--pgp-sign-Multipart_Thu_Oct_20_22:43:56_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "ts" == Timo Schoeler <timo.schoeler@riscworks.net> writes:

    ts> all done, i've even used different switches -- always the
    ts> same.

What do you mean:

    >>> * running in full duplex mode not a single error occurs (i
    >>> used a 4GByte file and transferred it via ftp);

you say the problem is always the same no matter what you do, but you
also said it works fine with Nortel switch and manually set to
full-duplex, which makes me confused.  Which is true?

Duplex autodetection is a little unpredictable, but one of the common
rules is that either both sides need to be configured manually, or
both sides need to be set to Auto.  For example, if you set your Mac
to 'auto' and then set the switch manually to forced-fullduplex, then
the Mac will autodetect half-duplex, and you'll have a duplex
mismatch.  It is quite goofy and isn't guaranteed to behave that way
all the time, but that is how it's _supposed_ to behave in theory, and
even the theoretic behavior is not intuitive.

I think this is the usual reference people give:

 http://www.cisco.com/warp/public/473/46.html

I have had a lot of duplex problems at my house, because I carefully,
deliberately use 100mbit/s-only hubs exclusively, no switches and
certainly none of those disgusting ``dual-speed hubs''.  Realtek NICs
don't correctly autodetect the hubs and simply ignore their duplex
setting, and they fail using their supported proprietary Windows
driver even.  The Realtek Crab has become the household symbol for
utter crappyness and failure.  The weirdest problem I had was, an XBox
onboard NVidia NIC would get partitioned by the managed hub (link
light went green->orange) about once every two weeks, and it would
stay Orange/useless until I reboot the XBox.  The problem went away
when I got all machines with bad duplex settings off the segment---the
spew on the segment was somehow exercising a nasty intermittent bug in
the XBox NIC's Linux driver.

Everyone always says ``it can't be MY machine, i set it to half just
like you said,'' or ``but that's a good 3com card it couldn't POSSIBLY
be the culprit'' or ``i used Linux eth-tool and it said it was fine''
or ``but that machine works fine, it's this OTHER machine that's the
slow one'' or ``look at the collision light it's solid red, that's why
i'm losing so many packets'' (Ethernet collisions are *NOT* lost
packets).  WHATEVER, and blame it on my use of hubs or throw up their
hands and say the problem is just impossible to solve, and every time
I track it down to some guilty machine with combinations of flood
pings and big ftp downloads involving three or four machines at once,
incriminate the Realtek Crab _again_ and shame its owner into fixing
it, and then everything works great again.  When duplex is wrong
NetBSD's tlp driver scrolls 'CRC error' and 'dribbling bit' messages
so fast that the system clock starts to lose time.

...i had odd experiences in passing with bmac adapters so,...I
wouldn't rule out a bug in the gmac driver.  I'm just saying, if
people tell you to suspect duplex problems and diagnose it from that
angle, don't poo-pooh them: it's real and it's tricky.

--pgp-sign-Multipart_Thu_Oct_20_22:43:56_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQCVAwUAQ1hV9YnCBbTaW/4dAQJbcQP/bBroRTBGZQZz3JcK1Sq17nybgWp8jJ8/
KGoHs+JV3+ywsMNliD9V7Eq4f+FfLgPM/tN5+MKPYFm7luQz+6+W5clXlnMQNvw2
0bqgOAYFLBeoEb9IQEroYv/Hx7cxXxxbX5Hr900V7rWDhBWpamCCRJLa2q1Dy9FN
epT/ehrEiHg=
=TeFB
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Thu_Oct_20_22:43:56_2005-1--