prometheus-connectivity-exporter VS mtr

I don't trust speedtests. There are all kinds of wrong incentives, similar to GPU benchmarks. One thing I noticed was that the data speedtest.net sends has really low entropy. It just repeats 10 bytes. If I ran an ISP I would...

So I wrote chargen2p [1] as an extension to the classical chargen protocol.

I use it together with a Prometheus exporter [2] I wrote to periodically check my laptop's connectivity. The actual check runs over Wireguard, since I didn't want to open my chargen2p server to the public. This only checks download speeds, mind you. (The chargen2p library exports upload metrics, but the exporter doesn't use it.)

My graphs tell me the average is ~5 MBps, so 40 Mbps. This is between me (Switzerland) and a Hetzner DC in Germany. speedtest.net just now claimed 160 Mbps.

[1] https://github.com/tommie/chargen2p

[2] https://github.com/tommie/prometheus-connectivity-exporter

As a reminder, Trippy combines the functionality of traceroute and ping and is designed to assist with the analysis of networking issues. You can think of it as a modern, cross platform, Rust based version of tools such as mtr, with a bunch of advanced features and a fancy TUI.

Cool project! Two suggestions, one serious, one frivolous:

- I wonder if you could get more accurate results by using TCP or UDP instead of ICMP. I think traditional traceroute has an option to use UDP, mtr [1] can use TCP or UDP, and tcptraceroute [2] can use TCP.

- This would be a perfect fit for some Talking Heads references. "And you may ask yourself, well, how did I get here?" [3]

[1] https://github.com/traviscross/mtr

[2] https://linux.die.net/man/1/tcptraceroute

[3] https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...

Run mtr, or whatever the Windows equivalent might be, and leave it running shortly before 4:15pm, and see where the traffic stops when the Internet shuts off.

Lot of great stuff here, haven’t seen MTR yet: https://github.com/traviscross/mtr

Consider using MTR (software) towards the actual end-point of the SIP connection to get a combination of traceroute and ping which will be much more revealing. This will also allow you to quickly identify if the problem is local to your equipment or somewhere along the path. Consider allowing her to join a Google Conference from Teams to determine if it is provider related. Yes, port mirroring and wire shark is the gold standard and will display the "answer" on your screen quickly but it requires skills to know what to analyze, look at and how to interpret the data.

Have you tried something like mtr to check for connection issues? I would recommand the view you get when hitting d twice after starting it (with the colored graph for latencies).

Continuing to build trippy; a network diagnostic tool inspired by mtr. There is still a long way to go but it is getting closer to feature parity with mtr.