--------------4AB34B14E834C9A9B5F1C360
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
HERE IS A COMMENT FROM A FRIEND:
have you tried nfs writes under linux ?
in the best case, it is 10% of the performance
of nfs writes under solaris or freebsd.
(i use freebsd because it handles large jobs,
much, much better than linux, and handles nfs
a million times better than linux. however,
linux is more popular, and may win in the long
run. i tell people: if you use linux instead
of windoz-nt, consider yourself very, very fortunate.
if you use freebsd instead, consider yourself
enlightened). watch out for disk crashes under
linux - the extfs file system is like the ufs
filesystem running with the -async switch - ie,
fsck equivalent under linux is not guarnteed to be
able to recover from all power crashes (bob
ran into this, and has now switched
to freebsd).
You might be blaming the wrong thing.
Kev.
Ben Liblit wrote:
> I am running Linux 2.0.35 with 3c59x driver version 0.99E on a 100
> megabit network.
>
> 3c59x.c:v0.99E 5/12/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
> eth0: 3Com 3c595 Vortex 100baseTX at 0xff80, 00:a0:24:c5:ef:f0, IRQ 7
> Internal config register is 101001b, transceivers 0xe10a.
> 64K word-wide RAM 3:1 Rx:Tx split, autoselect/10baseT interface.
> eth0: Overriding PCI latency timer (CFLT) setting of 64, new value is 248.
> eth0: Initial media type 100baseTX.
> eth0: vortex_open() InternalConfig 0141001b.
> eth0: vortex_open() irq 7 media status 8802.
> eth0: Media selection timer tick happened, 100baseTX.
> eth0: Media 100baseTX has link beat, 8882.
> eth0: Media selection timer finished, 100baseTX.
>
> Several times a day, I seem to lose all network connectivity through
> this interface. This is an NFS-intensive environment, so NFS timeouts
> are generally the first symptom. The driver reports transmit errors
> with one of three different status registers:
>
> eth0: Transmit error, Tx status register 90.
> eth0: Transmit error, Tx status register c0.
> eth0: Transmit error, Tx status register 90.
> eth0: Transmit error, Tx status register 90.
> NFS server asterope.CS.Berkeley.EDU not responding, still trying.
> NFS server asterope.CS.Berkeley.EDU not responding, still trying.
> eth0: Transmit error, Tx status register d0.
> NFS server asterope.CS.Berkeley.EDU OK.
> NFS server asterope.CS.Berkeley.EDU OK.
>
> "ifconfig" records the following tally of problems:
>
> TX packets:734220 errors:0 dropped:0 overruns:8 carrier:8 coll:872
>
> The network generally returns after about one to five minutes. During
> that span, the CPU is pegged at 100% by a pair of "nfsiod" processes.
> A "traceroute" reports "host unreachable" for any address I might care
> to try.
>
> During these network outages, other machines on the same subnet
> continue to operate normally. Also, I have never experienced similar
> outages when running NT on the same machine. So at this point I am
> inclined to suspect the Linux 3c59x driver.
>
> Any ideas?
-- http://www.grfx.com mailto:dkc@grfx.com
--------------4AB34B14E834C9A9B5F1C360
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
HERE IS A COMMENT FROM A FRIEND:
have you tried nfs writes under linux ?
in the best case, it is 10% of the performance
of nfs writes under solaris or freebsd.
(i use freebsd because it handles large jobs,
much, much better than linux, and handles nfs
a million times better than linux. however,
linux is more popular, and may win in the long
run. i tell people: if you use linux instead
of windoz-nt, consider yourself very, very fortunate.
if you use freebsd instead, consider yourself
enlightened). watch out for disk crashes under
linux - the extfs file system is like the ufs
filesystem running with the -async switch - ie,
fsck equivalent under linux is not guarnteed to be
able to recover from all power crashes (bob
ran into this, and has now switched
to freebsd).
You might be blaming the wrong thing.
Kev.
Ben Liblit wrote:
I am running Linux 2.0.35 with 3c59x driver version
0.99E on a 100
megabit network.
3c59x.c:v0.99E 5/12/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
eth0: 3Com 3c595 Vortex 100baseTX at 0xff80, 00:a0:24:c5:ef:f0,
IRQ 7
Internal config register is 101001b,
transceivers 0xe10a.
64K word-wide RAM 3:1 Rx:Tx split, autoselect/10baseT
interface.
eth0: Overriding PCI latency timer (CFLT) setting
of 64, new value is 248.
eth0: Initial media type 100baseTX.
eth0: vortex_open() InternalConfig 0141001b.
eth0: vortex_open() irq 7 media status 8802.
eth0: Media selection timer tick happened, 100baseTX.
eth0: Media 100baseTX has link beat, 8882.
eth0: Media selection timer finished, 100baseTX.
Several times a day, I seem to lose all network connectivity through
this interface. This is an NFS-intensive environment, so NFS
timeouts
are generally the first symptom. The driver reports transmit
errors
with one of three different status registers:
eth0: Transmit error, Tx status register 90.
eth0: Transmit error, Tx status register c0.
eth0: Transmit error, Tx status register 90.
eth0: Transmit error, Tx status register 90.
NFS server asterope.CS.Berkeley.EDU not responding,
still trying.
NFS server asterope.CS.Berkeley.EDU not responding,
still trying.
eth0: Transmit error, Tx status register d0.
NFS server asterope.CS.Berkeley.EDU OK.
NFS server asterope.CS.Berkeley.EDU OK.
"ifconfig" records the following tally of problems:
TX packets:734220 errors:0 dropped:0 overruns:8 carrier:8
coll:872
The network generally returns after about one to five minutes.
During
that span, the CPU is pegged at 100% by a pair of "nfsiod" processes.
A "traceroute" reports "host unreachable" for any address I might care
to try.
During these network outages, other machines on the same subnet
continue to operate normally. Also, I have never experienced
similar
outages when running NT on the same machine. So at this point
I am
inclined to suspect the Linux 3c59x driver.
Any ideas?
-- http://www.grfx.com mailto:dkc@grfx.com