Show HN: An ultra-light-weight tool to quickly test your ping

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!

Show HN: An ultra-light-weight tool to quickly test your ping
ping.projects.chrisjeakle.com

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?

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.