Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ping.projects.chrisjeakle.com

Post reply on HN
Print view View original

31–40 of 64 posts

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

#31

Post by the_only_law »

userbinator wrote: post #29
smabie wrote: post #21

Earlier quoted context omitted.

Why do you highly recommend it? Don't think I've ever thought while using a phone "damn I wish I had a Linux terminal handy"

I suppose if you don't think of your phone as the general-purpose computer that it really is, then it won't seem obvious. But otherwise, I also recall using dig, netcat, traceroute, and a few other network tools a few times. Having a shell, even a root one, is one of those things that you don't need often, but when you do, you really do.

I mean I know what my phone is. I just do not want to use that interface for those sort of tasks. Tiny little screen, virtual keyboard that tries to hard to be clever, etc.

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

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

#32

Post by PNWChris »

vitus wrote: post #10
vdfs wrote: post #4

Not an expert but this doesn't seem like normal ping, it's rather how much HTTP request take including handshakes and content download

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 packe…

This is super helpful context, thank you! I was wondering why the RTTs appeared to converge only after a couple retries, and why the first measurement was so wildly different when pulling up the page after some time away.

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

#33

Post by PNWChris »

0x0 wrote: post #7
vdfs wrote: post #5

Earlier quoted context omitted.

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.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().get…

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?

Super great points, I'm going to experiment with these ideas a bit and see how it goes.

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

#35

Post by yjftsjthsd-h »

smabie wrote: post #21
userbinator wrote: post #17

Earlier quoted context omitted.

especially when I'm on my phone or any other device that doesn't have a terminal Mine does, and in fact I have used the ping command from it before. I highly recommend having a terminal app.

Why do you highly recommend it? Don't think I've ever thought while using a phone "damn I wish I had a Linux terminal handy"

> Don't think I've ever thought while using a phone "damn I wish I had a Linux terminal handy"

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

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

#36

Post by yjftsjthsd-h »

ipsum2 wrote: post #13
Wxc2jjJmST9XWWL wrote: post #11

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 + $ ping 8.8.8.8 (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 term…

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

My phone does have a terminal, and I run ping in termux regularly.

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

#37

Post by PNWChris »

KennyBlanken wrote: post #25

Can HN please reject any submissions that are not HTTPS urls? The number of sites that get submitted here via plaintext http is shocking. 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."

Fair point! Just got all the certbot stuff set up. Wasn't too bad, though at first glance it appears there may be a bit more variance in the RTTs.

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.

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

#38

Post by PNWChris »

Wxc2jjJmST9XWWL wrote: post #11

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 + $ ping 8.8.8.8 (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 term…

Fair enough. I think technical users probably don't need this site, but I think there is value to be had (even for those technical users!).

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.

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

#39

Post by PNWChris »

OP here! Great discussion, it's made me realize I should also share my favorite speed test: https://www.waveform.com/tools/bufferbloat

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.

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

#40

Post by Matthias247 »

KMnO4 wrote: post #16
Matthias247 wrote: post #8

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…

Won’t the browser first do an OPTION before the test (GET) starts? The lookups should be cached.

you can check it in the network tab. It won't.
Post reply on HN