Live data from Hacker News

Building fast.com

techblog.netflix.com

171–180 of 180 posts

Re: Building fast.com

#171
post #72

Earlier quoted context omitted.

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.

No, I don't have it installed. But by testing addons, I figured out that Noscript is causing it. It's weird because in its settings, there is nothing in the "force https website" list, and the "forbid http" section is set to never.

I just installed NoScript and I can reproduce the problem you see. :(

Re: Building fast.com

#172
post #86

Earlier quoted context omitted.

Yeah right. Just wait until a user visits fast.com and unthrottle their connection for 20 minutes. I strongly suspect some ISPs already do that with speedtest.net.

Note to self: set up cronjob to ping speedtest.net and fast.com every 10 minutes, just in case.

I created a basic Windows service to do this (20 mins by default). Pull requests welcome.

https://github.com/jonashw/SpeedTestPingService/tree/master

Re: Building fast.com

#173
post #71

Looks like I've hit a case of IPv4 vs. IPv6. I recently noticed that fast.com starting showing me at about half my connection speed, 50Mbps. I only just now realised while looking at the traffic that it was doing it over IPv6. Disabling IPv6 in my network gets me a reported speed of 120Mbps on fast.com, which sounds about right for a 100/100 subscription + some burst. My ISP hasn't even officially announced any IPv6…

Chances are you are not running native IPv6. Most customers who "have access to IPv6" are running through IPv4 -> IPv6 conversion which adds immense overhead and is not a real indication of IPv6 to come. For all such customers, their pseudo-IPv6 will always be slower than IPv4. Most ISPs do not run any form of native IPv6 yet.

> Chances are you are not running native IPv6.

Yes, that's the case since, as I stated, I got IPv6 connectivity through 6rd:

> It is derived from 6to4, a preexisting mechanism to transfer IPv6 packets over the IPv4 network

Re: Building fast.com

#174
post #126

Earlier quoted context omitted.

I believe you replied to the wrong person. I never made that claim unless I am going crazy. speedtest-cli has a lot to offer as a tool

What did you mean "works great" for then? Just that your cron job works?

The actual tool I was suggesting was what I was saying works great. speedtest-cli has a lot more options available to you that a simple wget does not have.

It provides cleaner information quicker. Yeah you could certainly setup a cron job using wget and have it do everything you want it too down to the bits it changes in memory... That just offers a quicker way to do all you may want too with that information.

Re: Building fast.com

#175
post #163

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.

Try google's and see what you get from them. https://encrypted.google.com/search?hl=en&q=speed%20test

350mbps on Google too...

Re: Building fast.com

#176

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.

More likely your ISP is cheating and you don't actually reach 350 outside speedtest and some other routes they make sure you are unthrottled on. Would not be the first.

Maybe they throttle Netflix yes... I do get 350mbps on every other test and when downloading a test torrent though.

Re: Building fast.com

#177
post #99

Earlier quoted context omitted.

Yeah right. Just wait until a user visits fast.com and unthrottle their connection for 20 minutes. I strongly suspect some ISPs already do that with speedtest.net.

I've thought about that as well. Is there any evidence/reports for this?

I've never seen any, but I've also never seen anyone try and find out.

Re: Building fast.com

#178
"In pursuit of the design goal of simplicity, we deliberately chose to measure only download speed, measuring how fast data travels from server to consumer when they are performing activities such as viewing web pages or streaming video. Downloads represent the majority of activity for most internet consumers."

I'm willing to bet additional factors that went into that consideration were:

- Netflix gets massive download traffic on the cheap due to their scale. Upload, not so much

- This tool is a clever way of preventing providers from throttling Netflix servers without also throttling a (hopfully soon to be) popular speedtest. Uploading isn't something they need their primary customers to be able to do.

Re: Building fast.com

#180

Earlier quoted context omitted.

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 cont…

All of the traffic is HTTPS. The ISP doesn't get to see headers.
Post reply on HN