-   Linux - Networking (
-   -   Painfully slow internet connection...yes, I did my homework. (

M@Rob 02-23-2007 06:48 PM

Painfully slow internet connection...yes, I did my homework.
I have had a problem with Mandriva 2006 for quite some time and have not been able to resolve it. Hopefully someone here will have some good suggestions.

I am not a Linux newbie, but I am not an expert either.

The problem is that my internet connection is PAINFULLY slow. I have found many threads that suggest diabling IPV6 in various config files and have done that.

I am pretty sure it is not hardware for the following reasons:

1. It does not happen in Windows on the same machine (dual boot)
2. I can use any Windows machine on it and have very fast connection speeds.
3. I have two Mandriva 2006 Linux boxes (different hardware completely) and they both do the same thing.

The problem is easy to reproduce. I can go to a web site with a large download (I found some large photos from photography web sites to test with) and as it is downloading a huge image, open the Network Monitor applet.

The download speed will show something around 15 KBs. But if I disconnect eth0 and then immediately reconnect it, I will get anywhere from 700 KBs to 1.5 MBs...but only for about two seconds. Then the speed drops again to 15 or so KB and stays that way from then on.

Disconnecting and reconnecting will produce the exact same results no matter how many times I do it. A burst, then crawling.


2.1 Ghz Compaq PC wit 10/100 NIC
Hughes Networks DW7000 Satellite modem
Linksys router

I can already hear the questions coming, so let me address some of them up front:

I know the satellite speed is good. I had a tech come out and test it today.

I know it is not a router configuration problem because I can plug straight into the ethernet port on the satellite modem and get the same results.

I know that it is not the Ethernet card because both machines (with different cards) have the same problem.

I know it is Linux-specific because if I reboot into Windows XP I do not have the problem.

I know that is is not browser specific because it happens in Mozilla as well as the other browsers in Linux.

I know that it is not KDE related because I get the same results in WM and FluxBox.

So the issue is that I can very briefly download huge files really fast, but something happens and it loses the speed after a couple of seconds.

I can also reproduce the problem with online speed tests (like It will start out at 700 KBs or so and then quickly slow to less than 20KBs

The same things applies when I download a large non-image file (such as an MP3).

Any ideas are really, really appreciated. If you need more information about my configuration or hardware, please ask.

dxqcanada 02-23-2007 06:49 PM

Have you run a network trace (Wireshark is a good tool) from both OS's and then compared them for any clues ??

M@Rob 02-23-2007 09:30 PM

I will give that a try
I am not sure how that will tell me what is going on, but I will give it a shot and post back the results.



M@Rob 02-23-2007 09:31 PM

Any other ideas in the meantime?

spindles 02-24-2007 07:00 AM

hi there,
Can't say I can help, just offering sympathy, and I want to watch the thread because I have just encountered a similar problem.

I was fixing a network problem earlier. As far as I know, all I did was make a change in samba.conf, adding something to "allow hosts".
(I MAY have done more, seemed like the network problem had caused a runaway process and I shut down the firewall for now.)

The result has been really slow internet speeds.
Other machines on the same router/gateway have no problems.

Browsers often need to be told twice to go to a website. On the first time either the name doesn't resolve or it's a time-out -- I don't know which.

Unlike you I don't dual-boot so I have not completely ruled out hardware (on-board network card) problems.
Seems all the browsers are affected to some degree.

Anyway, good luck.

M@Rob 02-24-2007 08:32 AM

Hmmm...I wonder if this may have occured after I installed Samba. I am going to uninstall it and see if it makes a difference. Thanks -M@

spindles 02-24-2007 08:33 AM

I don't know if this makes any sense, but I seem to have internet speed back to sensible levels after telling resolve.conf the default gateway -- even though the entry was already there!

as root:
echo nameserver >> /etc/resolv.conf

Well, resolve.conf is set to be dynamically modified on my system, so it could change.

It was all probably just a weird glitch.

People wanting to help with your problem will likely want to see the output from:

chkconfig --list | grep network

But you very likely know more abut it than I do -- for me, networking mostly worked out of the box and I have left it alone.

Good luck, again.

M@Rob 02-24-2007 09:25 AM

I removed Samba and rebooted and still see the exact same problem. I also looked at the nameserver and it seems to be right for the Hughes system. Besides, I don't think this could be the problem because this happens after the download has already started, so name resolution should already be completed.

Anyone got any other ideas?



M@Rob 02-24-2007 01:57 PM

Further verification that it is a Linux problem
I just set up a brand new XP machine on the same network and ran the speed test for both Linux boxes with the XP box in sequence and then at the same time. In all cases, the Linux boxes had an initial spike of 400KB/s which immediately dropped to less than 20KB/s and the Windows box got a steady 400KB/s + reading. The speed test I am using is at, but all speed tests I have tried show similar results.

I really like Mandriva and don't really want to tell my wife that I have to rebuild her machine, but these speeds are unusable. Again, any idea (no matter how unlikely) will be appreciated.


btmiller 02-24-2007 02:05 PM

One suggestion -- dop an ifconfig on your interface and see there are large number of packets being dropped for some reason. You could also use sysctl to increase the TCP send and recv buffers, but they're at pretty sane defaults to start with so I doubt that's your problem.

Have you run Wireshark as suggested? In particular you might want to look at TCP window scaling since you notice an initial spike followed by a slowdown. This could indicate that the TCP window is being set too small (you'll see the TCP window in the Wireshark dump output).

One final idea -- boot with a Knoppix or other LiveCD and see if the problem still exists. If not, try to duplicate as many of the network setting as possible. If none of this helps, can you post back a bit more about the hardware and network.

M@Rob 02-25-2007 08:51 PM

I ran "ifconfig eth0" and got these results:

eth0 Link encap:Ethernet HWaddr 00:12:17:57:C5:9F
inet addr: Bcast: Mask:
RX packets:188143 errors:0 dropped:0 overruns:0 frame:0
TX packets:175593 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:146087190 (139.3 MiB) TX bytes:22916641 (21.8 MiB)
Interrupt:18 Base address:0xc400

Not really sure how to interpriet them, but they seem pretty good to me. Anybody see anthing odd?

I am going to try runnig wireshark next.


btmiller 02-26-2007 12:30 AM

No errors or dropped packets, so that all looks OK. I'd highly recommend going the wireshark route and looking at window scaling. One more thing, you might try a variety of different services (e.g. http, ftp, and scp) for transferring data and see if the transfer speed problem is only with one of them or all three,

M@Rob 02-26-2007 07:54 AM

I have been working on the Wireshark angle. I have not been able to find a RPM for Mandriva for it and it looks to me like the only way to get it is to build from source. I am currently working through the dependencies trying to get that to work. If anyone knows of a simpler way to get Wireshark up and running, please let me know.

I am going to try to also get ahold of a live CD of some other distro and see if I see the same problem in it. That is actually a pretty good suggestion.


M@Rob 02-26-2007 08:03 AM

There is one other observation I have that may or may not shed any light on this. I hesitate to bring it up because once it is out there, it will be easy just to blame it for the problem, but I am going over a satellite link. In order to speed up browsing over 25000 mile link (or 1/2 second round-trip), Hughes uses a caching scheme that will cache the page request on the server, then "firehose" it across the link. As I understand it, it is a kind of "pre-assembly" of the page that happens on the server so it can be delivered in as few round-trips as possible.

I am not sure how this works on larger files, and I really don' think this is the source of the problem since it is not page-specific, but rather happens early on and I never regain the speed until I restart eth0, at which time it spikes and then tapers off again.

The reason I bring this up is that I am thinking that the initial spike may be a false reading by Linux due to the caching and delivery scheme on the server. I can quickly talk myself out of this by observing that if I attempt to download an image (for example, 3MB) and it bogs down, I can disconnect and reconnect and it loads almost instantly. But if I do not disconnect and reconnect it will take several minutes to download.

Again, I don't want this to cloud finding the real problem, but I wanted to get all of the information possible out to be considered.


btmiller 02-26-2007 11:25 PM

It's entirely possible that the initial spike might be a false reading (I've seen it on certain downloads not using satellite). The thing with a satellite connection is that the bandwidth should be OK, but the latency is miserable (due to the long rounf trip time. This is what the caching is supposed to help with. I'd say it's possible that the caching exacerbates the problem, but without understanding how packets are arriving, it's a bit tough to tell. There are lots of things that could be going wrong here. perhaps if the cache is "firehosing" it your machine can't keep up with the data transfer rate (receive buffers too small or some other problem affecting data transfer off the NIC card). If you do find lots of small TCP windows in the Wireshark output, you definitely want to play with TCP buffer sizes (look at/modify net.ipv4.tcp_rmem in sysctl -- if you Google there are directions for changing it).

All times are GMT -5. The time now is 07:25 AM.