[FujiApple]

Something I intend to add to Trippy, but have not got around to it yet; is to codify the "If a packet takes the path A -> B -> C and pings to B have 50% loss but pings to C have 0% loss, then the path is perfectly fine" idea and use that to produce more meaningful headline status information to the user. How would you codify this?

[linsomniac]

It's probably tricky but if there's loss at D, maybe only then materialize the display of the loss backwards until there is no loss: C? B? A? It gets tricky though where maybe there is a small loss at D, but say that C and B have chronic loss because of throttling in the slow path responses.

If D has 1% loss and B and C have 50%, is it fair to say A=0, B=1%, C=1%, D=1%?

MTR display of loss is indeed confusing, but when weird things are going on it can be helpful just stare at it a while to see what's going on. Trippy looks fantastic, and I need to play with it, but there are cases where I just want to stare at the path loss for a while.

There's no way to influence the TTL on TTL timed-out responses, is there? That'd be pretty cool if there were some way to get the return path of the intermediaries to reply.

[FujiApple]

Thanks for that, I'll give this some thought and write a proposal in this [0] placeholder issue.

[0] https://github.com/fujiapple852/trippy/issues/860

[commandersaki]

I would love for there to be a useful indicator to the user to say if loss or latency is an issue.

Being able to indicate cascading loss (e.g. path A->B->C->D) shows loss at B, C, and D, is worth bubbling up to the user to say there might be real issues. Also any indication of loss at D is also an issue. Trying to reconcile these scenarios with the UI matters, but I don't think there's an easy way. What I think is more important than UI that is sorely needed is documentation / users guide explaining how to read and understand these indicators. I know documentation is usually overlooked by users first trying out a program, but having it documented and explained can be used as a reference to point to a user that is misunderstanding the tool. I found that MTR didn't have this much needed documentation / reference that people would easily misunderstand the tool and it was a herculean effort to correct them.

I would also like to point out that a 0% loss indicator at the destination isn't reliable either if the packets are spaced out with enough slack. One of my goto when testing packet loss of a link I've brought up is to smash a destination host with a ping flood, e.g. ping -c 100 -f 1.1.1.1. By inundating the link it helps provide a clear indicator if there is loss somewhere on the path (usually the first mile or the last). Cloudflare speedtest now has a packet loss tester that floods 1000 packets, although I'm not sure if it does it over an unreliable transport or not.

[FujiApple]

I agree regarding documentation. There was a request [0] for something similar, though not specifically covering this important point.

Regarding sending a ping flood, Trippy allow you to reduce the minimum and maximum round time (and grace period) to send packets almost as fast as you like. For example, to send at 50ms intervals (with a 10ms grace period):

> trip example.com -i 50ms -T 50ms -g 10ms

[0] https://github.com/fujiapple852/trippy/issues/853