NetDiag+
Evidence your provider cannot wave away
"My internet is slow in the evenings" is a feeling, and support is trained to answer feelings with a modem reboot. A number with a place and a time attached is a different conversation: packet loss starts at your third hop every night after nine, here are the runs. Three measurements do that job — where the loss begins, how latency behaves under load, and how far and how unstable the servers you actually use are — and since NetDiag+ 1.4.6 every one of them exports as plain text you can paste into a ticket, a forum post or a regulator's form.
Three measurements that name a place and a time
- Locate the loss with MTR. A traceroute that keeps pinging every hop shows where packets start disappearing. Loss that begins at one hop and persists to the very end is real, and that hop names the network responsible. Loss at a single hop that vanishes at the next is that router rate-limiting its own replies — normal, not evidence. Run it at the bad hour and note the hop.
- Add latency under load and the latency table. A bufferbloat test tells you how much latency rises while the line is busy and in which direction: an upload spike points at your own router, a download spike at the provider's equipment — and that direction is what decides whose problem it is. The Latency Dashboard adds median, jitter and loss to the named servers you use, with your own router measured first so nobody can blame your Wi-Fi if it is clean.
- Export as text, at the right hours, more than once. Every tool has Share → text report: targets, timestamps, every number. One run proves nothing; three at the bad hour on different days plus one at a quiet hour as a control is a pattern. The bufferbloat trend chart keeps the worst spike of every run over 7, 30 or 90 days, so the pattern is visible without you keeping notes. History keeps everything you ran.
Free · 27 tools · one-time purchase removes ads · no subscription
Questions people actually ask
What should the ticket actually contain?
Dates and times of each run. The hop where loss starts and its percentage. Idle latency versus latency under download and under upload. Median and jitter to two or three servers your household uses. Which test was the control. Everything pasted as text, not described — a technician can act on a hop list, not on "it lags".
Support says the line tests fine. Are they lying?
Usually not. Their tests check signal levels, error counters and throughput, and all of those can be perfect while a queue adds 300 ms or a congested peering link drops 2% of packets at 9 pm. You are measuring something they do not measure. Say so, and hand them the numbers.
Screenshots or text?
Text. It can be searched, quoted, pasted into an internal tool and forwarded to the engineer who actually fixes things; a screenshot cannot. Text also survives a forum's image compression and a regulator's web form. Keep the screenshots for yourself.
How many runs make a case?
Enough to show the problem is repeatable and time-bound. Three runs at the bad hour across two or three days, plus one at a good hour that comes back clean, is the minimum that turns a complaint into a report. If the good-hour run is also bad, the fault is not congestion — that is useful too.
Will this actually get something fixed?
It moves the ticket from first line to someone who can read a hop list, which is the step that usually stalls. Where a regulator exists — BTK in Turkey, the national telecom authority in most of Europe — the complaint forms ask for exactly this: dates, measurements, what the provider replied. Evidence does not guarantee a fix; it removes the reasons for saying no.
The single strongest number in any of this is latency under load. Next: which server is far, and which is unstable →