Re: limited bandwidth with SiS900 onboard NIC

From: Jesper Juhl
Date: Fri Jun 18 2004 - 12:44:03 EST


On Fri, 18 Jun 2004, Thomas Latzelsberger wrote:

> Dear readers,
>
> As mentioned on http://teg.homeunix.org/sis900.html and
> http://www.latzinator.com/acer_aspire_1705SMi.html there is a problem
> with bandwidth for the SiS900 onboard NIC. I allways use vanilla kernels
> and I'm having had this problem from 2.4.22 to 2.4.24 and from 2.6.2 to
> 2.6.6.

Does it work correctly with older or newer kernels - like 2.6.1 or 2.6.7?

> The symptom is easy to explain. I connect the PC to a 100MBit switch and
> no matter which method of transfer (ftp, scp, samba, nfs) I use, I get a
> maximum transfer rate of less than 400kB/s. By accident I found a dirty
> workaround that might be a hint for some tech savvy hackers: if I force
> the NIC to use halfduplex (allthough it's connected to a switch) it
> works like expected (7-8 MB/s).
>
> The only help I can be is that I can test new kernel drivers and send
> you feedback.
>
> Any help highly appreciated,
>

Doesn't have to be kernel related. I've seen plenty of cases over the
years where certain combinations of network hardware have issues like
that.
Sometimes it's a case of the two devices not being able to properly do
auto-negotiating together (even if both claim to support it) - I've seen
several cases of that with older 3COM NIC's hooked up to IBM switches -
forcing the port speed and duplex to the same value at both ends instead of
relying on auto-negotiation usually fix that up.
Sometimes it's a case of some equipment adverticing full duplex and/or
100mb/sec capability without actually being able to handle the dataflow
at that speed or duplex - I've seen that with several Realtek 8139 based
NIC's - the solution there is then often to drop down to half duplex or
10mb/sec speed...
And I've seen a lot of other similar problems when combining equipment
from various vendors in certain combinations.. some NIC's, Switches,
Hub's, Bridges etc just don't like eachother (and some are just plain crap
and don't work as adverticed).
Could also be caused by faulty cabling or too long cables I guess.

Ofcourse it can also be a driver issue, but it certainly does not have to
be. If it works with other kernel versions then I'd say a driver bug is
more likely.

--
Jesper Juhl <juhl-lkml@xxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/