Re: Youtube

We randomly have the buffer issue with youtube, where it refuses to buffer at all.

Right now, I'm running the pytomo program, while my son is watching a youtube video which isn't having any problems buffering (probably because he watches the same video several times a day?).--Battle.net Tech Support MVP

OK, this is an interesting result. I'm using a download plugin for firefox to download a video. Something less popular, will only get a few thousand views. It's been downloading at 150-400KByte/s. Mostly 150, sometimes climbing up to 400+.

I load husky's latest video (watch?v=69YAadYgMj4&feature=youtube_gdata) Not only does it load at close to 1MByte/s the video that I'm downloading also speeds up to >1Mbyte/s. I was able to repeat this a couple of times. This would explain why videos will download quickly at say 6PM when I get home, but if I have to reload the video later (ie when Chrome decides to wipe the video cache) it will load very slowly. Typically when I get home I'm pre-buffering several videos many of them from more popular sources (ie The Game Station sources, Yogscast etc).

Re: Youtube

So is there any update on this?

Again hitting different ggc servers will actually increase the speed of other ggc servers. I've been using this successfully when youtube decides to slow to a crawl, but it burns through a lot of bandwidth.

I did a 24h pytomo analysis from my home system over the past day. The database (.db and .tbz files) have been e-mailed to support@teksavvy.com. Using the web interface from pytomo, I was able to find out a few interesting things that might be of broader interest:

First, pytomo by default only appears to download standard-definition videos. The video encoding rate was uniformly in the 600kbit/sec range, which corresponds to about 480p videos (youtube's 'show video info' widget, by the way, doesn't give good encoding readings for 720 and 1080p). Consequently and unsurprisingly, on my lightly-loaded 25/10 connection I never saw buffering.

There was an interesting statistic, however, in the InitialRate data -- that represents the burst-download initial buffering of the first few seconds of the video. Overall, the burst rate was 12.5mbit/sec for me (roughly half of my line rate), which seems fine, but that was heavily modified by congestion. The burst rate fell from 12.5mbit/sec to about 6 from 18h-22h (eastern time), and then it recovered back to its full speed between 22h and 24h as peak congestion let up.

Checking the downloaded videos, these were all accessed from Toronto-based cache servers (all but one video seemed to be on Teksavvy's internal Youtube cache servers / googleboxes, at that.)

The peak-hours congestion can easily be causing the buffering that people here see. Based on youtube's upload quality recommendations, "standard quality" 1080p video should be encoded at 8mbit/sec. At this original bandwidth, the congested-peak-rate won't be enough for unbuffered playback. Youtube does appear to re-encode these videos to about 3.5mbit/sec, but I don't know the requirements for doing so -- this should be playable at congested hours, but there isn't much headroom.

In terms of other network diagnostics, nothing pointed to congested lines themselves. The average ping varied between 10ms and about 15, and it was only weakly related to the congested period.

Unfortunately, I could only test over IPv4. I do have an IPv6 login, but I found out only after signing up for the IPv6 beta that DD-WRT doesn't properly support IPv6-over-pppoe.

TL;DR: Teksavvy-network Youtube cache servers in Toronto are overloaded between about 8pm and 11pm EST, to the point that 1080p videos may require buffering. It's a datapoint of one, so I have to be right, eh?

An IPv6 test would probably itself be interesting, it might show a different congestion pattern than IPv4.

Looking through the pytomo source, it looks like the easiest way to disable IPv6 would be to tweak the DNS library to pretend it can't use INET6 sockets. I don't have any testing available, but editing pytomo/dns/inet.py to read:#try: # Pretend that we don't have INET6 at all# AF_INET6 = socket.AF_INET6#except AttributeError:AF_INET6 = 9999

beginning at line 34 might do the trick. The resolving will still happen, but it should pretend that IPv6 addresses can't be processed (failing back to ipv4).