Building fast.com • Hacker News Board

Re: Building fast.com

#111

Post by sergiotapia » Tue, Aug 09, 2016, 10:32 PM UTC

virtuallynathan wrote: post #88

Citrus2fizz wrote: post #74

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

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

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

Re: Building fast.com

#112

Post by corobo » Tue, Aug 09, 2016, 10:44 PM UTC

mi100hael wrote: post #98

joeblau wrote: post #49

Earlier quoted context omitted.

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

Re: Building fast.com

#113

Post by zeta0134 » Tue, Aug 09, 2016, 10:49 PM UTC

JoshTriplett wrote: post #104

a1k0n wrote: post #94

Earlier quoted context omitted.

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.

Re: Building fast.com

#114

Post by manish_gill » Tue, Aug 09, 2016, 10:51 PM UTC

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

Re: Building fast.com

#115

Post by mshenfield » Tue, Aug 09, 2016, 10:52 PM UTC

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.

Re: Building fast.com

#116

Post by fidz » Tue, Aug 09, 2016, 10:59 PM UTC

mofle wrote: post #17

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

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

Re: Building fast.com

#117

Post by jdavis703 » Tue, Aug 09, 2016, 11:00 PM UTC

corobo wrote: post #109

IshKebab wrote: post #73

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.

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

Re: Building fast.com

#118

Post by figgis » Tue, Aug 09, 2016, 11:17 PM UTC

thecosas wrote: post #100

figgis wrote: post #91

Earlier quoted context omitted.

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?

Re: Building fast.com

#119

Post by scrollaway » Tue, Aug 09, 2016, 11:19 PM UTC

jdavis703 wrote: post #117

corobo wrote: post #109

Earlier quoted context omitted.

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.

Re: Building fast.com

#120

Post by mrb » Tue, Aug 09, 2016, 11:27 PM UTC

cocoflunchy wrote: post #20

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.

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.