SEO

Hello all!

I wanted to run something by you all to see if anyone has experienced this
issue.....



I am running Slackware 9.1 (which was upgraded directly from 9.0 per Pats
documentation of course) and updated the kernel to 2.6.1. I was waiting
for NVIDIA to support this kernel before I made the leap and that dream
became a reality the other day, so here I am. Everything works wonderful
except a few bugs. One is really irritating me and I cannot seem to find a
fix anywhere. Ever since the kernel upgrade, my network speed has dropped
considerably. I am on a 3MB cable modem but it feels like 56k most of the
time now. Other systems on my network are functioning at full speed.

Has anyone experienced this issue before, and if you found a fix, what was
it? I cannot seem to dig up any real info on it so I am turning to you
Nothing has changed as far as my config goes... with the exception of the
kernel of course. If you need more info on the issue, let me know and I
will gladly provide it. This is frustrating the hell out of me. My Slack
box is an old friend and I hate to see it rebuilt....


_MP

On Thu, 29 Jan 2004 19:57:48 -0800, Mad Penguin wrote:

> Hello all!

Good day.

> Nothing has changed as far as my config goes... with the exception of the
> kernel of course. If you need more info on the issue, let me know and I
> will gladly provide it.

Maybe it has probalems with auto-negotiating speed/duplex mode. Try
setting it "hard" (on both ends of the link). On the Linux side, that is
probably done with either "mii-tool" or "ethtool".

BTW, does "ping" show latency? Jitter? Packet-loss?

--
-Menno.

On Fri, 30 Jan 2004 10:46:46 +0000, Menno Duursma wrote:

> On Thu, 29 Jan 2004 19:57:48 -0800, Mad Penguin wrote:
>
>> Hello all!
>
> Good day.
>
>> Nothing has changed as far as my config goes... with the exception of the
>> kernel of course. If you need more info on the issue, let me know and I
>> will gladly provide it.
>
> Maybe it has probalems with auto-negotiating speed/duplex mode. Try
> setting it "hard" (on both ends of the link). On the Linux side, that is
> probably done with either "mii-tool" or "ethtool".
>
> BTW, does "ping" show latency? Jitter? Packet-loss?


Thanks for the suggestions. There is not latency, jitter, etc with a
constant ping to either local LAN nodes or Internet locations. I have done
some more research and it appears to only be affecting internet browsing
in X windows. I can surf the net in links/lynx with normal speed, but if I
try to use konqueror, mozilla, firebird, etc.. it crawls. Very interesting
problem actually. FTP seems to work fine at the CLI as well as the GUI
using apps like gftp or igloo. ????? heheh this is bizarre

Try that one on for size :-)

On Fri, 30 Jan 2004 18:46:28 -0800, Mad Penguin wrote:
> On Fri, 30 Jan 2004 10:46:46 +0000, Menno Duursma wrote:
>> On Thu, 29 Jan 2004 19:57:48 -0800, Mad Penguin wrote:
>>
>>> Nothing has changed as far as my config goes... with the exception of the
>>> kernel of course. If you need more info on the issue, let me know and I
>>> will gladly provide it.

[...]

>> BTW, does "ping" show latency? Jitter? Packet-loss?
>
> Thanks for the suggestions. There is not latency, jitter, etc with a
> constant ping to either local LAN nodes or Internet locations.

Ok, so it wouldn't be the physical-link (or settings there of).

> I have done some more research and it appears to only be affecting
> internet browsing in X windows. I can surf the net in links/lynx with
> normal speed, but if I try to use konqueror, mozilla, firebird, etc.. it
> crawls.

This would have me suspect preemption of the GUI over network tasks ...
That might be way off, but i'd bake a (similar) 2.6.1 kernel without it.

> Very interesting problem actually.

Yes. You want to make as sure as possible the packets "mozilla" and "lynx"
gegerate look the same. (To rule out diffrences, being scheduled oddball).

Try looking at the output of "tcpdump" and/or "etherreal" for that.

> FTP seems to work fine at the CLI as well as the GUI using apps like
> gftp or igloo.

Well, this sounds like a QoS (Quality of Service) setting to me.
As ftp-data sets the TOS (Type Of Service) field of the TCP packet, to
"maximize throughput". And "minimize delay" for the control connection.
For HTTP trafic, that's set to default (0000) - more info: RFC 1700

> ????? heheh this is bizarre

Maybe.

> Try that one on for size :-)

If you have looked at just about everything (and thus pin-pointed the
problem) you might want to try the kernel-dev mailing list.

--
-Menno.

Very interesting you should mention that, 'coz I seem to be suffering from the
same problem - and I'm also using an Nforce chipset! (Though I'm using the
3com port for network connection (A7N8X)).

Most things work OK (FTP, etc), but some (not all) websites are very slow (the
data seems to come in bursts, with long pauses in between -
www.theregister.co.uk in particular). The real bugger is that this is my main
machine at home, and when I try and grab files off it to another machine, it
is *painfully* slow - the speed drops to bits per second, with frequent
freezes - BUT only if the "client" machine is also running Linux! If the
receiving machine is running windoze, everything works at normal speed!
Transfers between all the other machines are lightning fast, regardless of
operating system!

The only machine that *does* interoperate at a reasonable speed is connected
wirelessly to my wireless/broadband router, and uses DHCP - everything else
uses fixed IP. I've been blaming the router (Dlink 614+), but I'm beginning to
suspect its something very odd about the Nforce machine and the 2.6 kernel.

To summarize, the problem only seems to happen on some websites, and locally it
only happens with fixed IP, not DHCP, and if both machines are running Linux
and the server is running a 2.6.x kernel!

Hmmm!

--
Pete
christy@NOattglobalSPAM.net
(make the obvious amendments to reply!)

On Sat, 31 Jan 2004 17:05:44 +0000, Peter Christy wrote:

> To summarize, the problem only seems to happen on some websites,
> and locally it only happens with fixed IP, not DHCP, and if both
> machines are running Linux and the server is running a 2.6.x kernel!

Try disabling ECN (Explicit Congestion Notification) like so:

sysctl -w net.ipv4.tcp_ecn=0

Or maybe so:

echo 0 >/proc/sys/net/ipv4/tcp_ecn

--
-Menno.

On Sat, 31 Jan 2004 14:06:11 +0000, Menno Duursma wrote:

> Yes. You want to make as sure as possible the packets "mozilla" and "lynx"
> gegerate look the same. (To rule out diffrences, being scheduled oddball).
>
> Try looking at the output of "tcpdump" and/or "etherreal" for that.


hmmmm. I took a closer look at the output of Mozilla Firebird as compared
to that of Links using Ethereal and the results are completely different.
This is interesting to note, as this setup worked fine before the upgrade
to 2.6.1. In any case, here is a breakdown of what I have found (I've
shortened it up a bit to make it easier to read).


The test site I used was postnuke.com. Reason being is that since the
upgrade, it is one of the sites that takes the longest to load (20s using
firebird, 5s using links). Here is the edited output of Ethereal:

Mozilla Firebird:

ARP who has 192.168.0.32? Tell 192.168.0.1
ARP 192.168.0.32 is at 00:60:97:78:9a:3a
DNS Standard query response
DNS Standard query AAAA postnuke.com.lv.cox.net
DNS Standard query response, No such name
DNS Standard query AAAA www.postnuke.info.lv.cox.net
DNS Standard query response, No such name
DNS Standard query A www.postnuke.info

....this goes on for some time before it actually connects and downloads data
from the site. Like I said, this kind of activity continues for about 20
seconds. Completely unacceptable for a 3MB Internet connection.



Links:
ARP who has 192.168.0.32? Tell 192.168.0.1
ARP 192.168.0.32 is at 00:60:97:78:9a:3a

DNS Standard query A www.postnuke.info
DNS Standard response A 66.227.122.74
DNS Standard query A www.postnuke.com
DNS Standard response A 66.227.122.74

It is at this point that the browser gets the resources it needs from the
site.... working well by the looks of it.


There is my problem in a nutshell. Thanks for pointing me to sniffing my
traffic from this box, Menno. Good idea that I failed to think of.

On Sat, 31 Jan 2004 17:04:39 -0800, Mad Penguin wrote:


>
> hmmmm. I took a closer look at the output of Mozilla Firebird as compared
> to that of Links using Ethereal and the results are completely different.
> This is interesting to note, as this setup worked fine before the upgrade
> to 2.6.1. In any case, here is a breakdown of what I have found (I've
> shortened it up a bit to make it easier to read).
>
<snip>

>
> There is my problem in a nutshell. Thanks for pointing me to sniffing my
> traffic from this box, Menno. Good idea that I failed to think of.


Ok, After digging through my kernel config and finding that everything
looked fine (QoS was disabled by the way.. forgot to mention this in my
last post), I removed the IPv6 option simply because there is no need for
it. I recompiled and rebooted. Everything is working fine now. Sniffing
Mozilla-Firebird as it queried for postnuke.com proved to have the same
output as links did earlier. It pulled the A record of postnuke.com and
went straight to it.


Now.... whether this had anything to do with IPv6 or not I don't know. I
am doubting it... but for wahtever reason it works now. So I will chalk
this one up to a big mystery until I have time to look further into it.

Thanks for all your help in either case, bud!

Menno Duursma wrote:

> Try disabling ECN (Explicit Congestion Notification) like so:
>
> sysctl -w net.ipv4.tcp_ecn=0

I haven't actually got ECN configured in the kernel, so not surprisingly, this
had no effect!

I did rebuild my modules, removing the ipv6 stuff, and that has got web
browsing working properly again (www.theregister.co.uk now loads in a
reasonable time without pauses).

However, local file transfers are still an issue, but on further investigation,
this appears to be a KDE problem! Transferring a kernel source file (approx 30
MB) via mc (Midnight Commander) takes a few seconds. Trying the same transfer
using the KDE file manager takes over 5 minutes, with frequent stalling for
long periods.

However, KDE 3.2 is imminent, so maybe I'll just wait for that and see if it
fixes the problem.

In the meantime, I would recommend *NOT* building ipv6 stuff, as this does seem
to cause problems on certain websites!

--
Pete
christy@NOattglobalSPAM.net
(make the obvious amendments to reply!)

Peter Christy wrote:
> Menno Duursma wrote:
>
>
>>Try disabling ECN (Explicit Congestion Notification) like so:
>>
>>sysctl -w net.ipv4.tcp_ecn=0
>
>
> I haven't actually got ECN configured in the kernel, so not surprisingly, this
> had no effect!
>
> I did rebuild my modules, removing the ipv6 stuff, and that has got web
> browsing working properly again (www.theregister.co.uk now loads in a
> reasonable time without pauses).
>
> However, local file transfers are still an issue, but on further investigation,
> this appears to be a KDE problem! Transferring a kernel source file (approx 30
> MB) via mc (Midnight Commander) takes a few seconds. Trying the same transfer
> using the KDE file manager takes over 5 minutes, with frequent stalling for
> long periods.
>
> However, KDE 3.2 is imminent, so maybe I'll just wait for that and see if it
> fixes the problem.
>
> In the meantime, I would recommend *NOT* building ipv6 stuff, as this does seem
> to cause problems on certain websites!
>
You cant resolve IPV4 names with IPV6 tunneling as it is now.