Re:The $200 Billion Rip-Off: Our broadband future was stolen...
by arbitrage on Wednesday January 08, 2014 @10:21AM
(#7023976)
So ... where you ever able to get comcast to actually fix the problem?
Re:The $200 Billion Rip-Off: Our broadband future was stolen...
by simoncion on Wednesday January 08, 2014 @06:09PM
(#7027541)
I never did bring it to the attention of anyone who could have done anything. :/ It was fixed a year after it started happening and a couple of months after I performed that diagnostic work.
If you have shell access to a Linux machine in a College of Engineering attached to some university somewhere [0], try this:
1) Use youtube-dl to get the actual URL of the video that Youtube is sending to your machine that's slow as balls. [1]
2a) Wget that url on your home machine.
2b) Wget that url on the machine attached to that university.
3) Notice the discrepancy between download speeds of those two machines. In particular, notice if your home download starts at full speed, but is throttled to super slow speeds after a couple minutes of video have been downloaded.
4) Run a traceroute (I love using mtr for this) to ensure that the route to Youtube from your home machine goes directly from your ISP's network to Google's network. If this is the case, then there's noone to blame for poor performance other than your ISP and Youtube.
Comcast used to severely throttle Youtube videos downloaded on my connection here in SF. Using the method outlined above, I discovered that:
* I had a direct path from Comcast to Youtube at both my house and at the university.
* At my house, the first minute or two of the video file was fetched at full link speed (~6MB/s), the remainder of the video (even when downloading a 1080p MP4) was fetched at ~100KB/s.
* The very same file when downloaded at a university across the country was fetched at full link speed (14MB/s) and never slowed down.
[0] To lessen the chance that the campus network admins will be artificially throttling your connection, natch.
[1] You will notice that this URL is super-long and appears to encode all sorts of fun stuff in the domain name. This (along with a traceroute) leads me to believe that accessing this URL at another physical location won't give you a file from another CDN that's closer to that other physical location.