Network Related Performace Problems? Check for Low Level Ethernet Problems First.

The first thing to look for when dealing with a TCP performance problem is a low level Ethernet issue and by far the most common issue is a duplex mismatch. Ethernet can run in either full or half duplex mode. In full duplex mode both the module’s adapter and the device it is connected to, its link peer, (typically a switch but not always) can transmit at the same time. In half duplex mode only one side can transmit. There is a window in time when both sides can think it is OK to transmit and do so, when that happens a collision is declared, both sides stop transmitting, wait a random amount of time and try again. It is important to understand that, when both sides are in half duplex mode, these collisions do not significantly reduce network throughput.

In a duplex mismatch one side is in full duplex mode and its link peer is in half duplex mode. The side in half duplex mode can experience late collisions and excessive collisions, these types of errors do significantly reduce throughput.  Any late or excessive collisions are an indication of a problem. The network slowdown may appear out of proportion to the numbers of late and excessive collisions because in a duplex mismatch condition even normal collisions will reduce throughput because the link peer will not retransmit the frame since it will not recognize a collision in full duplex mode.

So how do you tell if that is happening to you? The “netstat -interface” command will display the statistics that will allow you to determine if a duplex mismatch is occurring. In the following example, the statistics for the active adapter of the #sdlmux.m16.11-3 interface are displayed. I have removed the statistics for the standby adapter to save space and added the line numbers.

If the adapter is in half duplex mode you will see positive counts in lines 25 (Transmit frame was deferred), 26 (Transmit frame after a single retry) and 27 (Transmit frame after multiple retry). These are the normal collision counters. If you see positive counts in lines 24 (Transmit frame discarded, late collisions) and/or 28 (Transmit frame discarded, excessive retry) you probably have or had a duplex mismatch. These counters are only reset when the adapter is reset so positive values are an indication that there was a problem; counters that continue to go up are an indication that you still have a problem. If the adapter is in full duplex mode and you see a positive value in line 32 (Receive frame discarded, bad CRC) the link peer is probably in half duplex mode.

How did you get into this duplex mismatch scenario? It is of course possible to have one device configured to run in full duplex mode and the link peer configured for half duplex mode BUT the most common scenario is to have one device configured for full duplex and the link peer configured for auto-negotiation. Most devices when configured for full duplex will not auto-negotiate and according to the auto-negotiation specification the side trying to auto-negotiate must fall back to half duplex mode when it does not see the auto-negotiation protocol from the link peer.

By default the Ethernet adapters used by OpenVOS will auto-negotiate so unless the link peer is also configured for auto-negotiation or half duplex mode you will get a duplex mismatch. To set an adapter for a specific duplex mode you need to add the “-duplex full” or “-duplex half” string to the parameters field in the devices.tin entry for the adapter. You must also set the speed. The OpenVOS Streams TCP/IP Administrator’s Guide (R419) describes this in detail.

One final note, if the adapter is running at 1 gigabit then it will also be running in full duplex mode. No one supports half duplex gigabit.