Blip: A tool for seeing your internet latency(github.com)
github.com
Blip: A tool for seeing your internet latency
https://github.com/apenwarr/blip
157 comments
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).
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.
(by the way, has anyone seen my orange watch?)
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?)
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.
We'll see how being public keeps this up..
We'll see how being public keeps this up..
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..
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
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
Probably more that most T1's in america don't peer so you end up going over HE/Cogent which is congested.
>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.
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)
* to local servers. Now that I've tried out blip on a 4g LTE connection it's around 50.
I have FTTP, so I get ~1ms-2ms to my ISP.
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.
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.
BBR for TCP should improve things?
Would UDP and something like bittorrent help?
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.
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.
(freezes) Did anyone else just hear something? No? Must have been the wind...
> 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?
You make it sound like every other day some UNDERSEA CABLE gets cut - that's not a once-in-a-blue-moon thing?
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'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.
Even rarer is something like the recent Shetland outage where virg cables were lost.
https://www2.telegeography.com/submarine-cable-faqs-frequent...
"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. "
"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. "
Sure but there’s 200 cables so that’s one break every 2 years on average.
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).
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
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
>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.
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.
I was thinking of streaming video, where the first load might be a lot heavier to buffer you to a state where you don't get choppy playback.
Yeah, regardless of throughput, you're going to have a bad time with interactive workloads with high latency.
Yeah, regardless of throughput, you're going to have a bad time with interactive workloads with high latency.
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.
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.
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.
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.
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
the connection has to go through HTTP (and not HTTPS) as GP states, if browser blocks requests
This should be in the README, I was getting only 2s red blips, constantly.
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.
> 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)
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.
"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.
It’s more of a cargo check, you fly all the way there to see if they’ll let you take some cargo back with you
*cargo isn’t really the right analogy… but close enough
*cargo isn’t really the right analogy… but close enough
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.)
Depends on the destination country and on exactly what it was you were trying to bring in with you.
Nah, the whole thing is just a "Can I ask you a question?" implemented in code.
Nah, the whole thing is just a "Can I ask you a question?" implemented in code.
That is a good point. I presume this site uses GETs just for simplicity but haven’t checked.
addendum: one can rarely state anything entirely accurate about CORS briefly.
addendum: one can rarely state anything entirely accurate about CORS briefly.
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.
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_...
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.
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.
That's hilarious, and probably explains why it takes a few seconds before it starts working.
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!
[deleted]
> 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?
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?
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:
https://github.com/apenwarr/blip/commit/4a1640977303f6dc58db...
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/4a1640977303f6dc58db...
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?)
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.
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.
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.
In switzerland no one would buy anything else then a symetric connection, normaly it's 1g/1g and for the same price if available 10g/10g
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 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.
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.
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.
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.
What exactly does the DNS checkbox do?
So nice to see gfblip and cake together again at long last.
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.
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.
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.
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).
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).
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.
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 :(
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 :(
Is there, by any chance, a MacOS-based machine running in your network?
Referring to this? https://apple.stackexchange.com/questions/263638/macbook-pro...
That's almost certainly it.
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.
[1]: https://en.wikipedia.org/wiki/Dynamic_frequency_selection
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.
[1]: https://en.wikipedia.org/wiki/Dynamic_frequency_selection
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?
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
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
apple's location services have cost me MUCH grief in developing newer versions of fq_codel for wifi, until we figured it out.
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.
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.
Your suspicion is correct. It's a Qt5 bug.[^1][^2][^3]
[1]: https://github.com/texstudio-org/texstudio/issues/62
[2]: https://bugreports.qt.io/browse/QTBUG-58936
[3]: https://bugreports.qt.io/browse/QTBUG-40332
[1]: https://github.com/texstudio-org/texstudio/issues/62
[2]: https://bugreports.qt.io/browse/QTBUG-58936
[3]: https://bugreports.qt.io/browse/QTBUG-40332
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.
It's actually intended behavior:
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.
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
[1] https://appleinsider.com/articles/13/07/03/skyhook-accuses-g...
> 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
[1] https://appleinsider.com/articles/13/07/03/skyhook-accuses-g...
And just think, it was this kind of clever thinking that got us Tailscale a decade later.
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.
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.
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.
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 multiple ring buffer timescales is genius!
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!
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.
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.
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.
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.
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
TCP probably has higher overhead, but even that is going to be next to nothing unless you've got packet loss
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.
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 HTTP/2.0 use TCP as the transport
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.
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.
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...
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.
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.
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.
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
Smokeping sounds like a comparable product - https://oss.oetiker.ch/smokeping/
Very useful for diagnosing ISP service interruptions
Very useful for diagnosing ISP service interruptions
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
Edit: Nvm it is because of https: https://news.ycombinator.com/item?id=33446511
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
https://iobureau.com/misc/21600-seconds-of-ping.jpg
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?
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?
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).
`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).
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.)
(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).
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.
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
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.
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.
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.
> 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.
> 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.
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
Seems to have coordinated with github going down....
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.
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?
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?
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.
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)?
Anybody know of a commandline tool equivalent to Blip? By that i mean a graphical presentation, something like `nload`:
https://github.com/rolandriegel/nload
https://github.com/rolandriegel/nload
Consumes 85% CPU on my Firefox. I'm sure both Firefox and this tool could do better.
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.
In my computer (also with Firefox) consumes less than 10% CPU and 18% of GPU
Is this site broken? On my 5G connection in iPhone safari I only see 2000 ms red blips.
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
How does this measure packet loss since this is only javascript and to my knowledge its not possible to measure packetloss with tcp connection.
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.
I use this tool https://www.pingplotter.com/
I've used pingplotter too. Good stuff.
Also https://ping.pe/ is good.
Also https://ping.pe/ is good.
Excellent tool!
Is there something in particular that could be causing red dots at 3 second intervals at or above 2000 milliseconds?
Is there something in particular that could be causing red dots at 3 second intervals at or above 2000 milliseconds?
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 ?
Is this a mac ?
Thank you! And yes, it’s a Mac!
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.
Requests get blocked for mixed content after a few seconds if the site is loaded with HTTPS.
Understood, thank you!
I tried with HTTP and the red dots or bars disappeared. With HTTPS they are there.
I tried with HTTP and the red dots or bars disappeared. With HTTPS they are there.
This has been my go to tool for checking my internet before playing an online multiplayer game.
Great tool, thanks!
Question - What are good ways to deal with dead zones?
Question - What are good ways to deal with dead zones?
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.
So happy to see so many sqm and cake users here.
it does not work with ad blocker ( brave )
how is my latency ??
https://ibb.co/YZRtJKX
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 :(.