Latency line · Latency & Path Analysis
Latency and path analysis tools, judged by the evidence they give you
“Where along the path does it go wrong?”
Latency line6 stops
- PingPlotterAlso on Throughput line and Reachability line
- mtrAlso on Throughput line
- SmokePingAlso on Reachability line
- Obkio Network Performance MonitoringAlso on Throughput line
- Angry IP ScannerAlso on Reachability line
- WiresharkAlso on Throughput line and Reachability line
Every “the internet is slow” ticket eventually needs the same answer: slow between which two points? Latency and path tools find it by sending probes toward a destination and timing the replies from each router along the way — the hops. A single traceroute is a snapshot. The tools compared here keep sampling, so an intermittent fault that only appears at two in the afternoon leaves a record instead of a rumour.
We judge them from the angle this site applies everywhere: what evidence does the tool produce that you could hand to an ISP, a SaaS vendor’s support desk or the colleague who owns the firewall, and how long does it take to get it? A text report pasted into a ticket within five minutes is worth something. So is a two-week graph showing loss climbing every evening when the off-site backup starts. The table below is ordered by how directly each tool produces that kind of proof on a typical small or mid-size network; the methodology page explains the full scoring.
One caution before you trust any per-hop number. Routers treat packets addressed to themselves — the ICMP replies traceroute depends on — as low-priority work. A hop showing 30% loss while every later hop shows none is almost always a busy control plane declining to answer your probes, not a broken link. Loss that starts at a hop and persists all the way to the destination is the pattern that matters. Every tool on this line displays that difference; not all of them make it obvious.
6 latency and path tools side by side
Ordered by how quickly each tool turns a live problem into evidence that someone outside your team will accept. Angry IP Scanner and Wireshark appear as supporting tools: the first confirms which hosts answer at all, the second shows what the packets did when the path looks clean but the application still stalls. Tap a tool name for our review; the vendor link goes to the developer’s site.
| Tool | Licence | Platforms | Evidence it produces | Key feature | Best for |
|---|---|---|---|---|---|
| PingPlotterPingman Tools | Commercial | Windows, macOS | Timeline graphs of latency and loss per hop that can be shared or exported | Continuous per-hop latency and loss graphed over time, with a shareable timeline | Proving an intermittent problem to an ISP with a graph instead of a description |
| mtrBitWizard / open-source maintainers | Open source | Linux, BSD, macOS; Windows only via WSL or Cygwin | A plain-text report (--report) of loss and latency per hop, easy to paste into a ticket | Traceroute and ping combined in one live per-hop table, with a report mode for tickets | Admins on Linux or macOS who want path evidence from a shell in under a minute |
| SmokePingTobias Oetiker | Open source | Linux / Unix server (Perl + RRDtool), viewed in a browser | Weeks of latency and loss history drawn as "smoke" graphs, one per target | Long-term latency distribution graphs that show jitter, not just averages | Keeping a baseline so the next "it has been slow for days" ticket starts with data |
| Obkio Network Performance MonitoringObkio | SaaS | Web app; agents for Windows, Linux, Docker, hardware and virtual appliances | Agent-to-agent loss, latency, jitter and VoIP quality history across sites | Monitoring agents at each site that test each other continuously, in both directions | Multi-site or SaaS-heavy teams that need ongoing proof of where performance drops |
| Angry IP ScannerAnton Keks | Open source | Windows, macOS, Linux | A CSV/TXT/XML list of which addresses answered, with ping time and hostname | Fast multi-threaded sweep of a range with pluggable fetchers and export | A quick before/after list of which hosts answer on a subnet you manage |
| WiresharkWireshark Foundation | Open source | Windows, macOS, Linux | A pcap file plus expert-info and TCP analysis (retransmissions, zero windows, resets) | Frame-level protocol decoding with TCP stream analysis and I/O graphs | Settling "network or application?" arguments with the actual packets |
Independent comparison — Scan 365 Pro is none of these vendors, and nobody paid for placement. Licences and platforms were checked against each vendor’s own pages on the date above.
How to choose
- Decide whether you need a snapshot or a history
A live per-hop table from mtr or PingPlotter solves problems that are happening right now. Faults that come and go need something that keeps recording while nobody is watching: SmokePing on a small Linux VM, PingPlotter left running on an affected machine, or Obkio agents at each site. If the complaint is “it was terrible yesterday afternoon”, a snapshot tool will only tell you it looks fine now.
- Measure from where the users are
A trace from the server room says little about the Wi-Fi on the third floor or a branch office on consumer broadband. Tools that run on the affected machine, or place an agent at the affected site, collect evidence from the right end of the path. Test in both directions when you can, because routing on the internet is frequently asymmetric.
- Check which probe type you are sending
ICMP, UDP and TCP probes can be handled differently by firewalls, load balancers and ISP edge routers, and some networks rate-limit ICMP hard. mtr and PingPlotter can both send TCP or UDP probes. If an ICMP trace looks alarming, repeat it with TCP to the port the application really uses before you escalate.
- Look at what leaves the tool
An ISP support desk wants timestamps, source and destination addresses, and per-hop loss and latency across a meaningful sample — a few hundred cycles rather than ten. Prefer tools that export a report or a shareable graph over ones that only show a screen you would have to photograph.
- Match the cost to the question
mtr and SmokePing cost nothing but setup time. PingPlotter and Obkio are paid products with trials (Obkio also has a small free plan); what you pay for is the time saved presenting evidence and, with Obkio, continuous multi-site coverage. A single office with one ISP rarely needs a subscription; ten branches and a hosted phone system often do.
Reading per-hop loss without fooling yourself
The most common mistake on this line is escalating a hop that only looks bad. Before sending a trace to anyone, check three things. Does the loss continue through to the final hop? Does latency step up at that point and stay higher for every hop after it, rather than spiking at one router? Does the pattern repeat across several runs taken at different times of day?
If the answer to all three is no, the hop is probably protecting its CPU and your traffic is fine. If the answer is yes, you have the start of a real case: note the first hop where the problem appears, the time window, and whether that hop belongs to your network, your ISP or a network further along. That short paragraph, plus the exported report, is the evidence package.
Vendor pages: PingPlotter pingplotter.com · mtr bitwizard.nl · SmokePing oss.oetiker.ch · Obkio Network Performance Monitoring obkio.com · Angry IP Scanner angryip.org · Wireshark wireshark.org
Questions admins ask about latency and path tools
Is packet loss at one hop in the middle of a trace a problem?
Usually not. If the hops after it show little or no loss, the router is deprioritising replies to probes aimed at itself while forwarding real traffic normally. It becomes a problem when the loss begins at that hop and continues all the way to the destination.
Should I start with mtr or PingPlotter?
If you are already in a Linux or macOS shell, mtr gives a per-hop table in seconds and its report mode pastes neatly into a ticket. If the problem is intermittent, the person reporting it is on Windows or a Mac, or you need a graph a non-technical manager or ISP agent will read, PingPlotter’s timeline is the stronger exhibit. Our PingPlotter vs mtr comparison covers the trade-offs in detail.
How long should a trace run before I send it to my ISP?
Long enough to cover the problem window with a few hundred samples. For a constant fault, ten to fifteen minutes is plenty. For something that appears at certain times, leave a logging tool running across at least two occurrences so you can show the pattern repeating.
Why do my traces look different from a colleague’s?
Different source networks take different routes, and many providers balance traffic across several equal-cost paths, so hop lists vary between runs and between people. Compare traces taken from the same place to the same target, and remember that the return path can differ from the outbound one.
Do I need SmokePing if we already have a monitoring system?
Many monitoring systems record up/down status and an average response time. SmokePing records the spread of latency and loss per target, which is what reveals jitter and congestion that averages hide. If your current system already graphs loss and latency distribution, you may not need it.
Keep going
Disclosure: vendor links on this page go straight to each vendor’s own site and earn us no commission. See the affiliate disclosure.