THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Joe Chang

Gigabit Ethernet is Full-Duplex only!

People still talk about checking if the network is in full-duplex mode even when they are on Gigabit Ethernet. Let me say clearly: Gigabit Ethernet is full-duplex period. There is no half-duplex mode. The same goes for 10 Gigabit Ethernet. If Windows Task Manager says the network Link Speed is 1 or 10 Gbps, don’t bother checking the mode, it can only be full-duplex.

In the old days of 10Mbit/sec Ethernet was originally half-duplex. The old 10BASE5 (fat) and 10BASE2 (thin) cable had one signal carrier. Basically a one-lane road. So for Ethernet we had collision detection. Then Ethernet over Cat 5 became popular. For whatever reason, Cat 5 had 8 wires. 1 pair was used for transmit, another pair was used for received, the other 2 pairs were not used.

Some one came up with the bright idea to enable simultaneous transmit and receive, why else have a 2 lane road? (I am not sure if Kalpana was the first with full-duplex, alittle help from the network old-timers please). And this became full-duplex Ethernet. The standards committee IEEE 802.3 got together to figure out a way to detect the mode, to only use full-duplex if both parties supported.

Later (1994?) 100Mbit/sec Fast Ethernet came along. If I came recall correctly, most Fast Ethernet Adapters could support full-duplex and all could support half-duplex, and all could support 10 or 100 Mbit/s. The meant there were 4 modes, 10-half, 10-full, 100-half, and 100-full. The adapter driver would have a 5th settting: auto-negotiate, which would set to the best mode supported by the other end.

Most of the time, the auto-negotiation worked, going to 100-full if supported on both sides. The one combination that did not work in the mid-1990s was an Intel Fast Ethernet controller connected to a Cisco Fast Ethernet switch. This combination negotiated to 100-half even though both sides supported 100-full. It also so happened that at the time, Intel was the most popular Fast Ethernet controller and Cisco was the most popular switch.

So it was necessary to manually set the network to 100-full. Of course, if this were set, and the other side did not support full, then there would a huge number of network errors. I recall one network was getting 15Kbytes/sec on Fast Ethernet, far less than the 300KB/sec for older 10-half networks.
Gigabit Ethernet was from the beginning full-duplex only. There is no half-duplex mode.
The driver will typically show 6 options: auto, gigabit, 100-full, 100-half, 10-full and 10-half.

This is my article from 2003. At the time, Gigabit adapters were beginning to be affordable, but gigabit switches were still really expensive, the same situation today with 10GbE (if you consider $800 per adapter inexpensive). I was too cheap to buy a GbE switch with my own money, so I had to figure out how to make a cross-over cable for GbE

http://www.sql-server-performance.com/articles/clustering/gigabit_ethernet_networking_p1.aspx

Gigabit Ethernet over Cat5e, or 1000BaseT, uses all four pairs of wires. Each pair is used simultaneously to transmit and receive, as it is possible to determine in which direction a signal is traveling. The signaling rate is the same as 100Mbit/sec Fast Ethernet (125MBuad) but more than 1 bit is transmitted. See the Ethernet Alliance website for details

http://www.ethernetalliance.org/

Correction, half-duplex is supported!

Well the IEEE 802.3 specification does say Gigabit Ethernet is full and half-duplex. From what I can gather, half-duplex is required for hubs (repeaters). I vaguely recall that there were Gigabit Ethernet Hubs in the early days. I do not recall ever seeing a Gigabit Half-duplex option in the driver setting for any adapter. I have used most of the Intel and Broadcom adapters from the very beginning. Unfortunately, I gave/threw away all of my old systems. I will try to get access one when I can.

I did also find in a number of place, but not the IEEE 802.3 specification, that Gigabit speed requires auto-negotiate.

Below is an excerpt from the Intel Ethernet Adapter Users Guide on Setup Speed & Duplex (this link is provided for convenience, please go to the Intel website for the full documentation.)

Intel® Gigabit Network Adapter Considerations

Per the IEEE specification, gigabit speed is available only in full-duplex.

The settings available when auto-negotiation is disabled are:

  • 10 Mbps or 100 Mbps Full duplex (requires a full duplex capable link partner set to full duplex). The adapter can send and receive packets at the same time. You must set this mode manually (see below).

  • 10 Mbps or 100 Mbps Half duplex (requires a link partner set to half duplex). The adapter performs one operation at a time; it either sends or receives. You must set this mode manually (see below).

  • Auto-Negotiation 1000 Mbps. The adapter only advertises gigabit speed at full duplex.

I am not sure exactly what is meant by the opening statement. It might be that the Gigabit speed setting is only available with Auto-negotiate, which will try full-duplex, but could drop to half-duplex?

Below is a diagram from the Broadcom 1GbE. The 10 and 100Mbit/s modes allow a choice of half or full duplex. The 1GbE mode is auto-detect and will negogiate full-duplex if supported.

Broadcom 1GbE

The same applies for the Intel 1GbE adapter.

Intel 1GbE

Below is an Intel 10GbE that only supports 10GbE mode. Certain Intel 10GbE adapter can also support 1GbE mode.

Intel 10GbE

This is excerpt from the Intel 82576 Gigabit Ethernet Controller Datasheet: " The GMII/MII interface used to communicate between the MAC and the internal PHY or the SGMII PCS supports 10/100/1000 Mb/s operation, with both half- and full-duplex operation at 10/100 Mb/s, and full-duplex operation at 1000 Mb/s. "

Below is a diagram of 1000BaseT showing that transmit and receive occur simultaneously over each pair of wires.
1000BaseT
"The use of hybrids and cancellers enables full duplex transmission by allowing symbols to be transmitted and received on the same wire pairs at the same time."

Published Tuesday, March 23, 2010 7:44 PM by jchang
Filed under: , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Ts said:

Great post, thanks!

March 23, 2010 7:21 PM
 

nobody said:

kalpana was the first switch

mac address tables etc

traffic not broadcasted etc

March 24, 2010 10:27 PM
 

jchang said:

yes, but who was first with full duplex?

and before Kalpana, there were bridges, but were those just dual port or multi-port?

Kalpana was first with cut-through, and Ether Channel (port aggregation)

March 25, 2010 2:16 AM
 

Randall said:

Great post, now explain flow control please.

March 26, 2010 7:12 AM
 

jchang said:

why are you asking me about network stuff, go to the source

usually Cisco has great documentation on this, but i think their web sites has gotten too complicated.

http://en.wikipedia.org/wiki/Ethernet_flow_control

There some topics in networking that serious under-utilized, mostly regarding link aggregation, perhaps I should look at this,

another is making good use of 10GbE. A 10GbE adapter is around $1K these days, the cost of a 10GbE switch is probably higher than that on a per port basis. So I think there is something to be said for direct server-to-server 10GbE connections, especially between primary and backup. Its nice to be able to move 700MB/sec, but you have to know alot of details to actualy get this, as life is never simple.

March 26, 2010 1:37 PM
 

VT17 said:

You have very nice explanation of the Ethernet history, but why do you claim Gigabit Ethernet to be full-duplex only? Many (all?) Gigabit network adapters allow choosing half-duplex mode. Last but not least: IEEE 802.3-2008 Part 3 is far from excluding half-duplex :o

(Of course i'm not trying to promote half-duplex modes, just curious)

April 11, 2010 12:04 PM
 

jchang said:

great catch, see above

April 13, 2010 7:58 AM
 

someone else said:

why not just use the other wires? you say going from half to full was better? then say theres more wires available? and this was back in the early 90's???

December 12, 2010 5:45 PM
 

Ansis Atteka said:

It seems that Intel has disabled option to choose between Full and Half duplex modes for their 1000Mb/s NICs (there is only Full Duplex mode):

82546EB Gigabit Ethernet Controller (Copper)

ethtool eth3

Settings for eth3:

Supported ports: [ TP ]

Supported link modes:   10baseT/Half 10baseT/Full

                       100baseT/Half 100baseT/Full

                       1000baseT/Full

But Broadcom still have this option for their 1000Mb/s NICs:

NetXtreme BCM5721 Gigabit Ethernet PCI Express

ethtool eth1

Settings for eth1:

Supported ports: [ TP ]

Supported link modes:   10baseT/Half 10baseT/Full

                       100baseT/Half 100baseT/Full

                       1000baseT/Half 1000baseT/Full

Supports auto-negotiation: Yes

Advertised link modes:  10baseT/Half 10baseT/Full

                       100baseT/Half 100baseT/Full

                       1000baseT/Half 1000baseT/Full

And getting these two NICs together to use 1000Mb/s Full duplex mode is a real pain in the ass even if you connect them directly with a single Ethernet cable.

January 18, 2011 9:27 PM
 

Jay said:

Do you know how to really test the network throughput at 1 Gbit/s full duplex?

I tried so hard with IxChariot and couldn't make it.

Any suggestions?

Thanks!

March 28, 2011 10:38 AM
 

jchang said:

To me, the whole purpose of full-duplex was that the acknowledgement packets would not disrupt the main transmission. If I am copying a 1.5GB file from A to B, then I will be sending 1M packets of 1500 bytes (plus 10%?) from A to B, but there will also be 1 acknowledgment packet (possible 64 byte each) for every 2-8 transmitted.

No single application or function should generate saturation level traffic in both directions simultaneously. Hence, any one talking about 2Gb/s combined bandwidth is probably some one who does not know what he/she is talking about.

I do suppose you could copy a large file in each direction simultaneously? This could potentially generation 40-50MB/s in each direction? Perhaps this might work with each coming and going to different disk drives?

March 28, 2011 6:35 PM
 

Mike said:

I have 3 comps all hooked up on a verizon fios router and all 3 computer nics have 1 gig lan support, but when I look in windows

task manager of all 3 comps they come up showing link speed 100Mbps.

Checked all lan cables and all are cat6.

Router supports 1gbe lan...  

September 5, 2011 3:06 AM
 

TooMeeK said:

Hello,

I'm sorry to tell this, but I think You are wrong. Or I'm.

Anyway, I'm trying to run 1000baseT-FD (Full Duplex) mode using crossover cable between laptop and desktop.

1000baseT-FD works fine with Gigabit Planet switch on both.

However, my tests using iSCSI and Ramdisk shows that using MCS (Multiple Connections per Session) I can reach heavy write speeds when read speeds are quite low.

Mii-tool on laptop shows: "eth0: negotiated 1000baseT-HD flow-control, link ok", so mode is Half Duplex. I just changed cross cable - same situation. Tried with autonegotiation disabled. Still Half Duplex only.

I'll post about this issue soon..

February 3, 2012 3:33 PM
 

mclayto said:

I noticed this comment above:

"I did also find in a number of place, but not the IEEE 802.3 specification, that Gigabit speed requires auto-negotiate"

So I thought I'd help out with an excerpt from 802.3 2008 Section 3:

"40.5.1 Support for Auto-Negotiation

All 1000BASE-T PHYs shall provide support for Auto-Negotiation"

Notice this is specific to BASE-T (i.e. twisted pair). I haven't found a similar statement for the other GigE protocols.

August 15, 2012 5:16 PM

Leave a Comment

(required) 
(required) 
Submit

About jchang

Reverse engineering the SQL Server Cost Based Optimizer (Query Optimizer), NUMA System Architecture, performance tools developer - SQL ExecStats, mucking with the data distribution statistics histogram - decoding STATS_STREAM, Parallel Execution plans, microprocessors, SSD, HDD, SAN, storage performance, performance modeling and prediction, database architecture, SQL Server engine

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement