On Sat, Jun 6, 2009 at 3:50 AM, Michael Butash<
michael@butash.net> wrote:
> So I finally got tired of dealing with this speed degradation issue
> plaguing me since ubuntu hardy, and decided to put some work in on
> figuring out what the issue was, and I think I have. Since this issue
> seems apparent in literally anyone I've tried using Ubuntu on a Cox
> network (and some of you substantiated), I think this probably would
> apply to most of you on this list. I suspect the problem isn't limited
> only to ubuntu, but don't have other distro's to test with. Anyways...
>
> The primary issue was downloads, primarily apt updates in ubuntu, and
> other random large http downloads would suffer an extreme speed drop
> within seconds of starting. Literally going from 400-500kb/s to bytes
> (snail time). Easily tested using cli 'sudo apt-get -d install
> linux-image-2.6.27-14-generic' or any other big .deb file. If it starts
> fast and slows to a halt, read on.
>
> I first suspected Cox, but ruled this out trying even a new docsis 3.0
> modem with no benefit. Once I'd ruled out the ISP, I began testing my
> internal network and my computer. Ultimately I then began tweaking with
> sysctl's, adding in some network performance items I typically throw
> into webservers and such. I found that tcp window scaling seems to be
> the root of the evil. Disabing it resolved the issue:
>
> sudo sh -c "echo 'net.ipv4.tcp_window_scaling = 0' >> /etc/sysctl.conf"
> sudo sysctl -p
Try playing with the different congestion control algorithms.
After looking at this link, I'd try htcp first. Check out the 10Mbs
with background traffic graphs.
http://netsrv.csc.ncsu.edu/wiki/index.php/Intra_protocol_fairness_testing_with_net-2.6.22.git
root@brak> cat /proc/sys/net/ipv4/tcp_available_congestion_control
cubic reno bic westwood highspeed hybla htcp vegas veno scalable lp
yeah illinois
root@brak> cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
root@brak> echo "htcp" > /proc/sys/net/ipv4/tcp_congestion_control
To make it permanent:
echo "net.ipv4.tcp_congestion_control = htcp" >> /etc/sysctl.conf
Also make sure ECN is disabled. I never enable since it almost
always just kills traffic (which is a great way to reduce congestion).
root@brak> cat /proc/sys/net/ipv4/tcp_ecn
0
The rabbit hole goes very deep. There are a ton of knobs to tweak
in Linux with essentially infinite combinations. The best approach
in my experience is to make some educated guesses about the popularly
tuned knobs and make gross changes until something emerges that's good
enough. The returns on micro-tuning diminish very quickly and tend
to change drastically with even the smallest variable changes, such as
time of day, link quality, and system load.
-Al
> Instantly I'm getting a solid 400kb/s of transfer on my apt's again,
> as I'd expect.
>
> I'm going to begin looking into more why that seems to be an issue
> either as a general problem with the ubuntu sysctl config issue, a linux
> tcp stack issue, or something funky with cox that works against RFC1323.
> I've seen this issue on 3 separate pc's (and switch/firewalls with them)
> myself at different houses around the valley, so I know I'm not the only
> one with this issue. I just don't know how far the rabbit hole goes.
> I'd like to know if this fixes anyone else seeing the same issues. Let
> me know your results please!
>
> wtf is this sysctl for or rfc1323?
> http://ipsysctl-tutorial.frozentux.net/chunkyhtml/tcpvariables.html#AEN505
>
> -mb
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)