[nSLUG] ethernet and the modern linux

Daniel Morrison draker at gmail.com
Fri Sep 26 18:03:20 ADT 2008

2008/9/26 George N. White III <gnwiii at gmail.com>:

> "Your opinion is important to us".


> I generally find that differences in opinion on technical issues come from
> differences in assumptions about the environment.   That makes this a
> linux issue because it is about a small pocket of linux in an ocean of
> Windows PC's (and the Windows machine belong to the managers,
> so as long as the managers think the network is healthy there aren't
> going to be changes to make a few linux systems work better.

Yes, you are probably entirely correct.

> On Fri, Sep 26, 2008 at 11:45 AM, Daniel Morrison <draker at gmail.com> wrote:
>> Your view is that networks where systems think the cable is
>> disconnected should just be left broken?

> Not exactly.

Sorry - I was being somewhat petulant when I wrote that...

> My view is that the world has many such networks in big organizations, and
> nobody is going to fix them.

I'm sure there are many broken networks in big organizations.  But I'm equally
sure that there are big organizations with excellent networks.

I'm running a relatively small network now (only have a /24, and some private
parallel networks for core servers).  But I worked for many years in a much
larger environment.  We had hundreds of dual-boot Linux/Windows (Windows was
the default boot) desktop workstations.  There were occasions when the entire
building's power was taken down for a while.  No issues when it came back.

(To be fair, if we had advance notice of the power shutdown, we would walk
around and trip the breakers in each room.  This way we had a controlled start
up when the power was back: walk around and turn the rooms on again one by

(Another note is that we used a multicast system (Norton Ghost) for imaging
systems.  Before a separate VLAN was created specifically for this purpose,
the few poor old 10 Mbit systems still on the network got effectively
disconnected due to flooding during Ghost sessions.  The multicasting at
100Mbit FD was also an excellent way to show up any misconfigured network
ports.  Any system on a misconfigured port would not be able to keep up with
the 'swarm' and would fail to image properly, and would promptly get some

> FD is faster when it works, but if the machine loses the net connection
> nothing moves.   If HD would work reliably, it may be the best approach.

I can't argue against those statements, but "when it works" and "if it would
work reliably" are red flags to me.  Obviously my experience is very different
from yours.  My experience is: ethernet is very reliable almost all of the
time.  When there are errors, those errors typically appear for very
particular systems, and the solution is invariably either 1) replace the
cabling/connectors/something physical, or 2) undo the the 'forced' settings
that were (accidentally) left over from some prior attempt to fiddle with the
network, and put it back to auto-negotiate.

If I ever come across a network connection which is HD, I immediately
investigate: what's wrong?  Why is it only HD?  Is there a mismatch with the
other end?  Check it!  Half-duplex is not a bad thing in of itself, but on
networks I've worked on it's usually been an indicator that there is some
other problem.

The only user complaint regarding the network that I've had ("my mail client
is slow!") turned out to be a system that had been forced to 100/full and the
switch had not.  I commented out the 'ETHTOOL_OPTS' line in
/etc/sysconfig/network-scripts/ifcfg-eth1, and the problem went away.  Good
thing too, because a later RPM patch configure script entirely commented and
reconfigured the interface, effectively taking away the forced configuration
on next boot (thanks a lot, Sun - NOT!).

> If HD allows us to get more done than FD, but is too slow, then we have
> an argument management can understand:  "we turned on the supercharger
> (FD) and the network kept blowing up, so we have to run without boost,
> but then we don't get enough power -- send money!"


More information about the nSLUG mailing list