Ran into the same issue in 2001, we deployed to production and it was dog slow. we changed the connection string to point to staging..fast as hell. So after 5 minutes or so someone decided to check the duplex setting and you can guess the rest  :-)

this was more a problem in the early days of Fast Ethernet. For what ever reason, the Intel FE NIC and the Cisco FE switch would not auto-detect and revert to half-duplex. This much more than a 2X reduction, in half-duplex, there are collisions. Consider a one lane road that traffic in both directions must share, versus a 2 lane, one for each direction. GE does not have a half-duplex setting, setting to half-duplex would revert 100Mb/s or 10. See my paper on SQL-Server-Performance on GE direct connect, which explains why there is no half-duplex

I've constantly encountered this since sql 6.0, finding missmatches in nics and switches. For the DBA it is difficult to sometimes convince anyone that there may be network problems, the same I also find with fc networks whereby questions about queue depths, buffers and so on are usually met with toal indifference - I know you've already blogged about HBA queue depth, it helped my cause considerably so thankyou for that. So sadly I have to report this issue is alive and well in production systems today.

I think the biggest mistake people make in network assessment is looking at % network utilization to deduce that there is not a problem, which is a nearly useless counter as far as SQL is concerned. SQL really depends on serialized communications, where a network call is sent from client to server, the server responds with one or more packets, some which require acknowledgements. The fact is % network utilization will never be very except in backup or file transfers. packet latency is the bigger deal, plus the full network round trip time/

Linchi,

This is a great post.  I have long suspected the impacts of misconfigured network duplex status, but have not seen the effects so well documented until now.

I am familiar with the process for configuring a NIC, using Control Panel / Network Connections/ right-click on desired NIC and choose Properties / click on Configure button / click on Advanced tab / Choose the Speed and Duplex property (or similarly named property).  This process will catch the obvious (such as your case – explicitly configured server NIC for half-duplex when full-duplex is desired), but it will leave to question the actual NIC status when “Auto” is requested (what duplex status was actually used – you hope the best is used – full-duplex, but you don’t know for sure).

What I am hoping for is an automatable process (such as a script) for getting the actual (versus requested) network duplex status.

Do you know of a host-based process for determining the actual (versus requested / configured) network duplex status for a given NIC / connection?  I have tried to find a non-invasive, host-based, vendor-neutral, self-detecting approach that:

-  Does not require physical access to secured facilities (data center)

-  Does not require visible or manual recognition (duplex light is lit on the proper NIC in the back of the server cabinet or on the proper network switch port)

-  Does not require collaboration with other IT staff (network, etc.)

-  Allows for automated collection and inventorying (if desired)

I have not had success towards these goals so far.  WMI doesn’t seem to capture network duplex status.  I haven’t found a GUI or command line utility for finding it.  Registry info on NIC configuration is highly vendor and model dependent, and only gives you “requested” configuration – not what is actually used (which may differ).

The alternatives:

-  Visual observation of the duplex status lights on either server NICs or network switch ports

-  Requiring access to physically secured facilities (data center) or relying on those that have such access

-  Use of network monitoring software or hardware tools

-  Involvement of additional IT staff (network, etc.)

may offer a solution, with catches (delays, etc.).

I have to believe that the running part of the NIC (internal registers, etc.) and some part of the OS (drivers, etc.) know how the network connection is established (half-duplex or full-duplex), and thus should be “queryable”.

Any thoughts?

What processes / persons / tools do you use to determine the network duplex status of a NIC?

Scott R.

check this out

http://www.dearmisterjones.com/wordpress/2008/03/03/audit-your-computers-network-settings/