traviscross / mtr

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

why the snt's num is different #463

Closed jayyah closed 1 year ago

jayyah commented 1 year ago

企业微信截图_16733412156820

rewolff commented 1 year ago

In the old days, MTR would send out say 30 packets all at once and then wait for the replies. I modified mtr to spread out the transmissions. On my connection at the time, it would take the better part of a second to send out all the packets. So it would measure 800ms delay to the host at hop 20 while in fact it was just for example the 100ms of my link and then 12 ms more. It is just that it took 700 ms to transmit the probes for host 1-19....

Nowadays the probes are spread out. But sending out many more probes than there are hosts in the path is wasteful. So mtr will send no more than 10 hops beyond the last known-responding router. The situation that you fire up mtr when you've lost connectivity is quite likely. Then there might be 3 hops before "nothing works": the link from router 3 to router 4 is broken. So mtr will try to probe hosts 4-13, but not any further. Once the connection comes back and say host 9 starts responding, mtr will extend its probes further than 13 (here 9+10=19) and once it gets a reply from the target e.g. at position 16 it will know to probe exactly 16 hops.

In your case, that's exactly what happened. The first 11 hops were probed then 5-10 seconds later, hops 2, 3, 4 started responding so from then on hosts 12, 13, and 14 started getting probes. Only 18 seconds after starting mtr did router 5 start responding and were the probes extended to host 15. Note that in those 18 seconds about 180 probes were sent to hosts 2-14 that went unanswered. Chances of sending out the probe for host 15 and getting a response in that situation is close to zero.