My ISP in Los Angeles is Time Warner Cable, and I'm pretty sure they're cheating on my speed tests. I pay about $39 a month for either 15 Mbps down or 20 (I don't remember which), and when I run speed tests on sites such as speedtest.net, I always get a download speed between 15 and 20, usually around 17 on average.
But, the entire rest of the Internet totally sucks. I'm using Google's DNS (because Time Warner Cable's have been absolutely useless, like making me wait several minutes just to resolve a domain name), so that's not part of the problem either. It seems also that on the general Internet, the entire network drops in pulses every 30 seconds for 5 seconds at a time. So if I'm on Reddit, and click to expand a dozen imgur links with my RES extension... all of the links take a while to load, and then all of a sudden they all load at the exact same time.
I was reasonably sure that Time Warner Cable was using traffic shaping to "put on a good show" for Speedtest.net, and throttling my network speeds for all the other sites. So that if I called and complained about my slow Internet, they'd say "go to Speedtest.net and see for yourself that you're getting your 15-20 megs down that you're paying for" when instead, they're cheating on speed tests and slowing me down on every other site in the world.
I just had to find a way to prove it. The idea I came up with was to proxy my speed test through a fast web server. My web server, though, wouldn't cut it. My server got 900 megs down, but only like 12 megs up... which I thought was absurd, because a web server's entire purpose in life is to upload web content to the end users. A server's upload speed is the bottleneck that controls your maximum download speed when downloading data off of it.
I migrated to a new web server that gets much better results on speed tests, and its upload speed is higher than my quoted download from my ISP. So, I used it to try and test whether my ISP is cheating on me.
The tools I used: speedtest-cli, a command line Speedtest.net client (so I don't have to worry about trying to proxy Adobe Flash traffic, which is notoriously difficult to do), and proxychains, a Unix tool that lets you force any other program through a proxy regardless if the program wants it or not. This way I could proxy
speedtest-cli to run through my web server instead of directly hitting up Speedtest.net.
My web server is hosted in Kansas City, MO, which is a bit of a drive away from Los Angeles, so to remove any geographical bias from the equation, when I ran my speed tests from my web server, I selected Speedtest servers here in Los Angeles. This showed me that my web server was able to download and upload reasonably fast from Kansas City to LA, and that the opposite should be true as well.
I'll let the results speak for themselves (note: I'm hosting these images here locally because I'm not sure speedtest.net hosts the results on their server forever. Clicking the images though will take you to the link that speedtest.net gave me). I did two rounds of tests for redundancy.
|PC Speedtest||Server to LA||Proxychains|
wgetinitially spiked to about 500 some entire kilobytes per second (about 4,000 kilobits or 3.9 megabits) before quickly dropping to between 100 and 200 KB/s (or 800-1600 kilobits/s) for the remainder of the file transfer. Overall it took 22 minutes, 46 seconds to download. Given my quoted download speed of ~17 Mbps, and my server's upload speed of 35 Mbps upload to Los Angeles, this is inexcusable.
For those who like the dirty details, I copy/pasted my terminal outputs from speedtest-cli and you can see them here: speedtest-cli.txt. So you understand what you're looking at:
aerelonis my local PC.
debianis my web server.
proxychains ./speedtest-cli --shareis me running the proxy through my web server.
[kirsle@aerelon ~]$ cat .proxychains/proxychains.conf | grep -v '^#' strict_chain quiet_mode proxy_dns tcp_read_time_out 15000 tcp_connect_time_out 8000 [ProxyList] socks5 127.0.0.1 8080Where
127.0.0.1:8080is a SOCKS5 proxy over SSH to the web server.