DragonFly users List (threaded) for 2006-10
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Network Slowdowns?
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..
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]