Hacker News Reader

MTR does none of the things you claim it does, which is directly addressed in the article.

It certainly claims to, and displays figures as if it could, but it cannot.

Even pinging the router IPs directly does not tell you your latency or packet loss to the router, for the reasons explained in the article.

mtr is built on false pretenses.

Thank you, combining ping & traceroute into one tool is a fools errand; keep them separate.

Ping to approximate RTT & detect loss between endpoints.

Traceroute to approximate forward path of a packet to destination.

Combining both gets you crap like a washing & dryer combo machine where it does both neither well.

As long as you're the only one doing the troubleshooting, sure. FTA:

  > The example given is that a handful of users running MTR (do not get me started on this bastard program) can actually hit this rate limit. This is an outstanding example because I have seen something similar in practice.

  > Consider what that would look like, and how common it would be: If you have a NOC full of people who think they know what they're doing, but don't, that only enhances the probability that everyone is trying to troubleshoot on their own instead of doing a screenshare and coordinating their efforts - thus, you have six guys running MTR to the same IP.

Plus one for MTR, it’s a great tool. Not perfect, but great.

MTR is great... if you know what route you expect it to take, and expect it to take back.

Very useful for troubleshooting inside of the Enterprise, or when I did a lot of ISP work. MTR to some rando website in a different timezone could be useful... but not often.