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 :(.
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).
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.
Yep, it's such a shame. Internode was great. Now that goes to AussieBroadband, their employees are great and their communication via whingepool is great.
For sure, AussieBroadband are (sample size of one) fantastic.
I particularly like that they've exposed some of the NBN troubleshooting tools to customers.
They also skipped over that "we'll provision more CVC capacity when we see it flatline for at least four hours a day" phase that most other retailers seemed to go through.
They don't quite have the same old school nerd appeal that Node had though. Things like free Usenet, games.on.net, unmetered downloads from the fairly well stocked mirror..
>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
>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.
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.
Side note: if you want to get a ballpark for one way latency, just measure the approximate distance of the undersea cable on Google Maps (in km) and divide by 155. That will give latency (in ms) to +/-10%, excluding any additional last-mile latency (Wi-Fi etc)
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.
The issue is TCP's congestion control needs to wait for an ack before sending the next packet so the latency kills throughput.
Changing to UDP would get rid of the congestion control but UDP on its own would have congestion issues killing its throughput.
Bittorrent created their own congestion control called ledbat and then added that onto UDP to create UTP which could help. There is also UDT which has its own congestion control algorithm designed for 10gbps+ connections, which would significantly fix the issue.
I would argue that drbd is the right thing 24x7 or zfs send. The problem with kind of bittorrent is, you have to retransfer the whole block and not just the packet, but could work too, interesting.
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.
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.
"Don't these cables ever break?
Yes! Cable faults are common. On average, there are over 100 each year.
You rarely hear about these cable faults because most companies that use cables follow a “safety in numbers” approach to usage, spreading their networks' capacity over multiple cables so that if one breaks, their network will run smoothly over other cables while service is restored on the damaged one.
Accidents like fishing vessels and ships dragging anchors account for two-thirds of all cable faults. Environmental factors like earthquakes also contribute to damage. Less commonly, underwater components can fail. Deliberate sabotage and shark bites are exceedingly rare. "
In this case it was about once a year and it was the only cable directly connecting the two locations. There was one occasion where there was a break only months after one was finally repaired, really frustrating. There are more cables taking that route now, so a bit of redundancy.
Most of the time I'd find out officially via network operators bulletin boards (i.e. those looking after AS and IXs) there wouldn't be anything reported in the local news because, for most people, as this article alludes to, the content edge servers they actually connect to are pretty close, both physically (distance) and virtually (hops).
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
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.
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.
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!
> 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.
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.
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)
However, the preflight check is sufficient to check latency :)
"Preflight check" is such a wrong analogy, since with CORS you fly all the way to the destination to check if you're allowed to fly to the destination.
Customs check basically. If you aren't allowed to bring something into the country you land in, they simply confiscate it when you get there. (And I'm sure arrest you and make you miserable because ... that's what justice is I guess.)
This is true. I’ve never seen an article or comment about CORS where someone didn’t disagree or add some major missing caveat. It’s never just a bunch of head nodding or “duh of course” responses.
I think CORS first sends an HTTP OPTIONS request. The headers received in the response dictate if the actual POST/PUT/GET/etc is sent to the server in a subsequent request.
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.
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!
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.
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.
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?)
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.
> "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.
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...
I also use OpenWRT with SQM (using cake queuing discipline) on a CM4 Pi to address buffer bloat. I don’t see any red blips, my latency is consistently between 20-40ms on Wi-Fi.
What hardware do you have? SQM is pretty CPU intensive. Mine is just powerful enough to be able to use SQM. Try checking if your cpu usage spikes from softirq interrupts.
I haven't played with OpenWRT SQM for a while, but if it's easy to reproduce with gfblip, it might be a simple matter of telling them your exact SQM settings and the URL to try.
Chances are changing the SQM backend (eg. between fq-codel and cake) will at least change the behaviour and likely make the bug go away.
Thanks! For posterity: I was previously using cake/piece_of_cake.qos. Changing to fq_codel/simple.qos made the blips go away, and seemingly does a better job of eliminating bufferbloat to boot.
fq_codel/simplest.qos made the blips worse instead of better. fq_codel/simplest_tbf.qos reduced but did not eliminate the blips.
that is a dismal ratio. I would set cake to turn on the ack-filter in this case on the upload. Also try comparing cake besteffort with your fq_codel implementation. MOST likely, from your report, you have some higher priority (via diffserv) traffic than blip going, and cake is actually doing the "right thing" by prioritizing that over the test.
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.
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.
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).
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.
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 :(
I was having exactly the problem GP described a few years ago, and this was the fix.
It just about drove me nuts. It got to the point where I replaced my AP, started dragging a 10 meter ethernet cable around my house for my laptop, and started to suspect esoteric things like the local airport weather radar triggering DFS[^1].
In the end, it just turned out to be the damn Location Services.
If this is the case I could kiss all of you. I will try tonight!
I even went down the path of buying new powerline adapters only to have the same problem. I was unplugging things in the house and factory resetting everything. I've felt like I was going to crazy lengths to troubleshoot.
As a temporary measure, am I able to simply switch off the WiFi on those Mac devices before running those commands, to test?
You should only need to turn it off on the devices you're running the tests on.
I should have conditioned my previous comment with "if this is happening on an Apple device". In case it helps, I described what's happening under-the-hood in another comment: https://news.ycombinator.com/item?id=33451879
That is an amazing rabbit hole and the linked fix for TeXstudio is awesome.
It's surprising to me how so many programs seem to check location on an interval timer, including programs that seem at a glance to have no reason to need to know the user's location. I wonder if there's some common SDK library that makes it easy to accidentally enable.
So should I assume this didn't get fixed in Ventura? I have a new MacBook and have been wondering if I should turn off location services or if Apple fixed this.
Location Services works by asking Apple if it knows the location of any of WiFi access points near you.† Apple knows these locations by using services like Skyhook who wardrive around mapping locations of BSSIDs (AP mac addresses).
So, when Location Services is on (which it is by default), macOS will periodically switch your wireless card to monitor mode to find those nearby WiFi access points. Doing so stops normal network traffic for around a few 100 ms on the device.
† On devices with a GPS (i.e. iPhones and iPads) it will also sometimes use the GPS, but does so sparingly because the GPS uses much more power.
Nit: Apple hasn't used Skyhook or Google for positioning in over a decade [1].
> Apple ditched both Skyhook and Google location services and began relying on its own databases starting with the release of iOS 3.2 for the first-generation iPad in April of 2010
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?
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.
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.
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 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.
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.
HTTP 1.1 and 2.0 do not require TCP, although that is by far the most common way they are used.
What overhead would TCP bring after the three-way handshake on a uncontested stable network without packet loss? I would expect it to be no more than UDP.
> traceroute on UN*X uses UDP by default. There is no overhead when using UDP.
You are correct. UDP will get you lower numbers, I was more of saying that TCP will not be much worse (maybe within 1ms) under good network conditions.
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.
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.
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?
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.
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.)
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.)
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).
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.
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
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.
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.
> 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.
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.
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.
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.
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)?
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.
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
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.
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
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.
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?
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.
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.
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 :(.