Howdy HN!<p>I find myself testing my ping from time to time, especially when my internet seems wonky while WFH. It feels like there should be an easier way test my ping than puling up a terminal or a complex web app - especially when I'm on my phone or any other device that doesn't have a terminal.<p>I figured I should be the change I wish to see in the world and created this super light ping test.<p>I also created a latency monitoring solution (<a href="https://github.com/cjjeakle/network-monitor" rel="nofollow">https://github.com/cjjeakle/network-monitor</a>), feel free to clone and try it out! I know there are a lot more mature monitoring solutions out there, but I never did figure out how to set them up. This one is super simple: clone it to some device that's always on, compile it, set up some systemd stuff, and it's ready to rock on port 8180!
Sorry for being unappreciative but... is this... satire? I honestly don't know...<p>'easier way to test my ping than pulling up a terminal', ... so a non https website that needs javascript is better than terminal-shortcut + <terminal>$ ping 8.8.8.8</terminal> (or whatever you want to ping, you also could set up an alias/function in your .bashrc to do something more complex)...<p>can I hit that point home: "easier way than pulling up my terminal", answer: a non-https javascript needing website!!!<p>>>> 'super simple: clone it to some device that's always on, compile it, set up some systemd stuff, and it's ready to rock on port 8180'<p>"super simple"... sounds... super simple... installing rust nightly as we speak to build it /s<p>this world of ours
Great start!<p>One way you could improve this is to not stop at just reporting a single data point but report the P50, P75, and P90 of a reasonable set of data points.<p>Also, it's probably better to call this HTTP latency rather than ping since the latter is on a much lower layer in the OSI model.
Really lightweight, nicely done.<p>For even more sites/pops, <a href="https://gcping.com" rel="nofollow">https://gcping.com</a> exists which I believe pings each GCP region worldwide. It feels a bit heavier, as it takes at least a few seconds before I see (relevant to me in the US) results.
This is super cool! I like the ability to review previous results. Not sure why people are getting so hung up on how ping in the terminal is so much simpler.<p>Not sure if this is desired, but if at some point alerting was built into this, that would be awesome.<p>---<p>On a related note, I currently use the following tools to monitor my network:<p>- bash-uptime[1] -- BASH script I wrote for simple (for me) icmp/http monitoring.<p>- iPerf3 server so I can test my bandwidth speeds over the LAN or Wireguard<p>- Nfcapd/nfdump to ingest netflow from my firewall and router and give me the ability to search that netflow with nfdump (I have a multi-arch Docker image for Nfcapd that I maintain[2])<p>- Syslog-ng to ingest logs and write them to my filesystem with some scripts I use to search the logs quickly via grep<p>- Gotify for all my network-related notifications<p>[1] <a href="https://github.com/heywoodlh/bash-uptime" rel="nofollow">https://github.com/heywoodlh/bash-uptime</a><p>[2] <a href="https://hub.docker.com/r/heywoodlh/nfcapd" rel="nofollow">https://hub.docker.com/r/heywoodlh/nfcapd</a>
I use <a href="https://www.cloudping.info/" rel="nofollow">https://www.cloudping.info/</a><p>Although it’s sad to see they put political messages in it now
<a href="http://ping.playit.gg/" rel="nofollow">http://ping.playit.gg/</a> embeds the request epoch in the TCP sequence number to give you your ping.<p><pre><code> Client SYN =>
<= Server SYN+ACK \w epoch in sequence
Client ACK =>
<= HTTP payload calculating ping with NOW - ACK number</code></pre>
The times will be super different between initial load and retries, since the first request requires a potential DNS lookup, establishing a TCP connection, and potential TLS handshake, and only then the request can be performed. Follow-up requests don't require an additional connection.<p>If you want timings only for TCP connection establishment, or only for the request, you can use the browsers navigation timing APIs to get those: <a href="https://developer.mozilla.org/en-US/docs/Web/Performance/Navigation_and_resource_timings" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/Performance/Nav...</a>
OP here! Great discussion, it's made me realize I should also share my favorite speed test: <a href="https://www.waveform.com/tools/bufferbloat" rel="nofollow">https://www.waveform.com/tools/bufferbloat</a><p>It both tests bandwdith and gives some cool latency measurements (both idle and under load). It's super helpful at diagnosing bufferbloat if there is any on your network connection.<p>I don't run it much since I don't want to tear through my ISP's data cap, but is an excellent tool.
I’m on my phone and I can’t debug/look into it but the jitter is very high.<p>Over 5 tries I’ve received widely varying ping times to SF, two of which were 1s while NYC was 140 ms ish.<p>Just weird because I’m on a reliable connection in SF (sonic).
I like this one which I think was a Show HN a while ago<p><a href="https://github.com/apenwarr/blip" rel="nofollow">https://github.com/apenwarr/blip</a>
Can HN please reject any submissions that are not HTTPS urls? The number of sites that get submitted here via plaintext http is shocking.<p>To anyone who just started typing out something to inform me that "it doesn't matter on _______ site because _______": there are four purposes of encryption, not just "confidentiality."