Slashdot Mirror

https://www.measurementlab.net... has some good tests. Sadly, some of old Net Neutrality tests have died there - but some of their stuff remains and is good. Back when this fight started, Google backed some groups working to make speed tests that detect if specific slowing was going on - all those tests are at this site - even though the public servers behind them are offline now. Cheers.

The new fast.com site test seems too short. Cox will give you more bandwidth than you're paying for for a few seconds (I'm on Cox) - to speed up bursty use like general web browsing, but slow down large downloads. You can see this on the speedtest.net tests. I'm on a 100 Mbps plan and it initially starts at around 160 Mbps, then gradually decreases, usually finishing around 110 Mbps. So fast.com is reporting your burst speed, not your sustained speed.

I've started using internethealthtest.org more. It runs separate tests to major backbone providers. Usually one or two are slower (often a lot slower) than your connection speed, indicating a bottleneck on the route your ISP uses to their networks. This is often the cause of some sites being fast while others are slow. You can also compare different ISPs in your area using MLab's Observatory tool.

Yes, the article referenced doesn't point to the actual study directly, a but with a bit of goggling I found:

• Some results here: http://www.measurementlab.net/observatory.
• You can add to the measurements by clicking this link: https://www.battleforthenet.com/internethealthtest/, which says:

  The battleground — where this degradation takes place — is at ISP interconnection points. These are the places where traffic requested by ISP customers crosses between the ISP’s network and another network on which content and application providers host their services.
  This test measures whether interconnection points are experiencing problems. It runs speed measurements from your (the test user’s) ISP, across multiple interconnection points, thus detecting degraded performance.

What I don't understand is why people assume congestion is intentional throttling by ISPs for them to profit later with imagined fast lanes. Isn't the simpler assumption that it costs ISPs money to add interconnection capacity. And since their customers don't/can't choose ISPs based on the quality of their connection all the way to the popular content providers, the ISPs don't spend money on those upgrades? Usually the only thing customers have to go on and promised is the maximum download/upload speeds quoted by the ISP for the last mile.

http://www.measurementlab.net/...

Unfortunately, the number of ridiculous hoops you need to go through to let an unsigned Java applet run an arbitrary network I/O makes it much less useful.

They now have a Flash version as well, so it's easier. But the numbers appear really low, claiming that my network buffer limits download to 140Mbps, yet I have often downloaded actual files from the Internet at faster than that.

OTOH, all the Ookla-powered sites claim I get over 70% of my 1Gbit network card speed, which I also find hard to believe, despite having a 20Gbps connection to our ISP (with literally thousands of users, one of which is a server I maintain that downloads at over 2000Mbps 24/7 backing up a remote site).

.
http://www.measurementlab.net/...

Runs on OS-X, Windows, Linux. Port available on FreeBSD.

The Network Diagnostic Test was able to see performance problems on my cablemodem connection that Ookla's speedtests did not.

http://www.measurementlab.net/...

Unfortunately, the number of ridiculous hoops you need to go through to let an unsigned Java applet run an arbitrary network I/O makes it much less useful.

There's a selection of various tests for various types of throttling you don't have to use the Java one... http://www.measurementlab.net/... - it's also a very well known and trusted site http://www.measurementlab.net/...

There's a selection of various tests for various types of throttling you don't have to use the Java one... http://www.measurementlab.net/... - it's also a very well known and trusted site http://www.measurementlab.net/...

http://www.measurementlab.net/

Ya that actual statement in the article doesn't make sense at face value, but this AC brings up a semi-valid point that if the the OnLive user is banging into an ISP's over-sub limits, then the end user will perceive higher-latency as TCP does the whole 're transmit thing' or UDP packets get dropped at a rate-limiter.. or in the best case, the packets funnel through a QoS Queue or something.

I guess it's time Onlive hops subscribes to more use of NDT services (like the Google approved Measurement Lab)