Timeout option to avoid false postives for packet loss in report mode on high latency links
Bug #776211 reported by
Marty
This bug affects 7 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mtr |
Fix Released
|
Undecided
|
rew |
Bug Description
I often use MTR to generate reports to email to other network admins.
On high latency connections there is often false positives for packet loss on the last few hops because the replies don't arrive before the timeout.
It would be nice to have an option to specify a higher timeout when testing high latency connections to obtain an accurate report.
Changed in mtr: | |
status: | New → Fix Released |
assignee: | nobody → rew (r-e-wolff) |
Changed in mtr: | |
status: | In Progress → Fix Released |
To post a comment you must log in.
I second this request. This makes troubleshooting high-latency paths (such as from the US west coast to Sweden) very difficult, and ends up indicating there's loss when in fact there isn't. Again: this ONLY happens with --report.
Here's a real-life example (same geographical locations as above, actually); this is with ICMP (not UDP mode), by the way, with a report count of 40.
=== Mon Jun 27 03:35:00 PDT 2011 (1309170900)
HOST: isis.parodius.com Loss% Snt Rcv Last Avg Best Wrst
1.|-- 72.20.98.65 0.0% 40 40 0.2 0.3 0.2 0.5
2.|-- 69.163.64.44 0.0% 40 40 0.3 0.3 0.2 0.4
3.|-- 38.112.2.73 0.0% 40 40 1.5 2.6 1.5 4.3
4.|-- 38.20.55.213 0.0% 40 40 90.3 57.4 1.1 194.1
5.|-- 154.54.1.25 0.0% 40 40 2.5 2.4 2.2 2.8
6.|-- 154.54.45.77 0.0% 40 40 48.3 48.0 47.9 48.5
7.|-- 154.54.30.169 0.0% 40 40 53.5 53.5 53.4 53.8
8.|-- 154.54.0.129 0.0% 40 40 76.9 77.0 76.8 77.3
9.|-- 154.54.1.134 0.0% 40 40 77.0 76.8 76.6 77.3
10.|-- 154.54.11.10 0.0% 40 40 71.3 72.1 71.1 95.6
11.|-- 80.91.248.161 0.0% 40 40 71.3 78.1 71.2 155.4
12.|-- 80.91.247.118 0.0% 40 40 167.8 176.3 167.8 259.9
13.|-- 213.155.130.50 0.0% 40 40 177.4 183.5 177.2 256.1
14.|-- 213.248.66.14 0.0% 40 40 180.0 182.1 179.9 225.1
15.|-- 213.248.77.186 0.0% 40 40 177.5 183.4 177.4 240.2
16.|-- 81.228.94.14 0.0% 40 40 178.8 178.9 178.3 179.8
17.|-- 81.228.79.226 0.0% 40 40 184.4 184.5 183.8 185.1
18.|-- 81.228.73.227 0.0% 40 40 190.6 193.8 190.6 312.7
19.|-- 81.228.72.97 2.5% 40 39 194.5 200.1 194.2 283.8
20.|-- 81.228.75.117 2.5% 40 39 195.0 197.4 194.8 271.6
21.|-- 81.226.229.103 2.5% 40 39 198.0 199.4 197.5 200.9
=== END
Hops 19-21 indicate 2.5% packet loss (and sometimes this varies, occasionally all the way up to 7.5%), but only when using --report. Standard ICMP ping and traceroute -P icmp (on FreeBSD) never indicate any degree of packet loss. This is purely a misreporting issue with mtr.
I'd provide a patch myself -- honest/really! -- but the code doesn't read well. I imagine the issue is in net.c, possibly the calculation used in function net_loss(), but I'm not entirely sure.