YouTube is slow during the last days - possibly caching server issue?

[hlinden]

Hello Forum,

Currently, I'm seeing very low bandwidth from YouTube. I've chosen a not-too-popular video for testing in order to find something that isn't on HE's caching server yet. If you want to replicate the measurements, keep that in mind and use some other clip that hasn't been cached yet as well.

Code Select Expand

youtube-dl "http://www.youtube.com/watch?v=bNCzbzypWXY"
[youtube] Setting language
[youtube] Confirming age
[youtube] bNCzbzypWXY: Downloading webpage
[youtube] bNCzbzypWXY: Downloading video info webpage
[youtube] bNCzbzypWXY: Extracting video information
[youtube] bNCzbzypWXY: Downloading DASH manifest
[download] Destination: Screen_Color test video [1080p]-bNCzbzypWXY.mp4
[download] 100% of 79.39MiB in 11:41


The video is coming from a server in HE's network, namely 2001:7f8:49:1::d, which I assume is a YouTube caching server. A traceroute to it doesn't look too bad:

Code Select Expand


Host                                                                                                                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 2001:470:26:292::1                                                                                                                 0.0%    31    1.7   3.0   1.4  32.8   5.9
2. hlinden-1.tunnel.tserv23.zrh1.ipv6.he.net                                                                                          0.0%    31   33.6  45.4  28.4 239.6  42.2
3. ge2-20.core1.zrh1.he.net                                                                                                           0.0%    30   24.7  44.9  24.7 155.4  38.1
4. 10ge15-2.core1.fra1.he.net                                                                                                         0.0%    30   40.6  56.2  32.8 378.5  64.8
5. 10ge3-1.core1.buh1.he.net                                                                                                          0.0%    30   73.8  81.4  61.4 333.3  50.5
6. 2001:7f8:49::d                                                                                                                     0.0%    30   73.4  79.1  61.1 207.9  37.8
7. 2001:7f8:49:1::d                                                                                                                   0.0%    30   62.1  77.1  61.3 176.0  31.6


For comparison, here's the speed I expect from my connection:

Code Select Expand


wget http://mirror.netcologne.de/debian-cdimages/current-live/amd64/iso-hybrid/debian-live-7.6.0-amd64-gnome-desktop.iso
--2014-11-01 14:51:05--  http://mirror.netcologne.de/debian-cdimages/current-live/amd64/iso-hybrid/debian-live-7.6.0-amd64-gnome-desktop.iso
Resolving mirror.netcologne.de (mirror.netcologne.de)... 2001:4dd0:1234:1::deb, 194.8.197.22
Connecting to mirror.netcologne.de (mirror.netcologne.de)|2001:4dd0:1234:1::deb|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1252147200 (1.2G) [application/x-iso9660-image]
Saving to: 'debian-live-7.6.0-amd64-gnome-desktop.iso'

100%[=========================================================================>] 1,252,147,200 5.77MB/s   in 3m 49s

2014-11-01 14:54:54 (5.21 MB/s) - 'debian-live-7.6.0-amd64-gnome-desktop.iso' saved [1252147200/1252147200]



Now comes the weird part. If I download the same video a second time, it is a LOT faster:

Code Select Expand


youtube-dl "http://www.youtube.com/watch?v=bNCzbzypWXY"
[youtube] Setting language
[youtube] Confirming age
[youtube] bNCzbzypWXY: Downloading webpage
[youtube] bNCzbzypWXY: Downloading video info webpage
[youtube] bNCzbzypWXY: Extracting video information
[youtube] bNCzbzypWXY: Downloading DASH manifest
[download] Destination: Screen_Color test video [1080p]-bNCzbzypWXY.mp4
[download] 100% of 79.39MiB in 02:47



...which, I think, puts the problem somewhere between HE's caching server for Youtube and YouTube.

[kcochran]

We don't operate a cache.  Downloads would be direct from YouTube, or in this case it looks like it may be a cache operated by the RoNIX exchange.

[hlinden]

Oops. Indeed. Ok then, time to wait until this clears itself up. RoNIX probably doesn't care enough about this that it would be worth writing them a mail.

Code Select Expand


whois 2001:7f8:49:1::d
[...]
inet6num:       2001:7f8:49::/48
netname:        RoNIX-20090127
descr:          Asociatia Nationala a Internet Service Providerilor din Romania
descr:          Romanian Internet Exchange
[...]