Network Slowdowns?

[Bill Hacker]

Freddie Cash wrote:

Odd, we do the exact opposite, replacing all non-3Com NICs we come
across with 3Com NICs, for the exact same reason you do:  to get
something that we know works, and works reliably.  :)
No doubt in an all-3Com environment it should do ..

For Windows, Linux, and FreeBSD, the only NICs that we found to work
well are 3Com 3C905B and 3C905C series NICs.
That could be a major differentiator - Windows, how it drives and configures 
NIC's, and what that requires of other players.

After a score of years 'in the barrel' we are down to just 4 legacy WinBoxen + 
one W2K 'server', and those only on their own internal LAN (Dell with onboard 
Intel NIC's).

Everything else is now *BSD, OS/2-eCS, or OS X.

D-Link, NetGEAR, RealTek, even a lot of Intel chipsets have given us
grief in the past.  Since standardising on 3Com, we haven't had any
problems.
Now we just need to find a good, solid, GigE chipset.

Have had mixed results over time with Intel, scrapping-out 2 different 
generations of them - but current Gig-E are rock-solid for us.

Unless, of course one has a 3Com+Win environment to adapt to?

- in which case, 3Com, of course...

;-)

But I still maintain that the problem in the original post is addressed best and 
cheapest by a NIC swapout - and to a different 'race', 'coz that means a device 
driver change as well.

IF THEN:

- the problem persists = experimentation by others is warranted (could be a MB 
bus timing problem, for instance)

- the problem goes away = driver-coders may be interested, but it is *probably* 
not a kernel issue. Could *still* be a system-board/bus hardware/timing issue.

Best,

Bill..