Measuring Slow: The Numbers to Collect Before Anyone Touches Anything

Wednesday, 11:15, at Harbourview Clinic. Greg, the practice manager, is standing at the desk rather than raising a ticket, which he does when he wants something done rather than recorded. "The internet's been dreadful since Monday. Reception can't load the appointment system, the scanner uploads are timing out, and I rang the provider myself and they said the line is fine. Can you just reset the router?" Sofia has been on the desk a year and has reset the router before, on a morning very like this one. That reset made no difference that anyone could prove, because nobody had written down what "dreadful" was before she did it. She asks Greg for ten minutes. He gives her five. She uses them to take four numbers.

Measuring slow means taking a small set of repeatable numbers about a connection, from known places on known devices at known times, before anything is changed. That way, "slow" becomes a figure that can be compared with yesterday, with the next desk, and with what the connection is supposed to deliver. Without the numbers, a fix is a guess, the provider is an argument, and "better now?" is the only test anyone has. With them, the desk can prove where the problem is, hand it to whoever owns that piece, and know afterwards whether anything changed. This article is part of our The Internet Is Slow series. The isolation frame in the first article decides which branch a complaint is in. This article is what the network branch does next, and it owns the method and the evidence sheet the other articles point to.

It covers why the numbers come before the fix, the three numbers in plain words, and taking them from the device and from a known-good device. Next come wired and wireless as two different tests, the time of day and the repeatable test, and what the connection is supposed to be. Then it covers the evidence a network owner or provider will accept, and the numbers that lie. A short war story and the evidence sheet to copy finish the article.

Why the Numbers Come Before the Fix

The reflex when someone says the internet is slow is to change something. The reflex is wrong for a reason that has nothing to do with caution. A change made before a measurement cannot be judged. If Sofia resets the router and Greg says it seems better, nobody knows whether it is better, whether the lunchtime lull did it, or whether Greg is being kind. If she resets it and Greg says it is the same, nobody knows whether the reset did nothing or whether two things were wrong and one is now fixed. The measurement is not paperwork before the work. It is the only way to tell whether the work worked.

The numbers also decide who the ticket belongs to, which is the practical point for a small desk. A connection that measures badly at the wall where it enters the building is the provider's problem. In that case, the desk's job is evidence and a phone call. A connection that measures well at the wall and badly at reception is the building's problem, which is the network owner's. In that case, the desk's job is to say where the loss happens. A connection that measures well everywhere while the appointment system crawls is not a connection problem at all. In that case, the one-service article takes over. Three outcomes, three owners, and the numbers are what sort them. Nobody has ever won an argument with a provider by describing the mood in reception.

Finally, the numbers are cheap, which removes the last excuse. A speed check takes under a minute. Taking it from two devices in two places takes five. Taking it three times a day for three days takes a quarter of an hour of someone's attention spread across a week, most of it the requester's own if you ask nicely. Against that, a router reset that fixes nothing costs the building a minute of connection and the desk its credibility. A call to the provider with no numbers costs forty minutes and ends with "the line is fine".

The Three Numbers in Plain Words

A connection is described by three numbers. A speed check is any test page or built-in tool that measures them by sending data to a test server and back. Download speed is how fast data arrives at the device, measured in megabits per second. It is the number people mean when they say "speed". Web pages, video, the appointment system's screens and the files people open all depend on it. Upload speed is how fast data leaves the device, in the same units. It is nearly always much lower than download on an ordinary office connection. Scanner uploads, video calls (your picture going out), cloud backups and sending large files all depend on it. It is the number most often forgotten when a connection is bought.

The third number is round-trip time, often called latency or ping: the time in milliseconds for a tiny message to reach a server and come back. It is not speed. A connection can have a fine download figure and a terrible round-trip time. In that case, the person on it will say "slow" because every click waits a beat before anything happens. Voice and video calls, remote desktops and applications that chat with a server on every keystroke care about round-trip time far more than about megabits. Beside it sits steadiness: whether that round-trip time is the same from one second to the next, and whether every small message arrives at all. Messages that get lost and must be re-sent are called packet loss, and a connection with loss feels jerky and unreliable even when its averages look fine.

Which number matters depends on what the requester was doing, and this is where the isolation card's "what exactly is slow" pays off a second time. Pages and downloads: download speed. Scanner uploads timing out: upload speed. The appointment system hesitating between clicks: round-trip time and loss. A video call freezing: upload speed, round-trip time and steadiness together. A speed check reports the first three directly and most report loss or steadiness too. Where yours does not, the pattern of the round-trip figure over a few runs says most of it. Take all three every time, because the one you skip is the one the provider will ask about.

From the Device, Then From a Known-Good Device

Take the first reading from the requester's own device, at their own desk, doing the test the way they would. That is because the reading is their experience in numbers and it is the one they will recognise. Note the device, where it is, whether it is on wireless or a cable, and what else it was doing at the time. A laptop that is uploading a backup while the test runs will report a dreadful upload figure, truthfully. The reading is still worth having as long as the note says what else was running. The first reading is the complaint, written down.

Take the second reading from a known-good device, the spare laptop the desk keeps clean, updated and trusted for comparisons. Take it at the same desk, on the same connection, within a few minutes of the first. If the two readings agree, the device is innocent and the connection at that spot is what it is. If the known-good device reads well while the requester's reads badly, the ticket has just left the network branch and become a device ticket. The first article in this series and the hardware diagnostic order handle that ticket. Two readings at one desk settle the single largest question in the frame, and most desks skip the second one because the first looked conclusive. It never is.

Take the third reading from as close to where the connection enters the building as the desk can get. Use the known-good device with nothing else running, at a wired port next to the firewall or the provider's equipment. This is the reading that says what the provider is actually delivering, with the building's own wiring and wireless taken out of the argument. If the readings at the wall are good and the readings at reception are bad, the loss is inside the building and belongs to the network owner. If the readings at the wall are bad, the provider's "the line is fine" has met a number taken from the wire, and the conversation changes.

Wired and Wireless: Two Different Tests

A wireless reading and a wired reading at the same desk are measurements of two different things. Recording which one you took is as important as the figure. The wired reading measures the building's network and the connection beyond it. The wireless reading measures all of that plus the radio between the device and the ceiling. That radio has its own weather: distance, walls, the number of people in the room, and the device's own choices about which access point to talk to. A wireless reading that is a fifth of the wired reading at the same desk is not a slow connection. It is a slow last twenty metres, and the Wi-Fi complaints article owns what happens next.

So take both where you can. Plug the known-good device into the wall port at the requester's desk, or the nearest one, and test. Then unplug it, let it join the wireless, and test again from the same chair. The pair of numbers tells you in one glance whether the wireless is the problem, whether the wiring is the problem, or whether the connection itself is. A desk with no wall port nearby has lost the comparison at that desk. In that case, the next best is the wired reading at the wall, which still separates the provider from the building. The one thing never to do is compare a wired reading on Monday with a wireless reading on Wednesday and draw a conclusion. The two will differ, and the difference means nothing.

The Time of Day and the Repeatable Test

A single reading is an anecdote with units, and the number that convinces anyone is a pattern over time. Connections are shared, and the sharing changes through the day: the nine o'clock sign-in rush, the backups that start at seven, the lunchtime video, the four o'clock file sends. A reading at 07:30 on an empty office says what the connection can do. A reading at 11:00 says what it does with everyone on it. Both are true, and a complaint that says "since Monday" needs the 11:00 figure from Monday, Tuesday and Wednesday beside the 07:30 one to mean anything.

The repeatable test is one test, done the same way every time. Use the same known-good device, the same spot, and wired or wireless (not sometimes one and sometimes the other). Use the same speed check pointed at the same test server, with nothing else running on the device. Change any one of those and the readings are no longer comparable. Write the time beside each reading. Three readings a day, morning, mid-morning and mid-afternoon, for three working days, is the smallest set that shows whether the problem is constant, follows the clock, or came and went. That is fifteen minutes of attention in total. It is the difference between "it's been slow" and a line of numbers the provider cannot wave away.

Ask the requester to help with the time-of-day readings, with the test written down for them step by step and a place in the ticket to put the figures. Most people will do it gladly, because it is the first time anyone has asked them for evidence rather than patience. The slowness series uses the same idea for computers and applications, where the measurement is a stopwatch on a task rather than a speed check. The principle is identical, and a desk that learns it for connections has learned it for everything. A feeling cannot be compared with Tuesday. A number can.

What the Connection Is Supposed to Be

A reading needs something to be compared against, and the first comparison is what the organisation is paying for. Somewhere there is a contract with the provider. On it is a download figure and an upload figure, in megabits per second, usually with a word like "up to" in front of them. Find it. Put it in the evidence sheet. At Harbourview the contract said one hundred down and twenty up. Until Sofia dug it out of a folder, nobody on the desk had known either number. That meant nobody could have said whether forty was dreadful or fine.

The second comparison is the connection's own normal, which is the set of readings taken on a day when nobody was complaining. A desk that takes a wired reading at the wall once a month on a quiet morning, and keeps it, has a baseline. Without one, the first measurement is taken during the complaint and there is nothing to set it against except the contract. Harbourview's wired readings at the wall on Wednesday were ninety-four down, nineteen up and nine milliseconds at 07:30, and ninety-one, eighteen and eleven at 11:00. Against a contract of one hundred and twenty, that is a healthy line. Reception's wireless reading at 11:00 was twelve down, four up and fifty-eight milliseconds, with the scanner mid-upload. Reception's wired reading from the same chair was eighty-eight, eighteen and ten. The connection was fine. Reception's wireless was not, and the scanner was eating what little of it there was.

The third comparison is sharing. A connection of one hundred megabits is not one hundred for each person. It is one hundred for the building, divided among whoever is using it at that moment, unevenly, in favour of whoever is moving the most. Sixty people reading mail barely touch it; four people uploading scans and one watching a training video can flatten it for everyone. This is the sizing question. Whether the organisation's connection is the right size for the organisation is a decision for whoever pays for it. The desk's contribution is the readings at busy times, which are the only honest evidence of whether the pipe is full. A contract figure is a ceiling. The 11:00 reading is the floor people live on.

Evidence the Network Owner or the Provider Will Accept

Whoever you hand the ticket to will ask the same six questions, and the evidence sheet exists so that the answers are already there. Which device, and was it a trusted one. Wired or wireless, and if wired, into which port. Where in the building. What time, and over how many days. Which speed check and which test server. What else was running on the device and, roughly, in the building. A provider's support desk, in my experience, will take a line of wired readings from the wall at known times seriously. It will take "my practice manager says it's dreadful" as an invitation to say the line is fine.

Readings taken through anything that is not the plain connection weaken the evidence and must be labelled. A test run while the device is on the VPN measures the VPN. A test run through a web filter that inspects traffic may measure the filter. A test run on wireless at one bar measures the radio. None of these readings is useless, but each one answers a different question. A sheet that mixes them without saying so will be picked apart in a minute by anyone who knows what to ask. Note the path the test took. Where the desk cannot get a plain wired reading at the wall, say so, and say what the nearest reading was taken through.

Keep the evidence in the ticket, not in a spreadsheet on someone's desktop, because the next episode will want it and the person who took it may be on leave. Each reading goes in as a line with its time and its conditions. The sheet at the end of this article is the format. If you run QuerySolv, each reading added as an internal note takes its place in the ticket's event history. So a month later, in that setup, the sequence of what was measured and when is still readable without anyone having kept a separate log. In any tool, the test is whether a stranger can see the readings in order and tell wired from wireless. A photograph of the speed check result pasted into the note is acceptable evidence; a memory of it is not.

The Numbers That Lie

Speed checks are honest about what they measure and silent about what they do not. A desk needs to know the four ways a reading misleads. The first is the busy device. A laptop running a backup, a sync or an update while the test runs will report a bad figure that belongs to the device, not the connection. That is why the known-good device with nothing running is the reference and the requester's own reading is only the complaint. The second is the far test server: a speed check that picks a server on another continent reports the round-trip to that continent. The download figure will suffer for it. Use the provider's own test page where one exists, or the server the network owner nominates, and use the same one every time.

The third is the wireless reading presented as the connection. A figure of twelve megabits at reception sounds like a line problem until the wired reading from the same chair says eighty-eight. A technician who rings the provider with the twelve will be told, correctly, that the line is fine. That technician will have spent the desk's credibility on a radio problem. The fourth is the single reading. One bad figure at 11:00 on Wednesday proves that 11:00 on Wednesday was bad. It does not prove a fault, a trend, or a cause. A provider who has seen a thousand single readings will treat it as the anecdote it is. Three days of three readings is the smallest thing that cannot be dismissed.

A Short War Story: The Line That Was Fine at Northgate Retail

At Northgate Retail's distribution office, a technician called Beatriz spent most of a month on a ticket from the stock team saying the internet had been slow since the spring. She did what the previous technician had done. She rang the provider, who ran their test and said the line was fine. She reset the office router twice, which gave the stock team a fresh excuse each time and changed nothing. On the fourth call the provider's engineer asked what she was measuring the line with, and from where. She realised she had never measured it at all. Every figure she had was the stock team's description of how long a stock sheet took to open. She borrowed the desk's spare laptop and plugged it into the port beside the provider's equipment at 07:30 and again at 11:00 for three days. She wrote the figures on the ticket: a steady ninety-two down and eighteen up at the wall, every time, against a contract of one hundred and twenty. Then she carried the same laptop to the stock office and got nine down on the wireless and eighty-six on the cable from the same desk. The fault had never been the line. It was a single access point serving twenty-six people in a room that had been built for eight. The cost was a month of a four-person stock team working at a crawl and two router resets that took the building offline for nothing. It also included four calls to a provider who had been right all along, and one apology. The lesson Beatriz wrote on the ticket was that the provider's "the line is fine" was a measurement, and hers had been a feeling. The lesson also said the provider had won because only one side had brought a number.

The Evidence Sheet

The sheet below is the internal note for any slow complaint that has reached the network branch. It is filled in before anything is touched. Section A fixes what the connection is supposed to be and the test that will be used throughout, so that every later line is comparable. B is the three readings at the first visit: the requester's device, the known-good device at the same desk wired and wireless, and the known-good device at the wall. C is the time-of-day log, three readings a day for three days, which the requester can help with. D is the reading of the pattern and the handoff. Every figure carries its time and whether it was wired or wireless. A figure without those two things is not evidence and should not be written down.

SLOW CONNECTION — EVIDENCE SHEET
Ticket: ________   Requester: ______________   Location: ______________   Started: ________

A. THE REFERENCE (fill once)
   Contract figures: ____ down / ____ up (megabits per second)   Provider: ______________
   Speed check used: ______________   Test server: ______________ (same every time)
   Known-good device: ______________   Baseline from a quiet day (wired, at the wall): ____ / ____ / ____ ms

B. FIRST VISIT (within minutes of each other; nothing else running on the known-good device)
   Reading                               Down   Up    Round-trip   Loss   Wired/Wireless   Time   Also running
   Requester's device, their desk        ____   ____  ____ ms      ____   ______________   ____   ______________
   Known-good, same desk, cable          ____   ____  ____ ms      ____   wired            ____   nothing
   Known-good, same desk, wireless       ____   ____  ____ ms      ____   wireless         ____   nothing
   Known-good, at the wall, cable        ____   ____  ____ ms      ____   wired            ____   nothing
   Path notes (VPN on? filter? which port?): ______________________________

C. TIME-OF-DAY LOG (same device, same spot, same test, same server)
   Day       07:30            11:00            15:30
   Day 1     ____/____/____   ____/____/____   ____/____/____
   Day 2     ____/____/____   ____/____/____   ____/____/____
   Day 3     ____/____/____   ____/____/____   ____/____/____
   Taken by: ______________   Wired [ ]  Wireless [ ]   Spot: ______________

D. THE PATTERN AND THE HANDOFF
   Bad at the wall ................................ provider; call with B and C attached
   Good at the wall, bad on the cable at the desk . building wiring; network owner
   Good on the cable, bad on wireless, same desk .. Wi-Fi; coverage, congestion or device
   Good everywhere on the known-good device ....... requester's device; device checks
   Good everywhere, one service still slow ........ one service; far end or filter
   Follows the clock .............................. sharing or a scheduled job; sizing question
   Result: ______________   Handed to: ______________ at ________   Nothing touched: [ ]
   Change made later: ______________ at ________   Readings after the change: ____/____/____

Sofia's five minutes produced the four readings in section B. The sheet told Greg what he had not wanted to hear and could not argue with. The line was fine, reception's wireless was not, and the scanner was uploading over it. A cable to the reception desk and a word with the network owner about the access point in the waiting room closed the ticket. Greg, to his credit, took the sheet to the next practice meeting and asked why nobody had known the contract figures. Nobody had an answer. The sheet now lives in the knowledge base with the figures filled in.

Frequently Asked Questions