Internet Speed Test: A Repeatable Method That Works

Three columns — date, download, upload — and one question ends the argument: which server?

A log built that way cannot answer it. It does not record which tool produced the number, whether the laptop was on a cable or across the room on Wi-Fi, or which machine at the far end the traffic was aimed at. Nothing in it has to be disputed to be set aside, because it describes an unknown path measured by an unknown method, and a support agent only has to say so. More rows do not fix that. They repeat it.

What follows is the log that survives the question, and why each part of it is there.

Four things to switch off before the first run

The measurement point is a laptop on an Ethernet cable in a LAN port on your gateway, with its Wi-Fi radio disabled. That is not a preference. The FCC's panel measures from a device wired into the home network for the same reason, and its Thirteenth Measuring Broadband America report spells out what wireless does to a result: "some Wi-Fi connections may be limited to tens of Mbps which would be the maximum achievable throughput to a specific device using that type of connection, independent of whether a consumer may subscribe to a service delivering; e.g., hundreds of Mbps to the home."

Before the first run, four things go quiet. Cloud sync and backups come first, on every machine in the house rather than only the one you are testing from: the panel establishes its idle latency connection "only when there is no other traffic detected in or out of the subscriber's home." Streaming is second, including the television nobody in the room is watching.

The other two get left half-done more often than not:

• The Wi-Fi radio on the test laptop, switched off at the operating system level. Carrying the laptop to the far end of the house is not the same thing, because the radio keeps associating and keeps sending.
• VPN clients, which put a second company's network inside your measurement and hand a support agent something true to point at.

Anything between the laptop and the gateway joins the test. A powerline adapter, a MoCA bridge, a switch in another room, a docking station with a slow adapter in it: each one is now a component under measurement, and each is something a provider can point at. One cable, one port.

Pin the server, and pin the same one tomorrow

Run two tools on every pass, because they answer different questions and a provider will lean on whichever one you left out.

Ookla's Speedtest CLI runs natively on Windows, macOS and Linux, reports download, upload, latency and packet loss, and writes CSV, JSONL or JSON, which is the only reason a month of automated runs is bearable to read. In version 1.2.0.84, the output of speedtest --help and the speedtest.md page shipped inside Ookla's own download list the four flags this method needs: -L, --servers prints the nearby servers with their IDs, -s, --server-id=# pins one of them, -f, --format=csv emits a single appendable row, and --output-header writes the column names once so the file is readable a month later. Run --help against your own build before scripting anything, because the flag set is not frozen across versions.

One trap sits inside that CSV. Ookla's documentation states that the machine-readable formats "use bytes as the unit of measure with max precision," and its own worked example turns 38,404,104 bytes per second into 307.23 Mbps by dividing by 125,000. Log a csv row straight into a column headed Mbps and every figure in the file is wrong by that factor, which is the sort of error that ends an argument in the provider's favor. Keep the raw value, convert in a separate column, and pin one server ID so the app never chooses again.

M-Lab's NDT7 is the other half. It opens a single TCP connection, runs about ten seconds, and does nothing else. Every result it produces becomes open data rather than living only in your browser history, and that cuts both ways: the consent line on the test page has you agree to a data policy which "includes retention and publication of IP addresses."

Why both, in one paragraph of numbers: the peer-reviewed comparison of the two tools published in the Proceedings of the ACM on Measurement and Analysis of Computing Systems in March 2023 found Ookla opening as many as eight TCP connections once round-trip time passed 100 ms, and stretching its median test length from 3.5 seconds at 0 ms to 11 seconds at 100 ms and 15.7 seconds at 600 ms, while discarding low throughput samples before reporting. NDT7 held to one connection and to 9.5 or 10 seconds throughout. The same study found 43.4 percent of households showing a statistically significant drop in NDT7 download speed during peak hours, against 18.9 percent for Ookla. Two tools, same minute, different answers, both defensible.

Server choice is not neutral either. That study saw 8 of its 10 most-used Ookla servers co-located inside consumer or enterprise ISP networks, and median normalized speeds that varied by server: 0.91 at one provider's server against 0.99 at another. If the server you pinned belongs to your own provider, your test never crosses the point where its network hands your traffic to anyone else. The FCC deliberately avoids that. Its measurement servers are third-party operated, sit near interconnection points, and its methodology allows "a maximum of two interconnection points and one transit network" on the test path in either direction. Pin one server inside your provider and one outside it if the list lets you, and label every row with which was which. A good on-net number beside a bad off-net number is not a broken test. It is a finding about interconnection.

Twenty-eight runs is the smallest log worth sending

One test proves nothing about a line that misbehaves at 9 p.m. Copy the federal cadence instead of inventing one.

The Thirteenth Report, built on validated data collected in September and October 2022, sets the panel cadence: download and upload tests run "once per hour during peak hours (7 p.m. to 11 p.m.) and once during each of the following periods: midnight to 6 a.m., 6 a.m. to noon, and noon to 6 p.m." Peak is defined precisely: "weeknights between 7:00 p.m. to 11:00 p.m. local time at the subscriber's location."

The home version, four runs a day for seven consecutive days:

That is 28 runs, and the seven days should include the weekend, which is what makes a weeknight pattern visible rather than merely asserted. Schedule them. Task Scheduler on Windows, cron or launchd elsewhere. A log with gaps exactly where you were busy invites the reading that you tested only when it looked bad.

Do not delete outliers. Report the median rather than the mean, as the FCC does, and keep every run.

Every row carries its own method

Every column below exists to answer a question that can otherwise be asked of the log. Here is all of it, one row per run:

timestamp_local, tool, tool_version, server_name, server_id, on_net_or_off_net, link_type, nic_negotiated_rate, download_mbps, upload_mbps, idle_latency_ms, loaded_latency_ms, packet_loss_pct, notes

The two _mbps columns are converted values, since the csv the tool writes is in bytes per second; whatever it wrote goes into the raw file untouched. The notes field earns its place. "Neighbor's party." "Storm." "Kid gaming upstairs." "Modem resynced at 20:14." The entries that admit to interference are the ones that make the rest of the file credible.

Two columns people skip and then regret. nic_negotiated_rate is what your Ethernet adapter actually linked at, and a port that quietly came up at 100 Mbps explains a disappointing result better than any theory about the provider. on_net_or_off_net answers the agent's question before he asks it.

Keep the raw output as well as the table. Speedtest CLI's JSON carries the server hostname, the ISP name and its own result URL. A summary with the raw files behind it is a different document from a summary alone.

Throughput, latency and loss are three separate questions

A speed test answers one of them, and only for the path it tested.

Throughput is how much bulk data moved across one path during a few seconds, using one tool's flooding method. It is not "your speed," and two honest tools disagreeing by 20 percent is ordinary rather than evidence of tampering. The Thirteenth Report keeps only "the upload speed measured in the last five seconds of the 10-second interval," which is a useful reminder that where in a test you sample changes the answer you get.

Latency splits in two. Idle latency is measured with the line otherwise quiet. Latency under load is measured while the speed test is saturating the link, at ten packets per second in the MBA method. The Thirteenth Report's finding on the second one is flat: "the latency under downstream traffic load generally is significantly higher than idle latency." Record both whenever the tool reports both.

Packet loss is a count against a timeout, not a feeling. That report counts a probe lost when no response comes back within three seconds. Loss is also the number most likely to be blamed on your side of the wall, which is why the wired control matters more here than anywhere else. Finding where loss comes from is a different procedure from measuring how much there is, and the twenty-minute Wi-Fi-or-line diagnosis is where that work belongs.

Then there are ceilings that belong to your own equipment. Appendix A of the Thirteenth Report normalizes gigabit-tier results to 940 Mbps, "the maximum speed of Gigabit Ethernet at the transport layer of the Whitebox 8.0 used in these tests," and the medians it reports against that figure run from 89 to 94 percent. A 1 GbE port cannot produce a four-figure number no matter what the plan costs. That is your ceiling to disclose, in the row, before somebody else finds it for you.

What "typical" means on your label, and what it does not

Your log is only an argument if it lands against something the provider published, and the label is that thing.

Under the 2022 broadband label order, published at 87 FR 76959, providers must display typical download and upload speeds and typical latency. How they arrive at those figures is looser than the word suggests. Providers in the MBA panel "may disclose their results as a sufficient representation of the actual performance their customers can expect." Providers outside it "may use the methodology from the MBA program to measure actual performance, or may disclose actual performance based on internal testing, consumer speed test data, or other data regarding network performance, including reliable, relevant data from third-party sources."

Two absences matter as much as the numbers. The Commission declined to require that label speeds be reported for peak periods, finding "no consensus on how to define peak at this point." And packet loss was left off the label entirely, on a record that consumers had "little understanding of what packet loss involves." So the typical figure is not a promise about 9 p.m., and your loss column has no label field to sit against. It rides on the transparency rule instead, which requires accurate disclosure of network "performance characteristics."

Borrow the Commission's own consistency framing when you write the summary page. The 80/80 metric in the Thirteenth Report measures "the minimum percentage of the advertised speed experienced by at least 80% of subscribers for at least 80% of the time over peak periods." You have exactly one subscriber, so the household version is a single sentence: across N peak-window runs over seven days, at least 80 percent of them delivered at least X percent of the typical download speed shown on the label dated D, and X is the number in dispute. That sentence does the work the Commission's chart does, in the vocabulary the Commission uses.

Getting hold of the label without wading through a sales funnel is covered in the early termination fee post, since the same document carries both numbers.

Two label documents to pull, and a deadline that is not a date

Two of the duties that make this evidence collectable are already condemned. Neither has an execution date, which is a harder thing to plan around than a deadline.

As the rule reads in the eCFR text of 47 CFR 8.1 — the 20 August 2026 issue, current as of a 22 August 2026 reading — providers must still publish label contents "separately in a spreadsheet file format on their websites via a dedicated uniform resource locator (URL) that contains all of their labels," which is paragraph (a)(3). Paragraph (a)(5) still requires them to archive every label for at least two years after the plan stops being sold, and to hand an archived label to the customer whose plan it describes "upon request and within thirty days."

Both duties are on the way out. The FCC order Empowering Broadband Consumers Through Transparency, FCC 26-48, published at 91 FR 52251 on 13 August 2026, eliminates the machine-readable spreadsheet requirement and the archiving requirement. On the second one the Commission adopted NTCA's characterization from the record, that the enforcement rationale for the rule was "based on speculative future utility in complaint proceedings."

When the deletions bite is a question the amendatory instructions answer and the summary does not. Instruction 3, which carries the removal of paragraphs (a)(3), (5) and (7), is carved out of the effective date and "delayed indefinitely," to be set later by a document the Commission has yet to publish. What actually lands on 14 September 2026 is instruction 2, a rewrite of paragraph (b) that adds a definition of the "passthrough fee." Notice the split that creates: the definition arrives on time, while the label provision that spends it — the permission to present those fees as one aggregated figure, along with the conversational phone-sales summary and the reworked point-of-sale wording — sits in instruction 3 and waits alongside the two deletions.

For a household building a file, that is the awkward shape. There is no countdown to watch, no notice period anyone has promised, and nothing on a provider's website that will mark the morning its spreadsheet URL stops being maintained. So do it while the paragraphs are live: download your provider's label spreadsheet from its published URL and keep the file with the date you fetched it, screenshot the label in your account portal, and if your plan changed in the last two years, ask in writing for the archived label for the plan you were on. That thirty-day clock is enforceable today under a paragraph with a removal order already written against it.

One duty the Commission expects to survive is the portal copy. It leaned on that copy, along with service agreements and billing statements, when it reasoned that deleting the archive would not strip subscribers of their plan information. Useful, but narrow: the portal shows the plan you are on now, which is exactly not the document you need when the argument is about the plan you were sold two years ago.

What twenty-eight rows prove, and what they do not

The finished log proves a narrow thing well. On these dates, at these hours, from a wired machine in a quiet house, the path from this gateway to these two named servers delivered these numbers, measured by two named tools using two different methods. That ends "it must be your Wi-Fi" on the first reply, and it lets you make one specific claim against one specific published figure instead of a general complaint about being slow.

It does not identify a cause. A shared segment at capacity, a congested interconnection port, a failing amplifier and a transit route having a bad month all look much the same from a laptop. It does not prove a breach, because a typical speed is a disclosure rather than a service level, and your agreement almost certainly says so somewhere. And it says nothing about how any particular application behaves, which the FCC excludes from its own reports on the ground that performance depends "not only on the network performance (i.e., raw speed, latency, or packet loss), but also on the application's architecture and implementation."

The narrowness is the strength. A claim that stops exactly where its evidence stops is hard to wave away, and what follows is procedural rather than technical: open a written ticket citing the log and the label together, get a ticket number, and if two visits change nothing, the billing dispute ladder sets out the rungs and the clocks that come after.

Start the file tonight with a header row and one wired run at 8 p.m. Twenty-seven to go.