search

traviscross / mtr

Official repository for mtr, a network diagnostic tool
http://www.bitwizard.nl/mtr/
GNU General Public License v2.0
2.7k stars 341 forks source link

Using the -f option changes the packet rate. #479

Open mosebyjr opened 1 year ago

mosebyjr commented 1 year ago

I'm using mtr with some scripting to monitor packet loss and latency over an L2 path. When the destination is up, this command sends 600 packets at 20pps and provides stats about every 30 seconds:

/sbin/mtr -c 600 -i 0.05 -o SLBAWVD --csv -a 169.254.163.1 169.254.163.11

If the destination is down, then it sends packets at 280pps since it now tries 14 hops before it giving up.

Since my target is on the same L2 network, one hop is all I need, so I tried this:

/sbin/mtr -f 6 -m 7 -c 600 -i 0.05 -o SLBAWVD --csv -a 169.254.163.1 169.254.163.11

This command sends packets with TTL=6 at 120pps, and the entire run is reduced from 30 sec down to 5. Seems like odd behavior that isn't obvious to the user since the ttl and the rate shouldn't interact.

Another oddity is that if one specifies -f and -m with the same value (e.g. -f 6 -m 6), packets are sent, but no csv report is generated.

I have resolved my issue by using "-f 1 -m 2", but if someone really wanted to monitor a subset of hops, figuring the rate would be hard.

$ mtr -v mtr 0.92 on RHEL8.4

yvs2014 commented 1 year ago

a possible fix of "ticking too fast" https://github.com/traviscross/mtr/commit/f89c17078deda0d3bd841cd515da4b79b0c2cada (it was for https://github.com/traviscross/mtr/issues/466, but probably that would be suitable in this case too)