• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

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

Started by hlinden, November 01, 2014, 07:05:51 AM

Previous topic - Next topic

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.


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:


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:


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:


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.


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
[...]