title needs to be fixed as above and becomes BAU.

shameless copy from https://stackoverflow.com/questions/12151306/argparse-way-to...

i think the biggest is problem is the culture fit.

Also to the point on raising the bar. I think that is not a bad thing.

There does not have to have a single battery standard, could be s/m/l, like coincell, aaa, aa etc.

> Would you trust the people and systems that the battery hasn't been tampered with and is in good working order?

Do you trust random utilities/charger manufacture?

> new battery, but empty, to a random one at a swapping station.

Would you care if it is within regulated thresholds and you can get another one any time you want?

Understanding can be improved. Bunk MTRs are easy to spot. You tell them this is not an issue because .... . Than they will learn and usually that customer will stop sending you bunk MTRs.

I'm pretty sure that the people that are opening tickets with providers/network teams because they have nothing better to do is nearing 0. The fact that they ran an MTR shows that they were doing some troubleshooting and at the end of the day a problem needs to be solved. It may not be on your end but that needs to be investigated but the same would apply for a crappy iperf throughput test. IMHO Any clue/information into where that problem is, is helpful. You may need to filter relevant from irrelevant.

But if I get to pick one out of 2 problems, one has a crappy iperf results, the other has an MTR that has a loss that carries over, I would probably pick the second because that at least gives me indication on whereabouts should I start looking.

> Time shouldn't be wasted measuring the control path and then investigating to confirm it is the control path and not data path. You cannot make these mistakes using traceroute and ping separately because traceroute doesn't have a notion of a "per-hop" loss indicator.

traceroute does have per-hop indicator, it's the * in the output, it's just so often off that nobody pays much attention. You can't really catch issues that are related to route-flaps or reroutes with traceroute. with MTRs it becomes pretty clear if a reroute happens in the middle of your test. I guess you can keep running traceroute but I will leave it to you to sift through the output of that nightmare and than it effectively became MTR, with worse output.

There are also many options available in MTR that is not there in traceroute (to trigger these packets by tcp or udp packets), fix local or remote port etc. Even if you just run it with 3 packets per hop, you will have way more options. You don't have to use it as a continuous monitor to indicate packetloss but can give you the traceroute level information in a much cleaner format and you have more options to choose from.

> ping doesn't involve intermediate hops (unless an intermediate hop generates an ICMP diagnostic for an echo request).

ICMP echo requests and replys can be subject to different QoS treatment as TCP/UDP traffic, so that also doesn't necessarily gives you the right idea when testing for end to end connectivity issue. Iperf imho is the best bet, and if you want to be really accurate you pick the src/dst port for client/server just to be sure you get into the same Class as your problematic traffic.

As a sidenote MTR packets are also ride the data-plane until they reach the TTL=1.

An argument could be made for a device configured as such to show loss on ping but not on mtr if you configure the rate limits so that the icmp reply rate is lower than ttl expired rates. Which tool would be wrong than? Would you blame ping for producing misleading results?

The running counters and the ability to pick out the obvious rate limiting when the loss doesn't cascade into the hops to me is akin to traceroutes * * * output. It doesn't always mean that the packets are blackholed, connectivity is broken, it just means the tool is producing an artifact due to network configuration or network characteristics. Further investigation is needed to figure out what's going on.

MTR imho is giving you much more insight into the network than traceroute or ping separately. It doesn't resolve the usual firewall/rate limiting artifacts, but gives you way more information about paths if you know how to interpret them.

If you run it in TCP or UDP mode you can even nail down the physical interface that's erroring in a LAG/LACP bundle due to being able to manipulate the 5 tuples very well.

I'm also curious about the flags you used for ping and mtr that showed you this discrapancy.