Blip: A tool for seeing your internet latency

by tosh • 4 years ago

603 154 4 years ago

vlovich1233• 4 years ago

Hmmm… my iPhone has a steady stream of notches at 200ms on WiFi (nominally 20ms) and cellular (nominally 50ms). The pacing is at ~1cm intervals on my screen. I wonder if it’s on my end or on the website.

paulproteus• 4 years ago

I think phone wi-fi is just like this sometimes!

When I used ping to test my iPhone's wifi latency (1), I frequently saw 200ms results, even when the phone screen was on and I was using an app. Maybe there's aggressive power saving stuff causing latency on the network stack. I was very surprised as well. Friends with Google Pixel phones tried a similar test on their Wi-Fi networks and got similar results.

Edited to add: When I test with the Blip website, it never goes above 80ms for gstatic. Go figure.

1. Tested by a wired Mac pinging the default gateway, a Google Nest Wi-Fi Router, which was <1ms consistently, then I used the wired Mac to ping the phone

apenwarr7• 4 years ago

When you ping to the phone, you're probably running into the phone's power saving feature. When the phone generates the request, it stays powered up for a bit until the answer comes back, which is why you're not seeing the same random delay from blip.

vlovich1233• 4 years ago

No I don't think that's the explanation. Just got around to reading the github. All the blips are blue so it's the latency to this random website. I suspect the density difference is because the higher latency means you can do fewer req/s.

herpderperator• 4 years ago

So you might be wondering, hey, how did you make a javascript applet ping these arbitrary servers? What about cross-domain request protection?
Answer: I did it by just making the queries anyway, and seeing how long it takes to get the error message back that my request was refused because of cross-domain request protection. Yes, this results in an infinite number of error messages to your javascript console. Don't look at your javascript console and you'll be fine. Trust me on this.

zeptonaut22• 4 years ago

Love the cleverness here. I was literally wondering this exact thing as I read through the documentation.

I'm hoping to use his WiFi debugging guidance from the readme at my in-laws: I was just experiencing remote desktop problems despite having a strong network connection. I suspect the culprit is Comcast's supplied router.

RockRobotRock• 4 years ago

That's hilarious, and probably explains why it takes a few seconds before it starts working.

sublinear• 4 years ago

Not so clever after all. I haven't even opened dev tools yet and I suspect this technique is why it stops working and gives many people the solid bar. The server probably just stops responding after too many failed requests. Oops!

pprotas• 4 years ago

Is this actually the case or are you just judging the tool based on your assumption?

kqr• 4 years ago

Maybe you should have opened the dev tools after all -- that's not why it breaks in modern browsers!

stavros• 4 years ago

That's because you didn't load it over plain HTTP.

thakoppno2• 4 years ago

Also highlights an aspect of CORS that is occasionally misunderstood. The client sends the request no matter what. The response headers dictate whether the response is usable.

Mavvie• 4 years ago

Keep in mind this is only true for requests that don't require a preflight check.

This also means if you rely on CORS to prevent XSRF attacks (which is maybe not the best idea), you must be ensuring that any request that came in would have been preflighted (for example, reject requests unless they have a special header)

im-a-baby• 4 years ago

This isn't true in general. For many requests, an OPTIONS request is sent first. If the OPTIONS request contains permissive CORS headers, then the normal request proceeds. See: https://developer.mozilla.org/en-US/docs/Glossary/Preflight_...

cateye• 4 years ago

This is really cool.

I have quite some wifi issues at home but when I check things like ping everything seems normal.

I'm going to try this out when I have issues in a video meeting and see if there is a correlation.

FrasiertheLion• 4 years ago

There is one "site on the Internet" being pinged, the author's personal site. I'm guessing it would need to be hosted behind a CDN or so to provide this oracle that can be benchmarked against? Otherwise how would I know it's my internet that's bad (especially if my internet is quite good and sensitive enough to notice server side problems) and not the website failing in some way?

apenwarr7• 4 years ago

In general, the load generated by a series of these pings is so low as not to matter, unless a whole ton of people start doing it at once. But in that case, gfblip's trivial backend code will ask the frontends to slow down so that aggregate load stays low.

hypertexthero3• 4 years ago

Excellent tool!

Is there something in particular that could be causing red dots at 3 second intervals at or above 2000 milliseconds?

worthless-trash2• 4 years ago

Probably your wifi device doing network scanning. The "wifi" hardware packet ring is stalled while the results of the network scanning is completed.

Is this a mac ?

hypertexthero3• 4 years ago

Thank you! And yes, it’s a Mac!

kdrag0n4• 4 years ago

It doesn't work with HTTPS because the pings are done with HTTP requests. You have to disable HTTPS-only mode and load it over plain HTTP: http://gfblip.appspot.com/

Requests get blocked for mixed content after a few seconds if the site is loaded with HTTPS.

hypertexthero3• 4 years ago

Understood, thank you!

I tried with HTTP and the red dots or bars disappeared. With HTTPS they are there.

how2cflags• 4 years ago

If you've a cable modem with a Puma 6/7 chipset, it could possibly be the potential for said jitter. Sadly, I suffer from this issue and it annoys me to no end. Linking an old thread with more details about it. https://news.ycombinator.com/item?id=15781788

drewtato2• 4 years ago

There's definitely something wrong with this site. If I turn off HTTPS-only mode, it makes a perfectly straight green and red bar at 2000ms.

apenwarr7• 4 years ago

You might mean if you turn "on" HTTPS-only mode?

The silly trick blip uses involves pinging non-encrypted HTTP web servers, which is not allowed from an encrypted web page. So you really have to load blip from a non-encrypted server.

This code is from 10 years ago. Most likely we could find some way to work with HTTPS nowadays, but alas, I don't have time to maintain it.

drewtato2• 4 years ago

The page still loads in HTTPS, but turning off HTTPS-only mode means that the HTTP requests succeed, at least more than before. So I guess there's nothing wrong there.

The blue ticks actually don't work, though. They're always accompanied by red and seem to be timing out instead of the usual exceptions.

fmajid• 4 years ago

It might be from 10 years ago, but it's still incredibly useful.

I recently upgraded to a Mac Studio with 10GBase-T and was experiencing regular SSH disconnections. Blip allowed me to isolate this to some sort of sporadic incompatibility with the 10GBase-T SFP+ modules I used in my Ubiquiti switch (despite having tried two brands of SFP+). Switching to a switch with native 10GBase-T ports (Zyxel XGS1250-12, only £225) fixed this.

The multiple ring buffer timescales is genius!

obrajesse• 4 years ago

And just think, it was this kind of clever thinking that got us Tailscale a decade later.

blipper2022• 4 years ago

Nice tool! When I run it I get solid red blips at the 2000 ms level after just a couple of seconds. Here's what it looks like: https://imgur.com/a/bTA86qz Is there something strange going on with my network or ISP? fwiw, I'm running Brave on a Win10 laptop.

cwilby• 4 years ago

Couple of clues

The author mentioned the tool sends out requests, and just measures response time regardless of response status. (If they fail, they fail!)

And they measure response times from gstatic.com, which should have edge nodes near most locations.

Shot in the dark guess - perhaps you're hitting some kind of rate limit somewhere in that chain?

kdrag0n4• 4 years ago

It doesn't work with HTTPS because the pings are done with HTTP requests. You have to disable HTTPS-only mode and load it over plain HTTP: http://gfblip.appspot.com/

Requests get blocked for mixed content after a few seconds if the site is loaded with HTTPS.

marzell• 4 years ago

Mine looks exactly the same, and I can't prevent it from redirecting to https.

Wowfunhappy3• 4 years ago

So this is a bit annoying.

I use OpenWRT's Smart Queue Management package to avoid bufferbloat. Without it, sites like dslreports.net and fast.com show that my latency goes way up under load.

However, when I have SQM enabled, I see regular red blips with this tool. Disabling SQM makes the blips go away.

Strangely, even without SQM, latency as measured by this tool does not seem to change when I'm e.g. streaming a Youtube video in the background, as I would have expected given bufferbloat. (Does bufferbloat only apply to the specific packets being streamed?)

apenwarr7• 4 years ago

Oh neat! If you see occasional red blips, you have probably found a bug (or misconfiguration) in your OpenWRT SQM. gfblip doesn't lie. In fact, I created it to find annoying router bugs like this. If you click the "DNS" checkbox you can find all sorts of terrible router bugs.

It's not too surprising that you don't see latency increase under light load like Youtube. "Under load" really means uploading (especially) or downloading (sometimes) at maximum speed. But Youtube usually doesn't download at maximum speed, because that would imply you can't keep up with its streaming video rate, and you'd get glitches. So your connection is likely not really "under load" at that time. Try uploading a large file somewhere and you should see an immediate change in blips.

Wowfunhappy3• 4 years ago

I don't suppose you have any suggestions on what to do about it? I'm now wondering if I should keep sqm off and deal with bufferbloat. I already give up a chunk of my limited bandwidth for it (my connection is only 20mb down / 3mb up).

I don't think I understand this enough to file a good bug report...

easrng2• 4 years ago

I'm also seeing consistently spaced red blips.

joshspankit2• 4 years ago

"Under load" really means uploading (especially)

In retrospect the industry really got shot in the foot on this ISP bandwidth race. ISP marketing kept going for bigger and bigger numbers but marketing only needs one big number (download speed) to sell subscriptions and so upload speed was de-prioritized leaving us with these wildly asymmetric connections (standard around here is 300/10), but if the upload is saturated (easy to do) the TCP Acknowledge packets can’t make it out and the whole connection grinds to a halt.

dave_taht6• 4 years ago

So nice to see gfblip and cake together again at long last.

Nux• 4 years ago

What exactly does the DNS checkbox do?

joshspankit2• 4 years ago

In many cases this is actually expected: Some of the SQM algorithms work by “penalizing” some packets and therefore signalling to the sender that it needs to slow down in order to get future packets through successfully.

Those red marks are kind of a “slap on the wrist” that keeps the sender in line.

P.s. Try downloading something that can send to you at 200MBps (and therefore saturate your connection) or something that can receive file uploads at 10Mbps, or do both at the same time and see what that does to the test results.

wtallis• 4 years ago

Bufferbloat isn't when buffers are so full that they cannot accept more traffic; it's when buffers are so big they never get full enough to cause packet drops (the slowdown signal the sender needs), but are big enough that packets spend an unreasonable amount of time waiting in line.

And a good SQM algorithm shouldn't be shooting down packets from a tool like this unless the configured bandwidth limits are really low, because this tool isn't really generating all that much traffic.

triggercut3• 4 years ago

I never really appreciated the relationship and importance of bandwidth, latency and packet loss until I had to move a small office from all on-prem infrastructure to completely cloud based at a regional data centre, about 10 years ago. And I mean completely. locally we had firewall, router, riverbed, UPS that's it for max 40 people. No data at rest (besides riverbed cache) due to security.

We had ridiculous bandwidth for the time, which users knew, and they would often come and ask "why can I stream youtube in HD but accessing my document/file takes ages" (ages being anything more than 2-3 seconds). A perfectly valid question. The answer was usually "illegal fishing", or "sharks". If the primary sub-sea cable was cut, we'd have to route through another which would add at least 400ms round trip extra.

Luckily this was a well known risk/issue for our parent company who had a team dedicated to negotiating peering and routing between office locations and their nearest regional DCs (these were not azure, aws, etc. usually local IX or Teclco). But they couldn't do anything about the sharks :(.

alexeldeib2• 4 years ago

A great example too -- initial page/content load for text/docs, vs continuous streaming which could be workable with arbitrary latency compensation as long as you do really have sufficient bandwidth. The start time might suck, but once you're going, you're going.

I had to double take when I saw illegal fishing, I thought you meant the digital kind and my mind went to ddos/similar :P

midoridensha• 4 years ago

The start time might suck, but once you're going, you're going.

Average users will barely even notice a start time of up to 1 second. 500ms will seem fast to them, for starting a video.

Typing a document in Google Docs and having a 1000ms round-trip latency for every letter they type, however, will quickly become annoying.

StillBored2• 4 years ago

Yah, if you really want it hammered home, find something that is considered a long fat pipe and try to max it out.

About a decade ago, one of our customers had a 25Gbit (IIRC) line that went cross country and had something like 150ms of latency. Then after hours they would basically cross replicate their entire data center through a couple machines they purchased from us (running some of our software). While their packet loss was fairly trivial, it was enough to cause some serious pain. Explaining why, if they insisted on TCP they were going to need an enormous amount of ram (for the time) in order to keep the thing running at line rate took about 6 months... Eventually someone ponied up the $$$$ for the ram, and the problem went away, and it sat there happily doing its thing, with only the occasional problems caused by other departments trying their own experiments and killing its throughput.

eru• 4 years ago

BBR for TCP should improve things?

quickthrower2• 4 years ago

Would UDP and something like bittorrent help?

thejosh3• 4 years ago

Yes. It's all well and good having gigabit+ connections, but latency is the killer.

Here in Perth, Western Australia we are very far from everything. In the 90s/early 2000's our routing and latency was pretty terrible, especially over dialup and slow connections and that's how I thought online gaming was (300ms+++).

When there started to be "local" servers in Adelaide (thanks Internode!) and Sydney, this went down to 25-30ms for adelaide and 50ms for Sydney.

Now we have undersea cables to Singapore from Perth, so we actually get 2ms lower latency from PER->SNG than PER->SYD! Sometimes I get weird routing through Asia if a service determines I'm better suited for that. There is apparently also a cable from PER->Europe now, where we now get less latency to EU (it's now less than US, crazy).

djhn2• 4 years ago

Out of curiosity, what kind of ping do you have now in absolute terms? I think mine is in the region of 1-2ms (Europe), but I do remember having double digit ping.

aussieshibe2• 4 years ago

It's a shame Internode went the way it did after iiNet/TPG took over.

Old Node was one of those rare companies where I actually believed they put their customers and employees before their bottom line. It's just TPG with different branding now.

(by the way, has anyone seen my orange watch?)

triggercut3• 4 years ago

Sometimes I get weird routing through Asia if a service determines I'm better suited for that.

It's a mix of traffic, peering agreements between providers* and QoS rules on the routers you hop through along the way. After your request leaves your ISPs hardware often you have no choice where it goes next.

Something that wasn't mentioned was that this is why traders will pay millions to set up servers in DCs/IXs all the way between them and the market so they have more control over the route their traffic takes. Sometimes even running their own cables.

SEA-ME-WE-3, the cable you were talking about was the only game in town for that side of the country until about 4 years ago when ASC came online. ASC has over 10 times the capacity (60Tbit/s) of SEA-ME-WE-3 which was below 1 Tbit/s until 2009 and is not only 4.6 Tbit/s according to wiki. It's worth noting that SEA-ME-WE-3 is administered by Singtel there are 90+ other investors (who were all getting preference or had capacity agreements at launch).

* this is complicated, someone feel free to correct/expand but essentially carriers will lease capacity over particular connections and sometimes the agreements between two carriers will mean particular customers traffic may get preference, so on busy lines, businesses paying for higher SLAs get prefered over regular consumers who might shunted off to a lower grade connection where there's space.

There's a great example with NTT's partnership with Formula 1 where NTT engineers go in before race day to location making sure all that incredible Digital Twin data is getting fed back-to-base to manufacturer's HQs in the UK or Germany etc. as fast as possible. Sure there's the pit crew, but there's a whole team back home who are watching and analysing data and relaying advice. F1 is really an incredible technical feat in more ways than just the cars.

867-5309• 4 years ago

Sometimes I get weird routing through Asia if a service determines I'm better suited for that. There is apparently also a cable from PER->Europe now, where we now get less latency to EU (it's now less than US, crazy).

strangely I found the same was true for reliable video streaming from NZ to UK

instead of Auckland > Sydney > California > New York > London, the optimal path undoubtedly proved to be Auckland > Sydney > Singapore > NoMansLand > London

traversing America introduces all sorts of problems, I'm guessing due to deep packet inspection rather than distance

club_tropical• 4 years ago

The answer was usually "illegal fishing", or "sharks".

You make it sound like every other day some UNDERSEA CABLE gets cut - that's not a once-in-a-blue-moon thing?

midasuni2• 4 years ago

I haven’t found a good source of news on submarine cable cuts/fixes, but anecdotally it’s not that often - maybe once a year on cables through suez. Atlantic you never notice.

Even rarer is something like the recent Shetland outage where virg cables were lost.

jeroenhd• 4 years ago

Worldwide, there's a cable break about once every three days. How much that affects you depends on the backup infrastructure and your current location. Submarine cables getting damaged is all but uncommon.

I'd expect cables through the Atlantic or Pacific ocean to get damaged much more rarely than cables through your local lake. Shallow waters and sports/amateur boating can damage the cables in shallower waters more easily than in the humongous depths of the greater oceans in the world.

enos_feedler• 4 years ago

The tool I use for seeing my internet latency is the one yelling “oh man this guys lag suuucks” over the live chat when I’m gaming on my ps4

aliqot2• 4 years ago

For some reason the name apenwarr reminds me of old hacker zines. I have Apenwarr near Attrition.org and Ankit Fadia from around late 90's. Is this someone else with the same name?

apenwarr7• 4 years ago

I've been on the Internet for a long time, including doing Debian stuff (popularity contest!) back in the 1990s. I don't know what attrition.org is though.

aliqot2• 4 years ago

Attrition is just another entry from the A's section where you were. I think you were mentioned in a txtphile or zine, but can't find the reference. Either way, good on ya. Thanks for your work.

AdamJacobMuller• 4 years ago

Seems to have coordinated with github going down....

kdrag0n4• 4 years ago

Looks like this doesn't work with HTTPS because the pings are done with HTTP requests. You have to disable HTTPS-only mode and load it over plain HTTP: http://gfblip.appspot.com/

Requests get blocked for mixed content if the site is loaded with HTTPS. That's what causes the constant stream of red blips after a few seconds.

pindab0ter• 4 years ago

From the README:

So you might be wondering, hey, how did you make a javascript applet ping these arbitrary servers? What about cross-domain request protection?

Answer: I did it by just making the queries anyway, and seeing how long it takes to get the error message back that my request was refused because of cross-domain request protection. Yes, this results in an infinite number of error messages to your javascript console. Don't look at your javascript console and you'll be fine. Trust me on this.

r618• 4 years ago

it's not enough to just "not look at javascript console"

the connection has to go through HTTP (and not HTTPS) as GP states, if browser blocks requests

Manjuuu• 4 years ago

This should be in the README, I was getting only 2s red blips, constantly.

therealdrag0• 4 years ago

This has been my go to tool for checking my internet before playing an online multiplayer game.

bscphil2• 4 years ago

I see ping times consistently around 10ms on my WiFi connection. However, it sometimes briefly spikes upward (while remaining green). Based on the behavior of the line, I think this might be happening when the bit of JavaScript drawing the line on the canvas staggers, rather than a blip in the connection itself. Probably a bug? It's quite noticeable when resizing the window, for example.

(I don't think it's the connection being flaky. Running `ping gstatic.com` in the terminal at the same time as the webpage is in the foreground shows a maximum time of 23ms after 180 pings.)

bscphil2• 4 years ago

Oh, another bug - if you have XHR connections blocked with a tool like uMatrix, the site will assume that the time-to-failed-connection is actually the successful round-trip time, so I was getting very low numbers in Firefox. (The test in the comment above was in Chromium.)

Rimintil3• 4 years ago

ICMP echo requests are often rate-limited and/or deprioritized traffic on most major routers. If forwarded _through_ the router, it'll be on the slow path (software-based handling of packets) -- if forwarded _to_ the router, it'll often be on the control plane which is backed by a typically fairly slow CPU.

Ping/tracert will give you a _general_ idea of what is going on, but it is not something to definitively answer a question (i.e., a tracert may have an asymmetrical path -- travel one route to the destination, but the return packets travel another route, which you'll never see).

NoPicklez3• 4 years ago

Slightly on topic, I have been experiencing packet loss in a game that I'd not had for years. Seemingly at the same time my powerline adapters have been disconnecting.

It's extremely hard (I've found it) to identify if packet loss is a problem in your house, or with the service you're using. Also, if you don't have a baseline for how your network normally operates, everything looks like a nail when you go digging.

I was having packet loss problems every 5 seconds in a particular game where it would spike up to around 15% then recover. I ran a ping plot to the router at 0.1x per second and had absolutely no packet loss. So is it me or is it the game server.

a1445c8b2• 4 years ago

Is there, by any chance, a MacOS-based machine running in your network?

NoPicklez3• 4 years ago

There are two!

bobbylarrybobby• 4 years ago

Referring to this? https://apple.stackexchange.com/questions/263638/macbook-pro...

jdaxe• 4 years ago

I just wanted to say that I've been experiencing the same issue, I'm not sure if it's packet loss or just high latency spikes but I notice it while playing a game (in my case the game is Old School Runescape). I've tried switching ISP but that didn't really fix the problem, I get latency problems using both ethernet (via powerline adapter) and WiFi. I think the next thing to try would be to switch to a different router/modem (I'm currently using the ISP provided one). If you ever figure out your problem let me know what your solution was.

Others that play the same game don't seem to experience the lag spikes as badly as I do, but I'm not sure whether they just get routed differently or if the problem is in my house or close to my house :(

standardUser• 4 years ago

My worst latency issues (and I've had several debilitating ones over the decades) were nothing more than overzealous anti-virus programs. Some update must have done something to break the program, which had otherwise been running quietly in the background for 3 or 4 years. I think others were temporary ISP issues, and maybe once I even had to replace a wire? But they've always been a nightmare to debug.

StillBored2• 4 years ago

Linux users with bad results might try:

`iw dev $interfacename set power_save off`

Linux on various laptops/kernel's has been known to be a little too aggressive with the power savings and it absolutely kills first ping latency.

(Although at first glance this thing might be fast enough not to notice).

paulv• 4 years ago

I discovered this issue on my rpi3 and rpi4s. There is always just enough latency when using ssh to drive me up a wall, but it went away when I tried to debug with ping. The first ping packet always took a bit longer than the others. I just assumed that was because of the arps, until I checked with tcpdump. Turning power_save off solved the problem immediately.

xwowsersx2• 4 years ago

This is a great tool, thank you!

So, on my Pixel 6, I see pretty bad latency: https://ibb.co/ft4ZmJr On my Mac, it looks decent: https://ibb.co/XJMXSzm

What can be done to improve it?

telotortium• 4 years ago

Broken on HTTPS, use http://gfblip.appspot.com

xwowsersx2• 4 years ago

Ohh, I see. Thank you!

Rimintil3• 4 years ago

This isn't measuring "Internet" latency but rather HTTP with all it's overhead, right?

When you connect to your favorite MMO, etc., it's doubtful that you're using the HTTP protocol to do so.

Still useful, but for one of many "Internet"-based scenarios.

shepherdjerred2• 4 years ago

The overhead of HTTP should be negligible. I can't imagine it taking even a ms to form an empty GET request

TCP probably has higher overhead, but even that is going to be next to nothing unless you've got packet loss

Rimintil3• 4 years ago

HTTP/1.1 and HTTP/2.0 use TCP as the transport, so not only do you have the TCP overhead, but you have the HTTP overhead. There is additional overhead if using HTTPS.

traceroute on UN*X uses UDP by default. There is no overhead when using UDP.

ICMP Echo, I'm not sure about, but I don't believe it has overhead, but as I said, it is a depriortized and possibly rate-limited by routers.

crummy• 4 years ago

I don't understand why my blue blips seem so terrible. https://imgur.com/a/FwFCXUq

If I ping apenwarr.co I get consistent results:

Pinging apenwarr.ca [74.207.252.179] with 32 bytes of data: Reply from 74.207.252.179: bytes=32 time=203ms TTL=51 Reply from 74.207.252.179: bytes=32 time=202ms TTL=51 Reply from 74.207.252.179: bytes=32 time=205ms TTL=51 Reply from 74.207.252.179: bytes=32 time=202ms TTL=51

And on my mobile, on the same network, my blue blips look normal enough. Just not on my wired desktop.

jsherwani• 4 years ago

The app is doing an http(s?) request, which includes more round trips than a simple ping. Also, the web server may be more loaded than the ping response would indicate.

Aachen2• 4 years ago

Usually not. I got a similar "ping" page on my website but haven't found a browser that closes the TLS connection between secondly requests. Also built a websocket version but that turned out to only be useful as canary because it doesn't survive connection changes.

julian_sark• 4 years ago

Great tool. Just one thing: please make an option to distinguish blips by something else than color. Like many people, I can not see the difference between red and black/grey/whatever especially for very thin, small elements on screen. Thanks!

perryizgr8• 4 years ago

Does not work on Samsung Galaxy S10 (Chrome, Samsung Internet, Edge). It seems to work for half a second and then continuous red marks on the graph. Seems like some sort of blocking?

Edit: Nvm it is because of https: https://news.ycombinator.com/item?id=33446511

dave_taht6• 4 years ago

So happy to see so many sqm and cake users here.

ComodoHacker• 4 years ago

Consumes 85% CPU on my Firefox. I'm sure both Firefox and this tool could do better.

edgartaor• 4 years ago

In my computer (also with Firefox) consumes less than 10% CPU and 18% of GPU

Aachen2• 4 years ago

I noticed my phone getting hot also (manufacturer put too fast a cpu in this little thing so 5 seconds of 100% use is immediately noticeable on the back center left where I presume it must be located). As someone who built a similar service with no such issues, I can confidently say it's not Firefox.

throw__2sdfw• 4 years ago

How does this measure packet loss since this is only javascript and to my knowledge its not possible to measure packetloss with tcp connection.

pgorczak• 4 years ago

It doesn’t measure packet loss, but since there is one tiny request in flight at a time, it ends up in a single IP packet with packet loss being visible as retransmissions / outliers taking multiples of your average round trip time.

Jedd• 4 years ago

6pm Sydney AU time (evening contention is ramping up) and Starlink looks like this:

https://imgur.com/a/Gyst24q

A few hours earlier and I was seeing regular red blips, but the service is definitely highly variable. I'm also bouncing through two Unifi AP's before I hit the uplink.

Use of 'ping' was a bit confusing, as it's obviously not ICMP. I'd hoped Animats might have popped in with some observations around how his algorithm may help (or hinder) this kind of test. : )

Someone mentioned Riverbed (Steelheads) which have lots of knobs you can turn to deal with high latency and/or non-reliable connections - around window sizes, backoff / congestion settings, SCPS, and of course Nagle (or Neural Framing, as they called it, IIRC).

igauravsehrawat• 4 years ago

I use this tool https://www.pingplotter.com/

collinmanderson• 4 years ago

I've used pingplotter too. Good stuff.

Also https://ping.pe/ is good.

rcarmo• 4 years ago

This is a brilliant hack. Am currently on a train and I can assure you that the amount of red mirrors my experience quite accurately...

js22• 4 years ago

Green blips are your ping time to gstatic.com

Rather, it seems to be pinging my router (192.168.1.1).

Blue blips are your ping time to apenwarr.ca

Rather, it seems to be pinging something in "Mexico City, MX" or "Moncton, CA":

https://imgur.com/a/NmC5Ns0

What does the DNS checkbox do?

js22• 4 years ago

Answering my own questions.

There is a hard-coded list of RFC 1918 addresses that are commonly used as routers that the program tries first to see if they are faster than gstatic.com.

https://github.com/apenwarr/blip/commit/b284f922b047e9032112...

Instead of apenwarr.ca, the code tries a bunch of sites from measurementlab.net:

https://github.com/apenwarr/blip/commit/20f99c1d641e8cc607b6...

The DNS checkbox does the following:

  Generate a pseudorandom hostname for each test and looks it
  up in DNS.  The hostname happens to be in a domain that returns a valid
  IP (incidentally always the same one) for every hostname you ask for.
  This triggers a new HTTP connection, but also validates that your DNS
  is working reliably without weird dropouts.  I made it optional for
  two reasons: it hits your DNS server pretty hard, which is more rude
  than blip is usually; and DNS is surprisingly crappy, so you might want
  to turn it off while looking to see if you have *non* DNS related
  problems.

https://github.com/apenwarr/blip/commit/0678d0668c14e2c7a7f0...

https://github.com/apenwarr/blip/commit/4a1640977303f6dc58db...

2Gkashmiri• 4 years ago

how is my latency ?? https://ibb.co/YZRtJKX

evertedsphere• 4 years ago

So you might be wondering, hey, how did you make a javascript applet ping these arbitrary servers? What about cross-domain request protection?
Answer: I did it by just making the queries anyway, and seeing how long it takes to get the error message back that my request was refused because of cross-domain request protection. Yes, this results in an infinite number of error messages to your javascript console. Don't look at your javascript console and you'll be fine. Trust me on this.

pliptvo• 4 years ago

Great tool, thanks!

Question - What are good ways to deal with dead zones?

pcthrowaway• 4 years ago

Haven't popular browsers made some changes to how CORS works to interfere with attackers using timing attacks on the targeted cross-origins? And won't those interfere with part of the result from Blip (which hasn't been updated for 5 years)?

n4r9• 4 years ago

If you run linux (possibly also unix) it's not too hard to set something similar up locally. For example, add the following to your crontab:

  ping -c 4 gstatic.com | tail -1| awk '{print $4}' | cut -d '/' -f 2 | ts '%F %T' >> pinglog.txt

and tail the log file or use a tool like LiveGraph (https://live-graph.sourceforge.net/) to get a live graph of it.

tesin• 4 years ago

Smokeping sounds like a comparable product - https://oss.oetiker.ch/smokeping/

Very useful for diagnosing ISP service interruptions

RadixDLT• 4 years ago

it does not work with ad blocker ( brave )

janandonly• 4 years ago

Is this site broken? On my 5G connection in iPhone safari I only see 2000 ms red blips.

dbmnt• 4 years ago

Basically. It doesn't work with https. It also doesn't like mixed-content protection. So it doesn't work in modern browsers unless you jump through some hoops. https://github.com/apenwarr/blip/issues/10

apankrat• 4 years ago

Sort of tangentially related - few years ago and for no particular reason I pinged HN server for 6 hours and then made a "data viz poster" out of it -

https://iobureau.com/misc/21600-seconds-of-ping.jpg

DavideNL• 4 years ago

Anybody know of a commandline tool equivalent to Blip? By that i mean a graphical presentation, something like `nload`:

https://github.com/rolandriegel/nload

Blip: A tool for seeing your internet latency

Related Stories