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.
I figured I should be the change I wish to see in the world and created this super light ping test.
I also created a latency monitoring solution (https://github.com/cjjeakle/network-monitor), 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!
'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)...
can I hit that point home: "easier way than pulling up my terminal", answer: a non-https javascript needing website!!!
>>> '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'
"super simple"... sounds... super simple... installing rust nightly as we speak to build it /s
this world of ours
For a bit of context:
I found myself using this site via my xbox's web browser to make sure my wifi latency is acceptable where I put the xbox.
Also, my spouse and I just moved to a new place, so I used this site on my phone to get a quick idea of the latency on wifi in my spouse's office.
There's tons of web-based tools to test your bandwidth, but I feel there just isn't a similar ecosystem of quick, web-based "ping" (well, latency, since I can't send ICMP packets from a web browser) tools.
-
RE: HTTP only, good point. I've set up certbot and the page supports https now. I am not certain how HTTPS will impact the latency measurements, it appears the results are typically a bit higher and occasionally much higher when using HTTPS.
-
I don't get the disappointment with the use of JS. It's just a bit of inline JS, easy to manually audit if concerned. JS is quite safe IMO and is a very powerful tool, it makes a rich universe of interactive applications possible in the humble web browser. I basically got into CS because of the fun I had creating things for and sharing things on the web.
Sure you did. But there's a whole category of phone apps called Wifi Heat maps, that would actually be "super simple" for a non-techie to use.
People are commenting on your use of javascript, where you are arguing that you built a super simple solution. As many already pointed out, the ping command is already there and is more "super simple" to use than to self host a website to get a skewed HTTP "ping" from some cloud service...
Mine does, and in fact I have used the ping command from it before. I highly recommend having a terminal app.
On your phone you run for example Fing
Fing iOS: https://apps.apple.com/us/app/fing-network-scanner/id4309211...
Fing Android: https://play.google.com/store/apps/details?id=com.overlook.a...
With Fing App’s free tools and utilities help you:
• Scan networks with Fing’s Wi-Fi & LAN network scanner and discover all devices connected to any network
• Get the most accurate device recognition of IP address, MAC address, device name, model, vendor and manufacturer
• Run WiFi and Cellular internet speed tests, download speed and upload speed analysis and latency
• Browse internet outages in your area, ISP ratings, reviews and speed statistics
• Advanced device analysis of NetBIOS, UPnP, SNMP and Bonjour names, properties and device types
• Includes port scanning, device ping, traceroute and DNS lookup
• Receive network security and device alerts to your phone and email
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.
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.
Labelling this a "ping" was a poor choice on my part. I meant ping in the RTT/latency sense, rather than an ICMP sense. Calling it "HTTP latency" is a huge improvement that clearly (and concisely) gets the idea across, I made a quick edit to do just that.
RE: recording a range of samples and reporting percentiles: My hope is to keep the code super simple and the delay to visible info in the UI very low. Elsewhere in the thread folks mentioned the excellent http://gcping.com/. That site has a ton of destinations to test latency to and reports the median of a number of samples - that is a really cool feature set! I don't think I'll be able to do anything close to that in tens of lines of inline JS, unfortunately.
Still, the measurements start super noisy and I'd like to ensure my site gives useful data even at the start. I did a bit of a hack to hopefully force the RTT to converge to something useful. I now fire off 3 time-delayed measurements after the page loads. By the time the third finishes, the numbers appear to be pretty stable.
For even more sites/pops, https://gcping.com 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.
Not sure if this is desired, but if at some point alerting was built into this, that would be awesome.
---
On a related note, I currently use the following tools to monitor my network:
- bash-uptime[1] -- BASH script I wrote for simple (for me) icmp/http monitoring.
- iPerf3 server so I can test my bandwidth speeds over the LAN or Wireguard
- 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])
- Syslog-ng to ingest logs and write them to my filesystem with some scripts I use to search the logs quickly via grep
- Gotify for all my network-related notifications
Although it’s sad to see they put political messages in it now
Client SYN =>
<= Server SYN+ACK \w epoch in sequence
Client ACK =>
<= HTTP payload calculating ping with NOW - ACK numberIf you want timings only for TCP connection establishment, or only for the request, you can use the browsers navigation timing APIs to get those: https://developer.mozilla.org/en-US/docs/Web/Performance/Nav...
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.
I don't run it much since I don't want to tear through my ISP's data cap, but is an excellent tool.
Modern browsers / webservers will keep TCP connections alive for at least a few minutes. I ran a tcpdump and confirmed there's only one network round trip involved in the critical path (after the first request, anyhow), with a transfer of a few hundred bytes in each direction (HTTP overhead, but nowhere near big enough to incur processing delays on the same scale as propagation delay).
(The actual packets sent: HTTP GET from my end, HTTP response from the server, ACK from my end.)
The latency is still 20-40ms higher than ping times, although it's not clear to me whether that's due to disk seek latency, server load, or something else.
Over 5 tries I’ve received widely varying ping times to SF, two of which were 1s while NYC was 140 ms ish.
Just weird because I’m on a reliable connection in SF (sonic).
function ping_test() {
time_request("http://ping.projects.chrisjeakle.com/ping/data.txt", "result-east");
time_request("http://ping.projects-west.chrisjeakle.com/ping/data.txt", "result-west");
}
function time_request(url, output_id) {
document.getElementById(output_id).innerText = "...";
const start_time = new Date().getTime();
fetch(url, {
mode: "no-cors",
cache: "no-cache",
}).then(async (result) => {
const elapsed_time = new Date().getTime() - start_time;
document.getElementById(output_id).innerText = elapsed_time;
});
}Also, maybe you should run the tests in sequence instead of at the same time. I wonder if running two concurrent fetches might disadvantage the second fetch?
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."
Edit:
I think I found a way to get the best of both worlds!
I've removed certbot's 301 redirect from HTTP to HTTPS and made it so the protocol used during latency measurements matches the page's state. Now if one wants HTTPS they can use it, but if they want a slightly more stable measurement they can use the http page.