[HN Gopher] Blip: A tool for seeing your internet latency
___________________________________________________________________
Blip: A tool for seeing your internet latency
Author : tosh
Score : 546 points
Date : 2022-11-03 00:52 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| throw__2sdfw wrote:
| How does this measure packet loss since this is only javascript
| and to my knowledge its not possible to measure packetloss with
| tcp connection.
| pgorczak wrote:
| 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.
| n4r9 wrote:
| If you run linux (possibly also unix) it's not too hard to set
| something similar up locally. For example, add the following to
| your crontab: ping -c 4 gstatic.com | tail -1|
| awk '{print $4}' | cut -d '/' -f 2 | ts '%F %T' >> pinglog.txt
|
| and tail the log file or use a tool like LiveGraph (https://live-
| graph.sourceforge.net/) to get a live graph of it.
| tesin wrote:
| Smokeping sounds like a comparable product -
| https://oss.oetiker.ch/smokeping/
|
| Very useful for diagnosing ISP service interruptions
| Wowfunhappy wrote:
| 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?)
| apenwarr wrote:
| 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.
| dave_taht wrote:
| So nice to see gfblip and cake together again at long last.
| Nux wrote:
| What exactly does the DNS checkbox do?
| easrng wrote:
| I'm also seeing consistently spaced red blips.
| argc wrote:
| Same, but only when I go over my companies vpn.
| dave_taht wrote:
| I'm always interested in packet captures of observed
| misbehavior.
| joshspankit wrote:
| > "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.
| nix23 wrote:
| 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
| Wowfunhappy wrote:
| 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...
| raggi wrote:
| I get red all the time in Firefox, chrome is healthy.
|
| I have cake configured on my border router.
| dave_taht wrote:
| so nice to see so many using cake.
| beeandapenguin wrote:
| 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.
| apenwarr wrote:
| 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.
| Wowfunhappy wrote:
| 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.
| dave_taht wrote:
| 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.
| joshspankit wrote:
| In many cases this is actually expected: Some of the SQM
| algorithms work by "penalizing" some packets and therefore
| signalling to the sender that it needs to slow down in order to
| get future packets through successfully.
|
| Those red marks are kind of a "slap on the wrist" that keeps
| the sender in line.
|
| P.s. Try downloading something that can send to you at
| _200MBps_ (and therefore saturate your connection) or something
| that can receive file uploads at 10Mbps, or do both at the same
| time and see what that does to the test results.
| wtallis wrote:
| 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.
| xwowsersx wrote:
| This is a great tool, thank you!
|
| So, on my Pixel 6, I see pretty bad latency:
| https://ibb.co/ft4ZmJr On my Mac, it looks decent:
| https://ibb.co/XJMXSzm
|
| What can be done to improve it?
| telotortium wrote:
| Broken on HTTPS, use http://gfblip.appspot.com
| xwowsersx wrote:
| Ohh, I see. Thank you!
| triggercut wrote:
| 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 :(.
| club_tropical wrote:
| > 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?
| midasuni wrote:
| 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.
| triggercut wrote:
| 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).
| harywilke wrote:
| 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. "
| midasuni wrote:
| Sure but there's 200 cables so that's one break every 2
| years on average.
| jeroenhd wrote:
| 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.
| thejosh wrote:
| 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).
| aussieshibe wrote:
| 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?)
| thejosh wrote:
| 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..
| 867-5309 wrote:
| >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
| hyperionplays wrote:
| Probably more that most T1's in america don't peer so you
| end up going over HE/Cogent which is congested.
| djhn wrote:
| 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.
| adamcharnock wrote:
| 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)
| thejosh wrote:
| I have FTTP, so I get ~1ms-2ms to my ISP.
| djhn wrote:
| * to local servers. Now that I've tried out blip on a 4g
| LTE connection it's around 50.
| triggercut wrote:
| >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.
| alexeldeib wrote:
| A great example too -- initial page/content load for text/docs,
| vs continuous streaming which could be workable with arbitrary
| latency compensation as long as you do really have sufficient
| bandwidth. The start time might suck, but once you're going,
| you're going.
|
| I had to double take when I saw illegal fishing, I thought you
| meant the digital kind and my mind went to ddos/similar :P
| midoridensha wrote:
| >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.
| alexeldeib wrote:
| 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.
| StillBored wrote:
| 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.
| quickthrower2 wrote:
| Would UDP and something like bittorrent help?
| nix23 wrote:
| 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.
| dumpsterdiver wrote:
| (freezes) Did anyone else just hear something? No? Must
| have been the wind...
| nix23 wrote:
| Why you freeze?
| dangerface wrote:
| 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.
| eru wrote:
| BBR for TCP should improve things?
| enos_feedler wrote:
| 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
| janandonly wrote:
| Is this site broken? On my 5G connection in iPhone safari I only
| see 2000 ms red blips.
| hypertexthero wrote:
| Excellent tool!
|
| Is there something in particular that could be causing red dots
| at 3 second intervals at or above 2000 milliseconds?
| kdrag0n wrote:
| 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.
| hypertexthero wrote:
| Understood, thank you!
|
| I tried with HTTP and the red dots or bars disappeared. With
| HTTPS they are there.
| how2cflags wrote:
| 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
| worthless-trash wrote:
| 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 ?
| hypertexthero wrote:
| Thank you! And yes, it's a Mac!
| apankrat wrote:
| 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
| 2Gkashmiri wrote:
| how is my latency ?? https://ibb.co/YZRtJKX
| aliqot wrote:
| 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?
| apenwarr wrote:
| 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.
| aliqot wrote:
| 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.
| ComodoHacker wrote:
| Consumes 85% CPU on my Firefox. I'm sure both Firefox and this
| tool could do better.
| edgartaor wrote:
| In my computer (also with Firefox) consumes less than 10% CPU
| and 18% of GPU
| Aachen wrote:
| 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.
| rcarmo wrote:
| 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...
| pliptvo wrote:
| Great tool, thanks!
|
| Question - What are good ways to deal with dead zones?
| NoPicklez wrote:
| 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.
| a1445c8b wrote:
| Is there, by any chance, a MacOS-based machine running in your
| network?
| NoPicklez wrote:
| There are two!
| a1445c8b wrote:
| Check out the link shared by @bobbylarrybobby.
| bobbylarrybobby wrote:
| Referring to this?
| https://apple.stackexchange.com/questions/263638/macbook-
| pro...
| hoosieree wrote:
| 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.
| runlevel1 wrote:
| 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
| runlevel1 wrote:
| 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
| NoPicklez wrote:
| 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?
| runlevel1 wrote:
| 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
| dave_taht wrote:
| apple's location services have cost me MUCH grief in
| developing newer versions of fq_codel for wifi, until we
| figured it out.
| wscott wrote:
| 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.
| runlevel1 wrote:
| 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.
| vlovich123 wrote:
| 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...
| kdrag0n wrote:
| 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.
| Manjuuu wrote:
| This should be in the README, I was getting only 2s red blips,
| constantly.
| pindab0ter wrote:
| From the README:
|
| _So you might be wondering, hey, how did you make a javascript
| applet ping these arbitrary servers? What about cross-domain
| request protection?_
|
| _Answer: I did it by just making the queries anyway, and
| seeing how long it takes to get the error message back that my
| request was refused because of cross-domain request protection.
| Yes, this results in an infinite number of error messages to
| your javascript console. Don 't look at your javascript console
| and you'll be fine. Trust me on this._
| r618 wrote:
| 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
| cateye wrote:
| 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.
| perryizgr8 wrote:
| 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
| crummy wrote:
| I don't understand why my blue blips seem so terrible.
| https://imgur.com/a/FwFCXUq
|
| If I ping apenwarr.co I get consistent results:
|
| Pinging apenwarr.ca [74.207.252.179] with 32 bytes of data: Reply
| from 74.207.252.179: bytes=32 time=203ms TTL=51 Reply from
| 74.207.252.179: bytes=32 time=202ms TTL=51 Reply from
| 74.207.252.179: bytes=32 time=205ms TTL=51 Reply from
| 74.207.252.179: bytes=32 time=202ms TTL=51
|
| And on my mobile, on the same network, my blue blips look normal
| enough. Just not on my wired desktop.
| jsherwani wrote:
| 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.
| Aachen wrote:
| 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.
| therealdrag0 wrote:
| This has been my go to tool for checking my internet before
| playing an online multiplayer game.
| standardUser wrote:
| 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.
| AdamJacobMuller wrote:
| Seems to have coordinated with github going down....
| vlovich123 wrote:
| Hmmm... my iPhone has a steady stream of notches at 200ms on WiFi
| (nominally 20ms) and cellular (nominally 50ms). The pacing is at
| ~1cm intervals on my screen. I wonder if it's on my end or on the
| website.
| paulproteus wrote:
| 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
| apenwarr wrote:
| 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.
| vlovich123 wrote:
| 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.
| bscphil wrote:
| 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.)
| bscphil wrote:
| 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.)
| Rimintil wrote:
| 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).
| dave_taht wrote:
| So happy to see so many sqm and cake users here.
| js2 wrote:
| > 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?
| js2 wrote:
| Answering my own questions.
|
| There is a hard-coded list of RFC 1918 addresses that are
| commonly used as routers that the program tries first to see if
| they are faster than gstatic.com.
|
| https://github.com/apenwarr/blip/commit/b284f922b047e9032112...
|
| Instead of apenwarr.ca, the code tries a bunch of sites from
| measurementlab.net:
|
| https://github.com/apenwarr/blip/commit/20f99c1d641e8cc607b6...
|
| The DNS checkbox does the following: Generate a
| pseudorandom hostname for each test and looks it up in
| DNS. The hostname happens to be in a domain that returns a
| valid IP (incidentally always the same one) for every
| hostname you ask for. This triggers a new HTTP
| connection, but also validates that your DNS is working
| reliably without weird dropouts. I made it optional for
| two reasons: it hits your DNS server pretty hard, which is more
| rude than blip is usually; and DNS is surprisingly
| crappy, so you might want to turn it off while looking to
| see if you have *non* DNS related problems.
|
| https://github.com/apenwarr/blip/commit/0678d0668c14e2c7a7f0...
|
| https://github.com/apenwarr/blip/commit/4a1640977303f6dc58db...
| pcthrowaway wrote:
| 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)?
| evertedsphere wrote:
| StillBored wrote:
| Linux users with bad results might try:
|
| `iw dev $interfacename set power_save off`
|
| Linux on various laptops/kernel's has been known to be a little
| too aggressive with the power savings and it absolutely kills
| first ping latency.
|
| (Although at first glance this thing might be fast enough not to
| notice).
| paulv wrote:
| 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.
| drewtato wrote:
| 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.
| apenwarr wrote:
| 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.
| drewtato wrote:
| 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.
| obrajesse wrote:
| And just think, it was this kind of clever thinking that got us
| Tailscale a decade later.
| blipper2022 wrote:
| 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.
| kdrag0n wrote:
| It doesn't work with HTTPS because the pings are done with HTTP
| requests. You have to disable HTTPS-only mode and load it over
| plain HTTP: http://gfblip.appspot.com/
|
| Requests get blocked for mixed content after a few seconds if
| the site is loaded with HTTPS.
| marzell wrote:
| Mine looks exactly the same, and I can't prevent it from
| redirecting to https.
| kdrag0n wrote:
| You probably have HTTPS-only mode enabled in browser
| settings. (or the HTTPS Everywhere extension)
| cwilby wrote:
| 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?
| RadixDLT wrote:
| it does not work with ad blocker ( brave )
| igauravsehrawat wrote:
| I use this tool https://www.pingplotter.com/
| collinmanderson wrote:
| I've used pingplotter too. Good stuff.
|
| Also https://ping.pe/ is good.
| Jedd wrote:
| 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).
| herpderperator wrote:
| > 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.
| sublinear wrote:
| Not so clever after all. I haven't even opened dev tools yet
| and I suspect this technique is why it stops working and gives
| many people the solid bar. The server probably just stops
| responding after too many failed requests. Oops!
| pprotas wrote:
| Is this actually the case or are you just judging the tool
| based on your assumption?
| stavros wrote:
| That's because you didn't load it over plain HTTP.
| [deleted]
| kqr wrote:
| Maybe you should have opened the dev tools after all --
| that's not why it breaks in modern browsers!
| zeptonaut22 wrote:
| 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.
| thakoppno wrote:
| Also highlights an aspect of CORS that is occasionally
| misunderstood. The client sends the request no matter what. The
| response headers dictate whether the response is usable.
| Mavvie wrote:
| 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)
| apenwarr wrote:
| 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.
| other_herbert wrote:
| 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
| jrockway wrote:
| 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.)
| TeMPOraL wrote:
| 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.
| thakoppno wrote:
| 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.
| matt-attack wrote:
| 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.
| bushbaba wrote:
| 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.
| easrng wrote:
| That's only if you have headers outside a default-allowed
| list set.
| im-a-baby wrote:
| 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_...
| [deleted]
| RockRobotRock wrote:
| That's hilarious, and probably explains why it takes a few
| seconds before it starts working.
| julian_sark wrote:
| 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!
| Rimintil wrote:
| 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.
| shepherdjerred wrote:
| 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
| Rimintil wrote:
| 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.
| shepherdjerred wrote:
| > 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.
| FrasiertheLion wrote:
| 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?
| apenwarr wrote:
| 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.
___________________________________________________________________
(page generated 2022-11-03 23:03 UTC)