Live data from Hacker News

Building fast.com

techblog.netflix.com

31–40 of 180 posts

Re: Building fast.com

#31
post #3

Testing for speed is great and all but is there an app or something that can monitor my Mac's end-to-end connectivity to an internet source? Like, I feel like my connectivity is spotty but am not sure if it's Wifi, Comcast or other.

Try mtr, it's like a combination ping/traceroute

Re: Building fast.com

#32

First, I thought why another speed test, then I saw that they link their results directly to speedtest.net (the reference) and finally, I realized that fast.com is so much faster in detecting the download speed (but lacks upload and ping). Not bad. EDIT: And they secured a fantastic domain.

I think the point was they conduct the speed test from the same servers that deliver video content. So ISPs can't throttle video streaming without it showing up in this speed test.

If it's intentional throttling, fast.com would actually not be much of a problem. It'd still be easy to selectively apply traffic shaping to streaming but not to the speedtest traffic.

It would be harder (though not impossible) if there is an actual capacity problem, and the bottleneck is outside of the ISP's network. For example insufficient peering capacity, which seems to be where most of the Netflix / ISP friction is.

Re: Building fast.com

#33

Fast.com is a lot slower than both speedtest.net and http://speedtest.dslreports.com/speedtest for me... I get 78mbps on fast.com and 350 on the other two. Not sure what's going on? Maybe they don't have servers near me, I'm in Paris, France.

One possibility is ISP skimping on peering and transit. Had that issue with an old ISP in Switzerland.

Re: Building fast.com

#34
post #9

Earlier quoted context omitted.

Latency is largely irrelevant to one-way video streaming (at least until it's so high it affects throughput), and since Netflix designed this to test your speed for their one-way video streaming service I think leaving out latency testing is reasonable.

Latency is critically important... You can easily determine how much of a problem it is in your case by calculating your bandwidth delay product: https://en.wikipedia.org/wiki/Bandwidth-delay_product

In the real world TCP window scaling solves latency induced delays for video streaming in all but the most extreme cases (hence my caveat), and endpoint buffering can solve even those.

For many activities on the internet a 1,000ms latency would be intolerable, but for one-way video streaming it's unnoticeable to the end user. I don't really care if a packet containing video takes 50ms or 1000ms to get from the CDN to my TV, as long as it gets there and is reasonably consistent in it's ability to do so.

For this use case, if my machine can get 20Mb/s on the test, latency will just not affect me streaming a 10Mb/s video. Latency may be lowering my test results, but that's the point here - testing the effective throughput.

Re: Building fast.com

#35
post #9

Earlier quoted context omitted.

Latency is largely irrelevant to one-way video streaming (at least until it's so high it affects throughput), and since Netflix designed this to test your speed for their one-way video streaming service I think leaving out latency testing is reasonable.

Latency is critically important... You can easily determine how much of a problem it is in your case by calculating your bandwidth delay product: https://en.wikipedia.org/wiki/Bandwidth-delay_product

[deleted]

Re: Building fast.com

#36
post #21

I seem to be unable to view the blog post in Firefox, it automatically goes to https which doesn't load. Maybe netflix messed up their HSTS settings at some point in the past?

Are you using HTTPS Everywhere? The Netflix blog post defaults to http for me. If I manually change to https, then it fails to load, as you describe.

Re: Building fast.com

#37

Fast.com is a lot slower than both speedtest.net and http://speedtest.dslreports.com/speedtest for me... I get 78mbps on fast.com and 350 on the other two. Not sure what's going on? Maybe they don't have servers near me, I'm in Paris, France.

Mine is actually faster on fast.com. About 140 on fast and 128 on speedtest. Yay.

Re: Building fast.com

#38

Earlier quoted context omitted.

I think the point was they conduct the speed test from the same servers that deliver video content. So ISPs can't throttle video streaming without it showing up in this speed test.

Makes sense but wouldn't they then use the netflix domain? Something like netflix.com/fast? I could image that if providers throttle it would be a mix of IPs and domain.

Some ISP's (we don't throttle anything) throttle based on several factors, mainly packet signatures. Traffic coming from big/known sources, such as Netflix, contain unique signatures (probably the headers, etc, that are unique to Netflix Traffic). You can then check all incoming packets that match those signatures and throttle them. So unless Netflix went out of their way to mask every request to look like video content, there's not a whole lot you could do.

Re: Building fast.com

#39

Earlier quoted context omitted.

I think the point was they conduct the speed test from the same servers that deliver video content. So ISPs can't throttle video streaming without it showing up in this speed test.

Makes sense but wouldn't they then use the netflix domain? Something like netflix.com/fast? I could image that if providers throttle it would be a mix of IPs and domain.

If you look at the actual traffic, it's hitting netflix's content servers. e.g. ipv6_1-lagg0-c001.2.bne001.waia.isp.nflxvideo.net

The interesting traffic is not to fast.com.

Post reply on HN