[HN Gopher] Show HN: An ultra-light-weight tool to quickly test ...
___________________________________________________________________
Show HN: An ultra-light-weight tool to quickly test your ping
Howdy HN! 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!
Author : PNWChris
Score : 30 points
Date : 2022-10-01 20:31 UTC (2 hours ago)
(HTM) web link (ping.projects.chrisjeakle.com)
(TXT) w3m dump (ping.projects.chrisjeakle.com)
| Matthias247 wrote:
| 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.
|
| 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...
| amelius wrote:
| Nice. Now all you need is a catchy URL so people can remember it.
| a1445c8b wrote:
| Great start!
|
| 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.
| isatty wrote:
| I'm on my phone and I can't debug/look into it but the jitter is
| very high.
|
| 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).
| vdfs wrote:
| The code my clarify that up, it simply calculate how much time
| an http request take to complete: function
| ping_test() { time_request("http://ping.projects.chris
| jeakle.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;
| }); }
| 0x0 wrote:
| You should consider switching to _window.performance.now()_
| as that is a monotonically increasing clock, instead of a
| wall clock that might randomly be adjusted with time sync
| services.
|
| 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?
| vdfs wrote:
| Not an expert but this doesn't seem like normal ping, it's rather
| how much HTTP request take including handshakes and content
| download
| vitus wrote:
| Not entirely.
|
| 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.
| netsharc wrote:
| I wonder if it could be done better using WebSockets: setup the
| connection, start the stopwatch, send a byte, wait to receive a
| byte, stop the stopwatch, and close the connection.
| silisili wrote:
| Really lightweight, nicely done.
|
| 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.
| Wxc2jjJmST9XWWL wrote:
| Sorry for being unappreciative but... is this... satire? I
| honestly don't know...
|
| '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
| hatware wrote:
| Definitely has a "but why?" vibe to it. OP probably learned a
| lot getting this up and that's usually what motivates me to
| learn.
| andrepd wrote:
| It has to be satire. I for one welcome the era of PaaS (ping as
| a service).
| ipsum2 wrote:
| How was it possible to read "easier way to test my ping than
| pulling up a terminal" but not finish the sentence to
| "especially when I'm on my phone or any other device that
| doesn't have a terminal"?
___________________________________________________________________
(page generated 2022-10-01 23:00 UTC)