A while ago YouTube put together a speed information page that you could use to check out your download speeds as well as compare to other isps in your area:
I'm also on Time Warner, and my graph shows wild inconsistencies - sometimes it spikes up to much faster than others, sometimes it's way below the average speed, and it also shows that Time Warner is the slowest provider out of all of the NYC area ISPs.
I wish it was easier to switch to another provider out here.
However, if I switch to another video (say a Google IO 2012 presentation), I get long pauses within the video constantly. 5-10 seconds of video, with 3-5 second pauses. In short, the test is hardly representative of my normal YouTube results.
"The test video will show you your streaming information in real time (look next to "Streaming HTTP")."
Uh, where? I don't see that anywhere, and Ctrl-F "streaming" doesn't find it, either.
If anyone on Teksavvy has a workaround, please let me know. Thanks.
I've noticed a change in YouTube buffering on FiOS the past few weeks as well. Other commenters here see it on Comcast. That may point to YouTube leaning more heavily on a CDN that can't handle the traffic (or some hop along the network to that CDN) rather than throttling by any one ISP.
One hell of a difference. I'm pretty shocked that they're doing this. I always thought it was Youtube that was being slow. http://www.youtube.com/watch?v=CB8UADuVM5A is an accurate depiction of what I just experienced right now.
I've never been able to watch anything in 1080 or 720 unless I want to go run an errand while it's loading.
After running these commands...1080 streaming like a boss.
I also applied the trick and now, magically, everything is quite a bit faster.
That said, while I'm not a network guy, this suggests that there's an issue with the YouTube CDN, not anything in particular with Time Warner or Verizon, unless they're doing something horrible relating to net neutrality.
My guess is just that there are a couple of CDN blocks that are preferred by the load balancers and they're saturated as a result, and blocking these IP ranges sends you to a less balanced block of CDNs.
I just temporarily blocked everything except 126.96.36.199/16 (google's home address), 188.8.131.52/24 and 184.108.40.206/16 (the CDN).
Youtube is plenty fast using the CDN. It can be slow to start because it sometimes tries other addresses first.
For those with tomato firmware:
Administration -> Scripts -> Firewall
iptables -I FORWARD -s 192.168.1.0/24 -d 220.127.116.11/24 -j REJECT
iptables -I FORWARD -s 192.168.1.0/24 -d 18.104.22.168/16 -j REJECT
If this workaround gets popular, I wonder if my provider (Comcast) and others will catch up and throttle youtube directly.
So far so good.
I also didn't find 22.214.171.124/24 in my testing. It's also a Google IP address, so I doubt it's causing any issues -- in fact, it may be the cause of some playback issues my wife is now having. (I think it may be their video ads, but have nothing to go on aside from getting "Playback Error" when an ad usually plays)
tool you can run to measure your own performance with jitter and dropouts and which caches your're being routed to:
For a bunch of internet enthusiasts y'all sure don't understand much about the world beyond your aws cluster.
Alas there was one horrible side effect. Videos took forever to start playing, and thumbnails for other videos on the screen (in the related videos section and other image assets) would not load until afte the video started playing.
so close :\
Guys, some networking 101:
* The route your traffic takes to get from point a to point b depends on your network/ISP/etc
* The CDN you use when accessing YouTube, et. al. depends on the route you take. The first/nearest CDN to you is (usually, depending on the CDN owner's configuration) the one that will be used.
* The fact that a video loads quickly on one ISP and slowly on another means absolutely, completely, totally NOTHING in and of itself.
To find out if the ISP is to blame or not, you must attempt to access the same CDN server from two different ISPs and see if you get the same problem. The latency will be different, but unless there is a massive bandwidth or latency bottleneck between two hops along either route, the overall bandwidth (for a large enough file) should be sufficient to deduce whether or not the problem is with your ISP or the CDN servers corresponding to the route your ISP is taking to contact Google's servers (the results need to be statistically significant taking into account margin of error and network conditions).
If the CDN is the problem, unless the CDN is actually owned by your ISP, your ISP is not to blame.
In fact, for traditional non-net-neutral throttling, it does not matter which/how many CDN IPs you block. Your ISP should (if they're doing it right) detect your connection to YouTube's subnet and throttle your data rates regardless of which CDN you use. The CDNs in the original article belong to Google/YouTube, not TW. As such, TW would throttle your connection on the way to Google's subnet, not at Google's subnet. They have no control over Google's subnet. The hops past TW's (or whatever ISP you use) servers are not under their control, cannot be bandwidth-throttled by them, and have nothing to do with net neutrality.
The real explanation is most likely poorly-balanced CDN servers. i.e. the traffic going to the CDNs is unfairly skewed towards one or more CDN servers, causing them to serve content to all users of all networks more slowly. By explicitly avoiding said CDNs which are slow on Google's end, you will use a different, less-pounded CDN that can serve your content faster.
Note that I am not even a TW user (Comcast here), but this lynch mob is getting out of control. I expect a higher understanding of basic network principles when I browse HN, and "I can't load YouTube quickly so this means my ISP is shaping my bandwidth, and I need not look for actual evidence to support this claim" does not qualify as such.
That said, yes, it is possible for a cunning ISP to shape your traffic by purposely mis-directing CDN selection, for example, making it so that all their users end up at the same exit (slow) node when contacting a YouTube IP as such effectively YouTube into serving all their content to all the ISP's users from the same CDN node(s), resulting in poor connection. The way to test this would be to map out the routes for packets sent all over, and search for statistically-significant routing anomalies when attempting to pass packets on to Google's network from within a certain ISP.
The CDN you use is often selected off a DNS response for many networks. An easy way to select a different CDN (that may adversely affect your browsing speed due to geo-origination!) would be to use a different DNS server (make sure to flush the DNS cache in your OS and in your browser). This is why it's not advised to use non-ISP DNS such as Google DNS, OpenDNS, etc) unless they're both a) anycast (basically CDN for DNS, your DNS query will go to the nearest geographic location to you) and b) have enough servers distributed around the country so that your anycast DNS request will be resolved near you, so that the CDN based off of DNS will also be physically near you. You can use namebench  by Google to query the fastest DNS servers, typically faster means closer as hops then physical distance are the biggest factors in DNS speed, though a shitty DNS server will obviously skew those results.
Just load a few videos in youtube with the chrome network tab from dev tools open, you'll very commonly see a CDN request returning a redirect to another CDN, 4-5 redirects isn't uncommon before the video plays.
Assuming that CDN selection is purely geographical or route based is just as poor an assumption as your accusing others of.
As you yourself quoted, I used the word "usually." That directly and explicitly implies "not purely."
The CDN you use depends on many factors. Nearness to your route/physical location is a big factor. The relative power/bandwidth of each CDN server is another factor (weighted distribution). Internal network factors also contribute to the decision, as does maintenance, BGP peering, random load distribution, and current network health/status.
Eg, The Jetstream CDN: http://www.jet-stream.com/
Any suggestion to make my blog post more technically sound, I'm all ears! I can't seem to find a conclusion in all the HN comments except that "it could be a bunch of stuff going wrong", and to be honest, I don't have the expertise to find said conclusion.
You can get that kind of info from Chrome's "Resources" tab in the dev console (or the equivalent in whatever browser you are using). You should run the test several times to avoid warm/cold cache along the way. Should the results significantly differ, you should also note the traceroute/tracert results to the final hop.
You can try these ready-made tests from Glasnost, but they do not cover all cases: http://broadband.mpi-sws.org/transparency/bttest.php
If that is the case, it's not unlikely that the off-net boxes are simply overloaded for people in this guy's usage area.
There are several other scenarios where it can be your ISP or can cause significantly different timings between ISPs. A lot of ISPs offer a network internal forward caching system (CDN-like) so your traffic will appear to go directly from your ISP to the CDN. This is typically done with servers inside your ISPs network but with anycast routing so requests to the CDN outside of their network stay within it. I don't know if Google/YouTube does this, but I do know that Netflix does.
Edit: this is independent of the post, which shows nothing but a fundamental misunderstanding of what's actually going on and why. I'd be more interested to see if this was flash or html5 video, whether it was using rtmp(s) for flash or http streaming, what IPs it ended up hitting instead of those two blocks and whether a traceroute for those two blocks went through the same or a different peer from where it finally connected.
There was a young upstart I had high hopes for, but I was out of their area. They are http://www.widerangebroadband.net/ and their customer service was great, but unfortunately I'm just outside their area at the moment.
Any new entrant has to build out a cable plant to reach subscribers and capture enough subscribers at a high enough density to make it worthwhile. The only company that's even trying at this point is Google.
2. Most of the larger markets are in densely populated cities, which makes laying infrastructure even more difficult (there's a reason that Verizon rolled out FiOS to suburban areas rather than urban areas).
3. If your 'value added' is something that the ISPs can easier undercut to drive you out of business (e.g. expanding bandwidth caps, increasing speeds), then your business proposition becomes even shakier.
..let's just say that if the author ever comes to Brooklyn, he will not leave sober. This is incredible.
To test: try a different DNS resolver, and see if you start getting faster video loads. If you're using TWC's local resolver, try 126.96.36.199 (run by Google); if you're using Google's already try the local resolver and/or OpenDNS (188.8.131.52).
If that does work as well, I'd recommend it over the heavy-handed approach of blocking arbitrary netblocks. Especially since that second netblock listed isn't owned by Google, and so you could be collaterally blocking other content that you still want.
(Disclaimer: I work for Google, but in Ads, not anything network or YouTube related).
Interestingly, I get consistently the best performance from 360p and 1080 with the rest giving absurdly unusable streaming speeds. Not great, but servicable if i go get some coffee while buffers. I wonder if the different resolutions are being served up from different CDNs?
Anybody try this on fios and find improvements?
(btw my wife gets better streaming performance than i do on youtube from various video streaming sites in asia and i'd bet a dollar i live within 10 miles of a google data center. The google forums are on fire with complaints)
I have noticed some serious throttling on from Comcast for Youtube as of late.
I can tell because directly viewing youtube gets throttled about 2min in (so they pick up on it about 2min in, regardless of where I start watching the video). If I VPN to work I can watch the same video no throttle, and still have bandwidth to spare.
It's the same bottle neck, Comcast, and work is down the road from me on their own dedicated fiber, it's adding 4 hops and it actually runs faster. (and I checked the IPs, I'm connecting to the same youtube servers as far as I can tell)
Edit: a bunch of people complaining on a google group thread about the same thing: https://productforums.google.com/forum/m/?fromgroups#!topic/...
The performance I was getting was terrible - much much worse than any other device on my home network.
Turned out it was because I was using the Google DNS servers for the TV, and that was screwing it up.
The ABC iView app uses Akamai, which doesn't use the new DNS extensions to pass through the location of the client computer.
Changed DNS server and everything was good again.
I tried adding the ip ranges in article and it rendered youtube inoperable for me. No matter what quality setting I used nothing would stream. Removed the rules and youtube streamed again, albeit slow as ever (still cant stream 720 & 1080)
I can't stand this ISP and I have no alternative available to me here. Talk about living in misery.
Interestingly for me the domain the videos are coming from are all of the same general form:
> r1.sn-jvhj5nu-p5qd.c.youtube.com (where the bit before c.youtube.com varies)
Where as the reddit discussion has domains of the form:
The inclusion of the 'preferred' and 'cache' bit are somewhat interesting.
I did find that if I block 184.108.40.206/16 as well as the other two mentions blocks (220.127.116.11/24, 18.104.22.168/16) then no youtube videos will load at all.
I would venture a guess that blocking the mentioned ranges is just forcing you to the 22.214.171.124/16 CDN.
$ whois 126.96.36.199
I won't include the whole output, but here is the link of the allocation: http://whois.arin.net/rest/net/NET-173-194-0-0-1
Basically, this listed IP block is part of a much larger allocation for Google. I don't know exactly what type of google service is hosted from it, but it isn't a commercial CDN.
> nslookup o-o---preferred---sn-mv-p5qe---v17---lscache1.c.youtube.com/
> Name: o-o.preferred.sn-mv-p5qe.v17.lscache1.c.youtube.com
> Address: 188.8.131.52
The gentleman in the video is Laurier. I sent him a message on FB thanking him for the videos, he is extremely friendly. There is actually a neat story behind the videos. The current playlist is slightly different than the original set. A while back someone paid him to take the original series offline for six months (under the theory that they were too helpful). Laurier took him up on his offer and when he put them back online the playlist was slightly different but still remarkably helpful. I am an order of magnitude faster now when I rock a room. The biggest change for me was using the concrete trowel instead of the normal 4/6/12 inch mud knife. That being said I did pick up a number of tips from all of the videos. The only thing I cannot do is freehand cuts with a tape measure and a blade, I still use the T.
I would suggest watching the entire playlist once before your next project starts and then watch the relevant video before each step as a refresher. I used to dread any project that involved drywall. When I do "habitat for humantiy"-esque projects now I try my hardest to be on the rocking team.
If you are skeptical about watching all the videos my big ah-ha moment came when I understood "mud control." This is a nice example:
I also experienced this temporary speed increase (from barely streaming 240p to getting smooth 1080p) if I switched locales (adding "&gl=CA" to the end of the URL) or switched to HTTPS.
netflix has an ARPU of $8/mo
youtube is probably lucky to have an ARPU of $0.25
netflix pays for transit from multiple t1's with dozens of pops
google traffic is 99% settlement free
it's almost seems like good video delivery must cost money or something.
when you peer with google you have to agree to offer all your routes at all peering points, they make an effort to do local delivery but its always best effort.
strangely, i never have a single glitch with netflix even though it always runs 6mbit, but i drop out on 240p often on youtube - this is verizon fios.
this whole experience is almost guaranteed to be google saving money or oversubscribing their regional cache boxes.
when you block certain class c's or b's you're just steering away from their cdn and hitting their primaries.
ipfw delete ____
where ____ is the id of the firewall entry.