DragonFly BSD
DragonFly users List (threaded) for 2006-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Network Slowdowns?


From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Mon, 09 Oct 2006 07:00:58 +0800

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]