On Fri, 27 Apr 2007, Bill Fink wrote:
> On Thu, 26 Apr 2007, Ilpo Järvinen wrote:
>
> > On Thu, 26 Apr 2007, Chuck Ebbert wrote:
> >
> > > Ilpo Järvinen wrote:
> > > > ...I'm unsure how to continue the investigation from this point onward
> > > > and asking for ideas/suggestions or how to rule out more
> > > > possibilities...
> > > > Or is there some knob which I don't know of that should be toggled or
> > > > something, is 2.6 network stack expected to behave this way?
> > > >
> > >
> > > Try a different network adapter.
> >
> > Hmm, I thought I had already done this but I just noticed that it is so
> > that the adapter was still the same as the other host has two adapter (now
> > that I look again). I'll give it a try tomorrow to see if using the
> > another adapter makes any difference.
...Much more promising result this time. I noticed that there was another
eth hw on mainboard, thus my previous test with different hw was not
valid as I assumed "wrong" (didn't even notice the other) one to be eth0:
02:05.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74)
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (LOM)
Ethernet Controller (rev 82)
With 3c905 I have the problem, with Intel one it does not show up
(tested today).
> > > Try turning off hardware TSO offload:
> > > ethtool -K ethX tso off
> >
> > # ethtool -K eth0 tso off
> > Cannot set device tcp segmentation offload settings: Operation not
> > supported
>
> Could the delays be caused by Ethernet PAUSE frames (which might not
> be rquired at the slower 10FD but might at 100)? TX and RX pause
> control settings (check with "ethtool -a") might be different between
> the 2.4 and 2.6 kernels.
# ethtool -a eth0
Pause parameters for eth0:
Cannot get device pause settings: Operation not supported
> Also check things like net.core.netdev_max_backlog and ifconfig
> txqueuelen settings.
# cat /proc/sys/net/core/netdev_max_backlog
1000
...and...
txqueuelen:1000
> And check "ethtool -S", "netstat -s", and ifconfig error counters.
Nothigh really alarming was found, errors were all zero, only thing that
could be even remotely interesting is this:
5 delayed acks further delayed because of locked socket
--
i.
