[123673] in North American Network Operators' Group
Re: FCC releases Internet speed test tool
daemon@ATHENA.MIT.EDU (Fred Baker)
Fri Mar 12 16:11:06 2010
From: Fred Baker <fred@cisco.com>
In-Reply-To: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv>
Date: Fri, 12 Mar 2010 13:10:26 -0800
To: Marshall Eubanks <tme@americafree.tv>
Cc: "nanog@nanog.org list" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail-484-210734633
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Mar 12, 2010, at 5:43 AM, Marshall Eubanks wrote:
> http://www.broadband.gov/
I'm listening to all this and thinking through the questions the FCC =
might be asking. I'm also trying to do a somewhat-controlled test, which =
I'll give you the first several samples of. See attached.
I picked up your note at ~7:10 PST this morning and set up some timed =
commands to remind myself to try this out once an hour at a few minutes =
before my various meetings start. I'm testing speakeasy against =
speedtest against the two broadband.gov engines, plus pingtest just for =
fun. I am of course at work today, woking from home.
For the record, I am a Cox Business subscriber, and my contract is 2 =
MBPS down and 384 KBPS up. That implies I'm not going see tens of MBPS, =
and I would be surprised if the numbers were significantly different =
than advertised as I am by definition paying more money for less =
service. Some of the tests will run in parallel with my daily workload, =
and I'll try to keep that straight. What may impinge is mail downloads, =
which happen under the hood and aren't necessarily visible at the time I =
initiate a test.
An observation on the various comments that "going to a test service =
operated somewhere other than my POP is a dumb idea": it depends on what =
you're measuring. If you're measuring, as I imagine those commentators =
are, what bit rate is available on the link between the residential =
subscriber and the ISP and therefore whether the contract is being met, =
the point is well taken. If the point is "what is a reasonable =
expectation of bandwidth when accessing various things on the Internet", =
the ISP's internal connectivity, connectivity to its upstream, and to =
its peers is also relevant - and from an FCC Net Neutrality perspective =
pretty important. A fairly common report several years ago was that on =
DSL networks one might get a high rate through the very last mile but =
often got mere tens of KBPS through the back end network, and DSL =
marketing made the same comment about Cable Modem networks. When I buy a =
certain rate from an ISP, the point is not to talk with the ISP at that =
rate; the point is to be able to do what I do, such as running a VPN =
across <ISP> and <upstream> to/from <company>, or access content on the =
web.
Another observation: when a subscriber buys a bit rate, the bit rate =
includes IP headers, link layer overhead, etc. If I use FTP to test my =
rate, it is measuring the rate at which TCP can deliver user data, which =
is to say that it omits the TCP, IP, and link layer overheads, which are =
on the order of 3-4% of the bandwidth. If I were running one of these =
tests over a circuit switch link such as a T-1, it would not measure =
that it was delivering 1.544 MBPS plus or minus 75 ppm; it would measure =
somewhat less considering both physical layer overheads (2/193 gets lost =
out of a T-1 frame) and TCP/IP overheads.
What I have seen so far this morning is that speakeasy, speedtest, and =
the two broadband.gov sites come up with about the same numbers, modulo =
obvious issues of being different tests at slightly different times. The =
one difference there is with broadband.gov/MLAB: it seems to measure my =
upload rate at about half of contract rate the first time I test it, and =
then measure something approximating the contract if I repeat the test. =
No idea what that really means - if it randomly was high and low I could =
argue that it is a capacity-at-tester or "did POP download email?" =
issue, but since it always the first test that is low it suggests =
something relevant to the sequence.
--Apple-Mail-484-210734633--
