Duplex Mismatch
Duplex mismatch occurs when one side of an ethernet connection is set to auto-negotiate, and the other side is set to 100 MBps full-duplex, between any two network devices. In this case, the side set to auto-negotiate will (silently) default to half-duplex and the other side will remain at full-duplex resulting in a mismatch. This is because it is not possible to manually configure one side for 100 Mbps full-duplex and the other side set to auto-negotiate, according to IEEE 802.3u.
The side that is set to half-duplex will drop packets whenever there is data being sent and received at the same time.
This condition usually manifests itelf when download rates exceed approximately 1.5 MBit. Even though a connection should have higher rates, say 6.0 MBps or 8.0 MBps, it will seem limited at around 1.5 MBit. The bandwidth chart in NxCoreAccess will show erratic changes in the download speed when in TCP mode. This is because the TCP algorithm drops the receive window in half when a dropped packet is detected, then doubles the window after successful transmission of a packet. A classic telltale sign is that a tcp connection will appear to be limited to around about T1 speed -- 1.5mbits because the tcp acknowledgment packets collide with the reception of new data packets starting around that level.
In UDP mode, the bandwidth chart will show pink lines at the bottom (which indicate dropped packets that had to be resent). The frequency of pink lines will correspond with the speed data is received, usually turning to solid pink (one or more per second) when the rate exceed 1.5 MBit.
NxCore's UDP algorithm is far superior to TCP in dealing with this problem, so it is best to not disable UDP in NxCoreAccess.
Correcting duplex mismatch is easy once it is identified.
Typically the issue is between a switch and the service providers equipment, so make sure all equipment is either Auto-negotiate on both sides, or at the same 100mbit-fixed duplex on both sides. Most older equipment that does not have a way to configure the duplex is set to 100mbit full duplex. Most newer devices without a specific configuration panel are auto-negotiate.
Firewalls
NxCoreAccess connects to port 55555 (five 5's) on an NxCore Server via TCP and UDP. To future-proof your network settings, allow ports 55550-55560.
NxCoreAccess as a Multicast Server
If you're running NxCoreAccess as a Multicast-server, we strongly recommend that your machine has 2 NIC cards, and that you bind the Multicast Server to the idle card.
Visually Troubleshooting Connections
Good TCP Connection
Here is an image of a good TCP connection.
Notice the full wall of yellow (signifying TCP) traffic, in this cases it's replenishing the tape, and is about -89 minutes behind, so it's going full bore.
The red line underneath is an indicator that it's still not real-time
Good UDP Connection
Here is an image of a good UDP connection.
Notice the full wall of green (signifying UDP) traffic, with peaks and valleys that are just data flows.
The blue line underneath signifies that it's up-to-date, and getting real-time data.
Duplex Mismatch
Here is an image of a duplex mismatch.
Notice the peaks and valleys, and the average bandwidth around 1.44 mbps
Saturated Connections
Here is an image of a saturated connection.
Notice the really jerky ping-time yellow line -- in normal cases, over the day, ping times should be very stable, creating a mostly horizontally-flowing line, with very occasional moves
MTU No Fragmentation
Here is an image of a case where the router drops packets that exceed their MTU.
Notice how the "time difference indicator" starts out as a hard-to-see thin blue line under a wall of green (UDP traffic),
then before 09:32 it becomes yellow (still green UDP),
then traffic stops mid 09:32 (gap),
until at 09:33 it goes red and NxCoreAccess switches to TCP (yellow wall -- notice how it uses entire 8-mbps bandwidth of the window to fill in the tape),
and we catch up to the time at 09:34, and switch back to UDP traffic (green wall)
Also, note the yellow ping line (hard to see) between 09:30 and 09:35 is jumping all over the place, and then after 09:35 it appears to stabilize
Sliding Window Mismatches between routers
Here is an image of a connection between two routers where one router strips off the TCP sliding window multiplier information, resulting in each side thinking the window size is something different than what it really is
Notice the classically saw-tooth charts between 09:40 and 09:43 -- traffic builds up to the sliding window, then crashes as the routers get confused, forcing the window size to get reset to minimum
NAT Timeout on a router
Here is an extreme case of router that times out its NAT addressing way too often
Notice the gaps as the network connection is dropped, then reconnected, and then dropped after only a few minutes
