'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.

Even browsing the web to read wikis and documents and stuff is a complete pain half the time.

I'd hook it up to a proper display using an MHL cable then connect a Bluetooth keyboard. It was a sweet setup and the assorted tools (plus root shell) actually came in very handy. It could fill in for a laptop quite nicely.

These days it seems there's no legitimate alternative to MHL... can any phones directly connect to a display anymore via wire? Or is the only option screencasting to a smart TV?

FWIW, I generally like my appliances on the dumb (or open) side.

Samsung has "Dex", their android desktop interface.

Linux phones can generally offer a full DE, either the pinephone or Librem, or compatible phones that have a video out where you can install something likke postmarketos.

Most phones also support miracast, and you can plug in a mouse/keyboard. I think the Charging in + keyboard + mouse + video out is clearer with USB-C.

Sent from my Galaxy S4 ;)

That is your preference. For others the advantage of utilizing a familiar interface outweighs the disadvantages (that maybe even aren't for some) mentioned.

Then maybe it's not for you, but some of us absolutely have had that thought and find it incredibly useful.

You are on holidays, your need to help someone (or yourself) with some server issues. Use your teminal to ping them, ssh, etc. Later, no Internet at your rental house. No computers. Fire up the terminal,diagnose the issue. nmap the network if you need to find the IP of something (also, to check for cameras? IDK).

It's just a huge toolbox, batteries included. You might not need it. It can certainly come handy, especially if you have no Internet to download the corresponding app.

I don't use it often, but when I do, it's much better to have it than not having it.

To answer your question: I think your point of view need to change. The need we want to full fill is to do computer stuff, we have a pretty neat computer in our hand it is clear we want to use it as such.

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

https://github.com/cjjeakle/network-monitor

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

[1] https://github.com/heywoodlh/bash-uptime

[2] https://hub.docker.com/r/heywoodlh/nfcapd

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 number

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: 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?

https://github.com/apenwarr/blip

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.