mtr: Probes exhausted

[mo8Zomo0]

referring to https://github.com/traviscross/mtr/issues/298

@rewolff it would be good to quote what would be reasonable values and also what else might cause this behaviour or what could improve it.

# mtr -v
mtr 0.92

(on Debian 10)

From how I see it it seems to fail quite quick if there are hops which do not respond on the path. As you see here, 500 packages, 0.1 (which I find is not very aggressive at all and which I would expect to work)

# time mtr  -werbz4 -c500 -i 0.1 host2
Start: 2022-08-25T15:21:33+0200
HOST: host1                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    192.168.101.2                            0.0%    65    0.5   0.5   0.3   0.9   0.1
  2. AS???    10.0.0.254                              95.3%    65    0.6   0.7   0.6   0.8   0.1
  3. AS2119   172.16.0.1                          90.6%    65    1.0   1.0   0.8   1.4   0.2
  4. AS???    ???                                     100.0    65    0.0   0.0   0.0   0.0   0.0
mtr: Probes exhausted

real	0m6.914s
user	0m0.025s
sys	0m0.078s

[rewolff]

It runs into "max outstanding probes" and that is set to 1024.

If I remember correctly, it now probes upto 10 further than the last host.

So you're sending about 15 probes 10 times per second, so 150 probes per second. So after 6-7 seconds, you're running into that 1000. Not sure when they expire, but that may be something like 10 seconds.

Try increasing packet/probe.h:#define MAX_PROBES 1024 to say 4096 and see if that solves it for you. That said... I think 1000 should be enough.

[mystica555]

I don't know what changed in kernels, or MTR, but I used to be able to do the following: (potentially sudo) mtr 75.75.75.75 i 0.01 dd to show the nice, very fast updating graph of pings to Comcast's DNS server.

It used to run for hours if I let it. Now it dies after 10s or less.

So what changed?