[nSLUG] Full vs half duplex

George N. White III gnwiii at gmail.com
Sat Sep 27 08:42:52 ADT 2008

On Fri, Sep 26, 2008 at 5:18 PM, Jim Haliburton <jim at on-site.ns.ca> wrote:
> Draker commented
> "Full duplex is faster.  Half duplex results in collisions when both
> sides attempt to communicate with each other at the same time.
> Doesn't matter if you cannot sustain 100 Mbit data stream -- I'm
> talking about latency, not bandwidth."
> I am not sure if this statement is completely correct.  If using a
> switch, not a hub, then the collision domain is 1.  In other words there
> cannot be a collision.  One pair transmits, another pair receives.  What
> is transmit on one end of the cable is receive on the other.  There can
> be no collisions on a switched conection between a card and the switch.
> The transmit and receive paths do not cross.

I see contradictory information.  The Wikipedia article says that 100baseTX
uses separate pairs for xmit and recv, but elsewhere I read that half-duplex
is equivalent to the original coaxial cables, so I suspect the issue
is really a
question of how the interfaces implement HD and FD.  We have seen
huge differences between $10 non-name interfaces that come with
lowest bid boxes and "server grade" cards.  The cheap cards were
useless on a PC running an X server under Windows XP and had to
be replaced.   My guess is that  you can find hardware in the junk bin that
generates collisions when set for HD, but that you won't get collisions
using high-end switches and high quality interfaces.

> On Netware networks with IPX, using full duplex on the server end, can
> get you a 50-80 % reduction in throughput.  Setting the card to come up
> in half duplex is an easy setting.  In addition, when using IPX, setting
> Link Support Layer Max buffer size to 2048 will gain you some throughput.

Wasn't netware responsible for a flooding the world with really dumb
network interfaces and using their own network stack.

> Now Windows networks are quite different.  Because interrupts are not
> always handled elegantly or as quickly in Windows they need to use full
> duplex to fill the buffers on each end while the system is thinking about
> responding to the interrrupts.  Netware is much more interupt driven on
> the comm side so it can respond to cards at interrupt time and clear the
> data from the buffer.  In FD it is waiting for the buffers to fill rather
> than acting on an interrupt when it is full.  So HD is faster.  I have
> several clients still using Netware and this behaviour is documented and
> well tested in the Novell world.  Have seen this across NW 3.12, 5.0,
> 5.1, 6.0, and 6.5 regardless of the card brand.  When set at FD the
> system slows.  At HD 10 Mbit gives about 950K bytes / sec and 100Mbit
> gives over 8 MBytes/sec sustained.  Have not tested Gig.  But it is
> faster again.

This might be why Apple recommends HD (as opposed to SGI, who
wants you to keep swapping system boards until you find one that works
with your switch at FD).   Apple has their own network protocols, some
passed down from the early Mac OS, and some from the mach kernel.
Also, Apple has a tradition of doing more in software, so it would not
surprise me to find that Apple

> Just my personal experience.

I'm reminded of the parable of blind men and elephant, only networking
is more like one of those transformer toys:

first linux guru: I think a network is like an airplane -- it only
connects a few places
   and the schedule is not convenient
2nd linux guru: I think a network is like an automobile -- the check
engine light
  comes on every morning so I put a piece of duct tape over it
3rd linux guru: a network is like a gun because it kills systems at a distance

George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia

More information about the nSLUG mailing list