Hacker News new | past | comments | ask | show | jobs | submit login
Building fast.com (netflix.com)
432 points by samber on Aug 9, 2016 | hide | past | web | favorite | 175 comments



This is beautiful. By using Netflix's actual CDN and requesting actual video files over HTTP, they're preventing ISPs from whitelisting fast.com without also whitelisting Netflix itself. Of course there'll be a game of cat-and-mouse with DPI, but it's a super-neat way of making it much harder for the ISPs to misrepresent actual video download speed...


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 did that, works great and with speed test cli it (did it without that at first) it's even better!

https://github.com/sivel/speedtest-cli

If you are going to setup a cronjob/service for it, I suggest using the --simple flag.


Any before/after stats to show this made a difference in speed?


Could you clarify the question?


Do you have any proof that running a cron job impacts internet performance?


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.


oh wow thanks for that. That's /much/ better than my DIY solution of using selenium to automate it...


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

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


That'd actually be great. The moment there's any evidence towards that happening I'm adding a cron script to visit fast.com every 15 minutes.


Make sure you update your user agent string to the latest Chrome every couple of weeks too. (I'm assuming any ISP doing this is already doing all kinds of sneaky things).


Since fast.com is https, the headers are encrypted. Correct me if I'm wrong, but unless the ISP has the CAs private keys they wouldn't be able to tell your user agent.


The CAs private keys can't be used to decrypt https. All the CA does is sign your public key in a certificate that shows validity and the domain name.


The DNS-Query or IP could be used to identify somebody accessing fast.com.


That still doesn't allow the ISP to tell the difference between e.g. wget and a browser via a current User-Agent-String, thanks to HTTPS.

The domain is exposed over various ways, yes, but that's the point of the idea to connect to fast.com regularly to trick theoretical shaping based on it.


List of supported ciphers is unencrypted and very UA-specific.


That would work for speed tests, but users will still get full HD streams suddenly (and reliably) downgrading to 320p after 20 minutes. That's still more likely to reflect negatively on the ISP than Netflix, I strongly suspect ;)


As someone who works on multi-terabit networks, this would be very difficult for most network operators to handle. Don't overestimate the competence for malice here. Usually the tactics of shitty ISPs are much more simple, such as not lighting up peering ports that their eyeball customers are in effect paying for.


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.


They don't need to : they just host a speedtest.net server on their own network, which the client will select by default.


Still a win for Netflix.


Well the same tech could be built into Netflix apps on various devices, no web visit necessary. They also made a command-line tool available.


We need a speedtest website hosted on tor :D Then ISPs won't be able to know when you visit the site.


Tor is over an order of magnitude too slow for this to work. You might get a result, but that doesn't tell you much about the speed of your internet connection.


They may also just unthrottle for the first x MB of video.


Wow, I hadn't thought of that before! That really is genius.


It is beautiful, and even if it weren't harded to misrepresent video download speeds, it's a significant step up from speedtest.net. And now there's no need to leave the command line, which is even better. That said, perhaps "making it slightly harder... to misrepresent... video download speed" is more like it.



They could block or override the A RR for fast.com so that a client can't connect.


The only times I use my ISP's DNS servers are when I initially set up a computer and forget to change the settings.


Yeah but unless you tunnel your DNS traffic they can modify responses very easily. Not that this is super common yet.


At a certain point if they're going out of their way to mess with the connection I'm paying for I'll stop paying for it and go elsewhere.


Is this what DNSSEC is supposed to prevent?


Yes and no. It is what DNSCurve is designed to prevent.


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.


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.


If you look they aren't using fast.com as the domain they are downloading files from. That's just the domain that hosts the page. It doesn't matter if it gets throttled because it only serves up a few kb of html.


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.


The files that fast.com has you download ARE chunks of video files :)


Does anyone know which video the test file is?

Perhaps it's encrypted, or a Netflix promo piece.

Wouldn't there be copyright issues to use their actual streaming licences content?


If you have a Netflix subscription it's probably this or something like this [1]. For non-flixers it's a calibration video similar to [2]

[1] https://www.netflix.com/watch/80103278

[2] https://www.youtube.com/watch?v=cGgf_dbDMsw


Earlier I got curious and I was wondering this too. Seems to be a 'random' blob of bytes every time that doesn't decode, but then I remembered they serve DRM'ed video that is then decrypted on the client.


The connection is encrypted, the ISP can't see request headers. For the main data download, all they can determine is its an TLS connection to a netflix content server. Potentially you could do some stateful monitoring looking for recent requests to fast.com but it's generally much harder to implement than simple IP or SNI based profiling.


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


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.


> It'd still be easy to selectively apply traffic shaping to streaming but not to the speedtest traffic.

That presumes they aren't fully emulating streaming traffic to test speed. Not only is this the correct thing to do from a video streaming company that wants to test connection speed for their services (the quantity and size of packets can affect the delivery through different mediums and devices), but it also makes it obvious when your ISP is quietly throttling your video streaming traffic.

Since it's a win-win in this respect, I would be surprised if this isn't exactly what they are doing.


> That presumes they aren't fully emulating streaming traffic to test speed.

It's not really a presumption, it's the actual facts on the ground. The actual benchmark file is served over HTTPS from, but there are still multiple simple ways to distinguish the current speedtest testcase from normal streaming.


> The actual benchmark file is served over HTTPS from, but there are still multiple simple ways to distinguish the current speedtest testcase from normal streaming.

Do you mind explaining the details you are aware of that lead you to think they are not emulating streaming traffic in at least some portion of their test (since they are testing multiple sessions and types of traffic)? I may have missed a portion of this article or some other source that outlined this.

It would fairly trivial to send sample content of actual video content for the test, and emulate a streaming client on the tester side, so I'm not sure how an ISP would distinguish traffic in that situation.


Sure. One example is that someone doing a speedtest will have accessed fast.com before starting a download of video streams. This can be detected despite the the encryption, e.g. via looking at the SNI of the requests. It doesn't matter what the video stream looks like, since those separate TCP flows can be cross-correlated.


So in that case Netflix just decides to have their streaming clients occasionally access fast.com before regular streaming to get any traffic shaping eased?

I agree, that in this case, where a separate domain was used, ISPs can use that to detect a speed test is likely. That said, I would like to note that every solution an ISP has to implement is much more expensive to any mitigation put forth by Netflix, as long as they want to hide what they are doing. If they aren't hiding it, well that's one of the reasons netflix is doing this, to inform customers what they are actually getting from their ISP, and let them make choice whether they like the current product they are using from their ISP (if they have a credible choice).


Netflix could load something from fast.com on each Netflix navigation right?

Ultimately if they're playing cat to Netflix's mouse how much does each mitigation strategy cost them relative to Netflix? I wonder if it's more cost effective to process that much traffic through shapers than it is to increase bandwidth between peers or allow Netflix to drop their boxes within their networks.


The same functionality can surely be built into Netflix apps.


> but there are still multiple simple ways to distinguish the current speedtest testcase

Like looking out for DNS queries for fast.com then handling traffic from that client differently for a period (such as the A record's TTL).


Also, I'd imagine it's a way for them to fight back against providers capping download speeds to Netflix's content.


Since they took this precious domain, I was wondering about the purchase price and if it was worth to buy this awesome domain—we are talking here about a mid six digit at least, rather seven digits.

Then, I checked how much traffic speedtest.net is getting on SimilarWeb: wow, 150m visits per month, I didn't know that speed testing can be so popular.

Conclusion: Yes, it was right to buy this domain and if fast.com gets a large part of speedtest.net's traffic in the long term, Netflix has a neat free Marketing channel.


They also have a pretty simple way to show end users that their ISPs are either throttling them or being uncooperative with Netflix. I'm not sure what it will do to monopolies, if anything, but it could apply significant indirect pressure to a lot of ISPs.


They also have slow.com... speedtest.net might be dead.


Why not also measure upload speed? I get it, it's because their business model only requires people to download stuff. The current state of the internet is much like the old days, where only big corporations had the ability to "broadcast".

So I'm not enthusiastic at all.


Given throttling by ISPs targets primarily streaming (i.e. downloading), they designed a specialized bandwidth tool to illustrate this. If this were generic, sure, then your complaint would be valid, but this is not a generic tool.


Measuring upload would require building out infrastructure to receive data streams with reasonable performance.

That's nontrivially hard compared to the download portion, where they can use their existing CDN.

Sure -- they didn't build out a fully featured internet connection monitor. But what they have built is a pretty good tool, especially for diagnosing Netflix or last-mile performance.


>EDIT: And they secured a fantastic domain.

Apparently they have slow.com as well.


They bought slow.com too.


I believe another HN user, CyrusL, owns slow.com and redirected it to fast.com - https://news.ycombinator.com/item?id=11723650


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.


Maybe your ISP is generally throttling your traffic but whitelisting speedtest et al to hide it.


Perhaps that is a reflection of your provider's ability to serve bandwidth to Netflix servers?


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.


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


Notice how speedtest.net selects a server geographically close to you? Well many ISPs work directly with speedtest.net (and other similar services) to ask them to put servers in their own networks, so that traffic avoids going through potentially saturated peering links. So you are really testing the bandwidth of the last mile to your house and the ISP's internal network, which is not representative of your real network bandwidth to the rest of the Internet.


That's how it's supposed to be. Speedtest is measuring essentially that you're getting what you paid for. If you have 50/50 Fios, you're paying for a 50mbps connection to the Verizon network.

> So you are really testing the bandwidth of the last mile to your house and the ISP's internal network, which is not representative of your real network bandwidth to the rest of the Internet.

There's no such thing. If you were downloading a file from a friends computer and they have 2mbps upload, your connection speed will be 2mbps. How would your ISP have anything to do with that?

Fast.com just measures your connection to Netflix, which is valuable if that's a service you use a lot.


"There's no such thing."

Yes there is. The Internet is not an abstract cloud with unlimited bandwidth everywhere. Your ISP runs their own network, peered with other bandwidth providers or other ISPs. You may have a 50 Mbps downlink from your ISP, but it doesn't mean the real-world usable bandwidth to all hosts on the Internet will be 50 Mbps, because your packets will be going through these peering links when they leave your ISP's network.

"How would your ISP have anything to do with that?"

Well, simply put some ISPs have terrible peering and/or intentionally throttle. So speedtest.net will show you awesome numbers, but in practice anything you download will be at much lower speeds. This matters, this is precisely why fast.com was built, and this is why the GGP is seeing different bandwidths when testing with speedtest.net vs. fast.com.


My results were similar on DSL:

  Speedtest 12.6 Mbps

  Fast.com  13.0 Mbps
But differed on LTE:

  Speedtest 40.0 Mbps

  Fast.com  73.0 Mbps


It likely depends where the netflix servers are relative to you versus those used by other speed tests. For example, at my workplace in a big US city, I get about ~500Mpbs down from dlsreports, speedtest.net, and xfinity speedtest, because they are all using servers based in this city. Speedof.me and fast.com are not from what I can tell and give me download speeds between 200-300Mbps.


Try google's and see what you get from them.

https://encrypted.google.com/search?hl=en&q=speed%20test


350mbps on Google too...


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


What does testmy.net show?


It's a little odd that they elected to invent their own way of requesting just a range of bytes in a file. It's built into HTTP: https://tools.ietf.org/html/rfc7233


YouTube also put the byte range in the URL rather than using a range request header.

Perhaps it mitigates against proxies stripping the headers, or it simplifies caching.


I tried to use the Range header feature to resume downloads in an autoupdating app once, and it worked beautifully...for about 90% of users; the others had all kinds of weird issues thanks to transparent proxies and caches not handling the Range header correctly. This was years ago, but I'm not surprised they chose to be safer than sorry.


> I tried to use the Range header feature to resume downloads in an autoupdating app once, and it worked beautifully...for about 90% of users; the others had all kinds of weird issues thanks to transparent proxies and caches not handling the Range header correctly.

One of many reasons to use HTTPS: prevent tampering with your requests and responses.


Youtube recently did a writeup on their long road to HTTPS: http://youtube-eng.blogspot.com/2016/08/youtubes-road-to-htt...

I find it particularly telling that switching to HTTPS caused many streaming errors to mysteriously vanish, and I suspect ISP / proxy tampering to be part of the cause. I'd love to know more about what their engineers saw though.


We had similar issues when I was at iHeartRadio. We got reports from a number of users that were getting a lot of playback issues. Once we saw that the users were all in a relatively small area in the southeastern US, it took a few days of dealing with local ISPs to sort out the issue: all requests on a certain local ISP were being rewritten and certain headers were getting removed altogether.


you can also send a link that way (e.g. via email/Slack.) No way to send a link with an http header


Not that odd if you are trying to represent a chunk of a file with a single url, which would be desirable if you were serving video manifest/playlist files like m3u8 (HLS) or f4m (HDS). IIRC Netflix is using HDS.

Edit: not sure what format they are using, probably several depending on the client... But one url per chunk makes sense for multiple delivery formats as well.


As others have mentioned "ranges" are put in the uri stem & query string for two reasons; evading mangling proxies and simpler access from browsers/clients. From memory notable implementarions are MPEG DASH, action script/flash, icecast, and various proprietary "services".

The formats that send time ranges instead of bytes ranges are the worst. In that case the server/cdn has to retrieve & read the manifest, decode time indexes to fragments/chunks/ranges, and then return the appropriate byte stream to the player. This also means you cant cache based on the URI plus query string!

Source: ive worked at both ISPs and CDNs supporting streaming content


I mean I see the benefit, but any semi-competent proxy already caches based on the Vary header, and also the range header (per the HTTP 1.1 specification.) It shouldn't be a problem. Also query strings are per definition part of the URL.


Can you set range headers from javascript? Can you set them from random video player SDKs?


> Can you set range headers from javascript?

Yes, see http://stackoverflow.com/questions/15561508/xmlhttprequest-2...

> Can you set them from random video player SDKs?

Good point, probably not.


Most likely to make sure it works everywhere (browsers, proxies, etc)


You can also run fast.com from the command-line: https://github.com/sindresorhus/fast-cli


Here's a quick oneliner I threw together that does pretty much the same thing for those of us that dont have/want npm and node:

  mkfifo /tmp/fast.com.test.fifo ;token=$(curl -s https://fast.com/app-ed402d.js|egrep -om1 'token:"[^"]+'|cut -f2 -d'"'); curl -s "https://api.fast.com/netflix/speedtest?https=true&token=$token" |egrep -o 'https[^"]+'|while read url; do first=${url/speedtest/speedtest\/range\/0-2048}; next=${url/speedtest/speedtest\/range\/0-26214400};(curl -s -H 'Referer: https://fast.com/' -H 'Origin: https://fast.com' "$first" > /tmp/fast.com.test.fifo; for i in {1..10}; do curl -s -H 'Referer: https://fast.com/' -H 'Origin: https://fast.com'  "$next">>/tmp/fast.com.test.fifo; done)& done & pv /tmp/fast.com.test.fifo > /dev/null; rm /tmp/fast.com.test.fifo


This is cool; just ran it, but I couldn't tell that it was doing anything. Maybe adding some soft of indicator/throbber that lets you know it's processing.

  fast | cat
  860 Mbps


Why are you redirecting the output of the script which would otherwise be printed to a program that does nothing but print the output?


Best guess is because it's what the --help says to do if you just glance at it

  $ fast --help

  Usage
    $ fast
    $ fast > file

  Example
    $ fast | cat
    90 Mbps


It shows an animated spinner if you don't redirect the output.


Ah okay awesome! Thanks.


I am impressed that Phantom could do almost everything https://github.com/sindresorhus/fast-cli/blob/master/api.js#...


1. When will someone build a tool like this and then open up the measurements data? A speed-measuring tool would be infinitely more useful if we could investigate the results beyond just our one device for one test. A question I really want to be able to answer: which ISP offers the fastest service in my area? fast.com and speedtest.net could easily answer this question if they made the data available.

2. I think tests like this that rely on a built-out network and well-placed CDNs and such are probably junk. A more useful test would be against a handful of download targets that aren't optimized, and then average the results. This is particularly true for Netflix. Case in point: fast.com says I download at 78Mbps, but speedtest.net has me down around 57. I'm only paying for 30.


Re:#1, I'd like to see some type of software we can install in our stacks, to publicly publish speed data in a standardized format for real data. Can you imagine `test.youtube.com`, `test.netflix.com` and `test.vimeo.com`? Hell, imagine how nice it would be for gamers? Having trouble with your ping? `test.csgo.com` (or whatever CounterStrikes domain is.. a popular FPS), and etc.

I'm firmly untrusting of Comcast's results on speedtest.. If Comcast is intentionally throttling, it's in their interest to not throttle Speedtest. However if we can monitor real data.. that actually seems useful.

I understand that would likely require additional resources from video/etc providers, and is likely an unrealistic request from video/etc providers.. but i definitely don't need more test sites for Comcast to manipulate.

Disclaimer: I don't know the subject domain, so apologies if i'm insanely off base.


>I think tests like this that rely on a built-out network and well-placed CDNs and such are probably junk.

Depends on the goal - here Netflix wants to see how fast you can stream from their "built-out network and well placed CDNs" so testing those is completely relevant. For their purposes, testing a bunch of unoptimized and unrelated services would be "junk".


> here Netflix wants to see how fast you can stream from their [CDNs]

Absolutely right; but also in this case, Netflix' and the average downloader's needs align, given that the bulk (by share of bytes) of legal speed-sensitive downstream traffic is video.


Dslreports speedtest publishes the results publicly: http://speedtest.dslreports.com/


They appear to only publish it by ISP. Part of my problem is not knowing comprehensively what ISPs serve my area, so I need to look it up by zip code or city.


Google / YouTube has a 'Video Quality Report' which will measure your speeds and will also show local ISPs speeds as well.

https://www.google.com/get/videoqualityreport/


I don't see numerical speeds there, just a graph of how much SD and HD video is used across various ISPs in my neighborhood. Are you getting actual numbers like "100Mbps" from that report?


"Reports from your location are not available yet." Uh, I didn't tell you my location, Google... what the heck?


They can guesstimate by geolocating your IP.


The problem is I'm at work right now, and I wanted to get results for where I live not where I work. (Which might still be unavailable, given, but at least let me type it in!)


We display our data publicly on the map. http://www.broadbandspeedchecker.co.uk/broadband_speed_in_my...

Granted we do not have many results in the US (maybe ballpark 200k+ results in last 6 months), still you should be able to find some results in your area.


200k is a pretty good sample size is it not? Even with multiple providers.

Most election/political polls use far less data and very big decisions get made because of them.


Sample size is only a tiny part of the relevance of a sample. You can take a thousand gallons of water to test water quality, but if all of it is from the same faucet the sample isn't representative.


I don't see how that applies here though. How much variation is there among broadband users that matters?


RE #2: fast.com has me at 1/3 of what speedtest.net has me for download.


I see this as a tool for netflix to immediately raise concerns about ISP neutrality. The link to another speed test (using some minor server) is there not by chance. If speed test is far better than netflix fast.com the ISP is clearly limiting the customer.


I wish that my ISP (Comcast) would throttle Netflix in the evening. My internet bandwidth gets reduced to 200 kbps during prime time (roughly 9 to 11 PM). It makes it challenging to work, especially if I need to stay connected to a VPN.


If you were wishing, why not wish for your ISP to aptly judge its peek traffic and scale its infrastructure?


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?


I'm also experiencing the same (also using HTTPS everywhere). Disabling the extension doesn't seem to work.

If you get a solution, please let me know.


I found that Noscript was causing it.

The best solution is to go into Noscript options > advanced > HTTPS and add .netflix.com to "Never force secure".

The other way is to go into about:config and set noscript.httpsDefWhitelist to false. But that's less secure.


Ahhh! Thank you! That was my problem as well. I didn't even know NoScript was doing that. >:-(


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. :(


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 support, I discovered more or less by accident that if I enabled 6rd things "just worked" so the fact that it might not go at the full speed of my subscription isn't something I'm super worried about.

I've actually got a similar issue with Google. While using IPv4 I don't even leave my ISP's network as they have those Google Global Cache boxes at the edge and terminate my connection there but over IPv6 I do go all the way out over the internet to Google.


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


This does something good by providing a nice service for a common and difficult to answer question, and also seems like a smart strategic use of Netlix's resources.

The net result of applying their capital, engineering talent and existing infrastructure here: a positive recruiting impact for engineers, a positive branding impact for consumers visiting fast.com, and Netflix obtains information about internet speeds for IPs that are not currently Netflix customers, information that many businesses would find useful for things like determining the market for high bandwidth applications.


Hows this for a discrepancy https://i.imgur.com/7SX2Wro.png


I got 150 on Fast, and 120 on Speedtest. I think it just depends where the CDNs are in comparison to you.


That's nuts! Does that indicate that your ISP is playing games?

I get an insignificant discrepancy: 91 on Fast and 91.99 on Speedtest.


I get 72 (fast.com) vs 92 (speedtest)


You're on Centurtlink Fiber I see. I had a very similar experience with them. I switched back to biz class Comcast, which was far superior/faster in almost every area, even though ostensibly slower.


That's pretty dramatic. I wonder if they throttle, won't increase peering bandwidth and won't allow them to deploy an OCA within their networks like Verizon is/did? Could be that the connection is simply tapped out and they're trying to play hardball with Netflix. It is hosted on exactly the same infrastructure and served over the same network links after all.


This is a bit of an unfair test, as it is not in Netflix's best interest to provision enough CDN capacity for any user to hit 1Gbps, especially at peak times. Netflix wants to buy/provision just enough capacity so that users don't complain. Depending on the distribution of the users in the area, this could 5Mbps per user, or 15Mbps per user for a large amount of 4K streamers.

Netflix pushes their CDN nodes to the limit, 60-70Gbps per box for video. Speedtests don't make them money, so why provision capacity for it?


If they aren't going to act like a speed test server, they shouldn't advertise it. Not that netflix is the only potential weak link between the person and fast.com.


That's incorrect. I have AT&T Gigapower 1GB connection, and fast.com shows me 850-989 MB/s speeds.

It seems Netflix does shove info to you as fast as they can from fast.com


I'm not saying it isn't possible to ever hit 1Gbps (or whatever speed), I'm simply saying it is not in Netflix's best interests to make sure this is possible 24/7 365.

I have 1Gbps CondoInternet/WaveG at home, right now at 11PM PST I get ~400Mbps from Fast.com and 800Mbps+ from DSLReports and the Comcast/Xfinity speedtest.


FWIW, I just clocked in at 780 Mbps on fast.com.


Bastards!


My parents recently had 100mbps fibre installed, I told them to visit fast.com to test their speed and they were pleased at how easy it is to use and hassle free

Good work by Netflix.


I'm getting a consistent difference between fast.com in Safari on iPad vs their Fast app (90-ish vs 65-ish, across 5 interleaved trials). I was hoping for better measurement in the native app, but I suspect it might just be a web view in a native shell. Anyone else seeing similar results?

I think this is an interesting idea, but I'm not convinced it'll actually make a difference. From the consumer side, there's nothing to say that the slowest link isn't Netflix's CDN when a discrepancy occurs between Fast and Speedtest.

I was receiving atrocious download speeds for movies from iTunes (18+ hours for 4 GB), and also saw slow speeds from speakeasy.net/speedtest. The comcast rep just pointed me at Speedtest and said "it's not a problem with your connection, it's fast! Contact Apple." He dismissed the "other" speed testing results. ISPs can continue to throttle directly or by refusing to upgrade peering connections. fast.com providing a number to go along with bad Netflix streaming quality doesn't improve the customer's life.

What I really want is something that empowers me to be heard in my request for the $75 worth of Internet that I pay for every month. I had high hopes that the SamKnows program might yield something, until I received a docsis 3 cable modem in the mail from Comcast with a note: "since you're a participant in SamKnows monitoring, we sent you this upgraded modem so you can take advantage of better speeds". My first thought was "what about all of your customers who aren't participating in SamKnows? When do they receive their 'upgrades'?" Do we really need the government monitoring everyone's broadband performance to ensure that companies are delivering?


I wish people would believe this. I had an hour long fight with my ISP the other day - the customer support people are provided with a script that they have to follow, and I'm trying to tell them that the speed isn't as good as they claimed it was. It got to the point where I was sharing screen with them on TeamViewer to show them the download speed I was getting.

Their response? "We use SpeedTest.net as standard, it must be a problem with the servers that you are using".


I wonder if Netflix makes it as easy to apply for their local CDN nodes as google does with GGC. I know akamai is super difficult to apply for and get admitted.

Ever since Netflix became available in our country we have been hurting BW wise. We don't throttle BW for any sites. Does anyone here have any experience with open connect (Netflix)?


It doesn't seem terribly difficult so long as you have the traffic numbers to support it (peak traffic of 5gbps) and enough bandwidth for the box to fill its cache during off peak hours.

https://openconnect.netflix.com/en/requirements-for-deployin...


"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.


Speed testing is a good starting point, but on my LTE connection (rural area) I find the latency to be very contributor to overall experience. Especially that once the link is saturated the latency shoots through the roof (up to x10). I wish there were some tools for testing more complex use cases.


I'm working on an project to solve this type of issue. What we do is put test servers throughout your provider's network and then provide a browser frontend that will test your connection (throughput+latency) to each point on your provider's network on your way out to the Internet. I would love to come up with a way to do this without requiring the provider to install anything, but so far that doesn't seem technically feasible. One of the main problems is that so much of last mile networks is now layer 2, so traceroutes aren't particularly helpful at narrowing down the network segment causing the problem.

The good news is that many of the smaller providers (where they exist - maybe your LTE provider is one?) are very excited about adding something like this to their network. Where the incumbents would rather just hide problems from you to keep you locked in, the smaller providers are very motivated to keep you on their network. They're often overworked and resource strapped - so a system that will help them narrow down the source of network problems and reduce truck rolls is usually very exciting to them.


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.


Sounds like bufferbloat to me. Tried using smart queue management like fq_codel on your end? Or is it an overloaded LTE cell?


Not sure if bufferbloat, but happens across multiple machines and system versions (I can saturate the link with one machine, the others will still suffer). But it may be an issue with the LTE router. I don't think I can do anything about it as it is totally locked down by the ISP.


I'm largely using LTE these days for network access instead of wired and I have not yet encountered significant latency problems. You have a higher latency out of the box but it seems very stable. However LTE does QoS on a per device situation and it might be that the tower downgrades you if your link is not good enough.


Unfortunately, it doesn't work for me behind a proxy (tried with three different browsers). I thought I'd just check it out (https://fast.com - trying http redirects to https anyway), but it says:

"Could not reach our servers to perform the test. You may not be connected to the internet"

P.S.: It also bugs me that it says "the internet" and not "the Internet". :)


:D AP and other publishers don't recommend capitalising 'internet' and 'web'.

"The changes reflect a growing trend toward lowercasing both words, which have become generic terms"

http://www.poynter.org/2016/ap-style-change-alert-dont-capit...


Apparently my ISP upgraded my speeds; I tested at 170Mbps and when I last checked my plan it was 80Mbps.

In general, I've been quite happy with Cox. The actual network service is great. Customer service and pricing are so-so (I'm paying $60/mo. for the above connection; customer service is very hit-or-miss depending on which representative I get, but I haven't been outright lied to).


Several years ago I used this wonderful tool. http://software.internet2.edu/ndt/.

It provides the ability to do lots of troubleshooting in a private network.


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 https://github.com/apenwarr/blip - built by google fiber guys for exactly this.


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



Nice and I think they really benefit on their existing infrastructure.

But tests shows 5mbits for me and all other 30+ (real). So not really a great help till now.


What's stopping ISPs from slowing down other speedtests at the same rate as netflix to eliminate your ability to have a 'control'?


You can have any "control" you want by setting up your own "speedtest" mirror. It's hard to stop all of them.


Wouldn't your results show as being dramatically lower than your purchased speeds, then? That would backfire in a hurry :)


Great example of engineering as marketing.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: