* Re: [Cerowrt-devel] [Bloat] blip: a tool for seeing internet latency with javascript
@ 2013-04-28 18:52 dpreed
2013-04-29 0:37 ` [Cerowrt-devel] [Codel] " Jim Gettys
0 siblings, 1 reply; 6+ messages in thread
From: dpreed @ 2013-04-28 18:52 UTC (permalink / raw)
To: Rich Brown; +Cc: codel, cerowrt-devel, bloat
[-- Attachment #1: Type: text/plain, Size: 3400 bytes --]
Actually, using HTTP 1.1 GET that generates a single packet in each direction for a ping is quite reasonable. In fact, it is "better" for measuring actual path latencies, since ICMP pings *could* be discriminated against in a router along the way (in the "old days" people in the routing community suggested that ICMP should be diverted off of the "fast path" to avoid degrading the user experience).
I've been using this technique to measure bufferbloat-induced delays on Phones and Android phones for quite a while. I have a couple of servers that use nginx "status" handlers to generate a short GET response without touching files as my "targets".
Since it depends on HTTP 1.1's re-use of the underlying TCP connection for successive GET commands, it's a bit fragile.
Javascript can be made to do a lot of performance testing - you can access both TCP and DNS protocols from the browser, so if you play cards right, you can cause single TCP exchanges and single UDP exchanges to happen with cooperative servers (web servers using HTTP 1.1 and DNS resolvers using uncacheable UDP name lookups).
On Sunday, April 28, 2013 10:56am, "Rich Brown" <richb.hanover@gmail.com> said:
> This is indeed a cool hack. I was astonished for a moment, because it was a
> bedrock belief that you can't send pings from Javascript. And in fact, that is
> still true.
>
> Apenwarr's code sends short HTTP queries of the format shown below to each of two
> hosts:
>
> http://gstatic.com/generate_204
> http://apenwarr.ca/blip/
>
> The Blip tool shows ~60-70ms for the gstatic host, and ~130 msec for the latter.
> Ping times are ~52 msec and 125msec, respectively. These times seem to track
> response times by my eye (no serious analysis) to load both on my primary
> (bloated) router and CeroWrt.
>
> Still a cool hack.
>
> Rich
>
> -------------------------
> HTTP Request & Response for typical blip "ping"
>
> OPTIONS /generate_204 HTTP/1.1
> Host: gstatic.com
> Connection: keep-alive
> Access-Control-Request-Method: GET
> Origin: http://gfblip.appspot.com
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31
> (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
> Access-Control-Request-Headers: accept, origin, x-requested-with
> Accept: */*
> Referer: http://gfblip.appspot.com/
> Accept-Encoding: gzip,deflate,sdch
> Accept-Language: en-US,en;q=0.8
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
>
> HTTP/1.1 204 No Content
> Content-Length: 0
> Content-Type: text/html; charset=UTF-8
> Date: Sun, 28 Apr 2013 12:37:17 GMT
> Server: GFE/2.0
>
>
> On Apr 26, 2013, at 7:04 PM, Dave Taht <dave.taht@gmail.com> wrote:
>
> > Apenwarr has developed a really unique tool for seeing latency and
> > packet loss via javascript. I had no idea this was possible:
> >
> > http://apenwarr.ca/log/?m=201304#26
> >
> >
> >
> > --
> > Dave Täht
> >
> > Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
[-- Attachment #2: Type: text/html, Size: 5093 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] [Codel] [Bloat] blip: a tool for seeing internet latency with javascript
2013-04-28 18:52 [Cerowrt-devel] [Bloat] blip: a tool for seeing internet latency with javascript dpreed
@ 2013-04-29 0:37 ` Jim Gettys
2013-05-01 2:39 ` Rich Brown
0 siblings, 1 reply; 6+ messages in thread
From: Jim Gettys @ 2013-04-29 0:37 UTC (permalink / raw)
To: David P Reed; +Cc: codel, cerowrt-devel, bloat
[-- Attachment #1: Type: text/plain, Size: 4382 bytes --]
On Sun, Apr 28, 2013 at 2:52 PM, <dpreed@reed.com> wrote:
> Actually, using HTTP 1.1 GET that generates a single packet in each
> direction for a ping is quite reasonable. In fact, it is "better" for
> measuring actual path latencies, since ICMP pings *could* be discriminated
> against in a router along the way (in the "old days" people in the routing
> community suggested that ICMP should be diverted off of the "fast path" to
> avoid degrading the user experience).
>
Yes, using HTTP is good in this respect. I worked with the author of
httping to get support for persistent connections 18 months or so ago.
How to deal with proxies is one question, though one should mark the
response uncachable. (unless the intent is to just test the path as far as
the proxy.
In practice, I've never seen signs of ICMP being put off the fast path in
my testing; this doesn't mean it doesn't happen.
>
>
> I've been using this technique to measure bufferbloat-induced delays on
> Phones and Android phones for quite a while. I have a couple of servers
> that use nginx "status" handlers to generate a short GET response without
> touching files as my "targets".
>
>
>
> Since it depends on HTTP 1.1's re-use of the underlying TCP connection for
> successive GET commands, it's a bit fragile.
>
I don't think this should be particularly fragile, unless you know
something I don't.
Jim
>
>
> Javascript can be made to do a lot of performance testing - you can access
> both TCP and DNS protocols from the browser, so if you play cards right,
> you can cause single TCP exchanges and single UDP exchanges to happen with
> cooperative servers (web servers using HTTP 1.1 and DNS resolvers using
> uncacheable UDP name lookups).
>
>
>
>
>
>
>
>
>
> On Sunday, April 28, 2013 10:56am, "Rich Brown" <richb.hanover@gmail.com>
> said:
>
> > This is indeed a cool hack. I was astonished for a moment, because it
> was a
> > bedrock belief that you can't send pings from Javascript. And in fact,
> that is
> > still true.
> >
> > Apenwarr's code sends short HTTP queries of the format shown below to
> each of two
> > hosts:
> >
> > http://gstatic.com/generate_204
> > http://apenwarr.ca/blip/
> >
> > The Blip tool shows ~60-70ms for the gstatic host, and ~130 msec for the
> latter.
> > Ping times are ~52 msec and 125msec, respectively. These times seem to
> track
> > response times by my eye (no serious analysis) to load both on my primary
> > (bloated) router and CeroWrt.
> >
> > Still a cool hack.
> >
> > Rich
> >
> > -------------------------
> > HTTP Request & Response for typical blip "ping"
> >
> > OPTIONS /generate_204 HTTP/1.1
> > Host: gstatic.com
> > Connection: keep-alive
> > Access-Control-Request-Method: GET
> > Origin: http://gfblip.appspot.com
> > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3)
> AppleWebKit/537.31
> > (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
> > Access-Control-Request-Headers: accept, origin, x-requested-with
> > Accept: */*
> > Referer: http://gfblip.appspot.com/
> > Accept-Encoding: gzip,deflate,sdch
> > Accept-Language: en-US,en;q=0.8
> > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
> >
> > HTTP/1.1 204 No Content
> > Content-Length: 0
> > Content-Type: text/html; charset=UTF-8
> > Date: Sun, 28 Apr 2013 12:37:17 GMT
> > Server: GFE/2.0
> >
> >
> > On Apr 26, 2013, at 7:04 PM, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > > Apenwarr has developed a really unique tool for seeing latency and
> > > packet loss via javascript. I had no idea this was possible:
> > >
> > > http://apenwarr.ca/log/?m=201304#26
> > >
> > >
> > >
> > > --
> > > Dave Täht
> > >
> > > Fixing bufferbloat with cerowrt:
> > http://www.teklibre.com/cerowrt/subscribe.html
> > > _______________________________________________
> > > Bloat mailing list
> > > Bloat@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/bloat
> >
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
>
>
>
>
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>
>
[-- Attachment #2: Type: text/html, Size: 7905 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] [Codel] [Bloat] blip: a tool for seeing internet latency with javascript
2013-04-29 0:37 ` [Cerowrt-devel] [Codel] " Jim Gettys
@ 2013-05-01 2:39 ` Rich Brown
0 siblings, 0 replies; 6+ messages in thread
From: Rich Brown @ 2013-05-01 2:39 UTC (permalink / raw)
Cc: codel, cerowrt-devel, bloat
Folks,
I noted a paradoxical effect using the blip tool and CeroWrt. I wrote it up and included screen shots in: http://www.bufferbloat.net/issues/430 Here's the text of the note.
Any thoughts?
Rich Brown
Hanover, NH
-------------
CeroWrt 3.8.8-4 doesn't have as big an effect on the apenwarr.ca blip javascript program as I expected. This isn't really a bug report, but I am using this message as an easy way to include screen shots:
Experimental setup #1
- Macbook connected to demo3.intermapper.com, where I executed iperf -s
- Macbook running iperf locally to that server (iperf -c demo3.intermapper.com -i 1 -t 30)
- Macbook running http://apenwarr.ca/log/ connected to primary (bloated) router running DD-WRT from a couple years ago
Result: blip chart times increase during iperf as expected. The response goes from ~120/200 (green/blue, respectively) to ~500msec for both. (see "Test #1 using primary router wireless" image)
Experimental setup #2:
- MacBook is connected to CeroWrt 3.8.8-4 which is connected to LAN side of DD-WRT which then goes to the Internet.
- Run "iperf -c" as before
Result: the blip chart times seem to exhibit approximately the same behavior, with the same high response times during the iperf transfer. (See "Test #2 using CeroWrt5 wireless" image below)
Observation:
Both charts seem similar - this is counter to my intuition, and counter to my experience using a simple sequence of one-second pings which don't vary much from the baseline in the experimental setup #2.
Hypotheses:
- blip is a cool hack, but a bad test, and doesn't accurately represent the responsiveness of the network.
- fq_codel as implemented in CeroWrt3.8.8-4 does not handle these "TCP Pings" well/as expected.
- ???
Any thoughts?
Rich Brown
Hanover, NH
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] [Bloat] blip: a tool for seeing internet latency with javascript
2013-04-26 23:04 [Cerowrt-devel] " Dave Taht
2013-04-28 14:56 ` [Cerowrt-devel] [Bloat] " Rich Brown
@ 2013-04-28 23:53 ` Fred Baker (fred)
1 sibling, 0 replies; 6+ messages in thread
From: Fred Baker (fred) @ 2013-04-28 23:53 UTC (permalink / raw)
To: Dave Taht
Cc: <codel@lists.bufferbloat.net>,
<cerowrt-devel@lists.bufferbloat.net>,
bloat
[-- Attachment #1.1: Type: text/plain, Size: 1206 bytes --]
On Apr 26, 2013, at 4:04 PM, Dave Taht <dave.taht@gmail.com<mailto:dave.taht@gmail.com>> wrote:
Apenwarr has developed a really unique tool for seeing latency and
packet loss via javascript. I had no idea this was possible:
http://apenwarr.ca/log/?m=201304#26
Indeed, very cool.
For those on PCs running Windows, there is also pingplotter (http://www.pingplotter.com). It sends what amounts to a trace route once a second - a burst of packets back to back with TTLs varying from 1 to the number of hops between you and whatever you're targeting. It tracks not only the end to end behavior but the behavior along the way. If you like, you can leave it running and have it send you an email with a .png of an event that is worse than some threshold. I've attached a graphic it showed me once about a particular path I cared about that happened to have a geosynchronous satcom delay in it.
BTW, the data here is most definitely dated. A ping I just did gave me
--- 212.88.97.49 ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 364.163/372.373/398.910/5.712 ms
[cid:717DCED7-6136-433E-A8A4-9FF5795D689A@cisco.com]
[-- Attachment #1.2: Type: text/html, Size: 1924 bytes --]
[-- Attachment #2: sb-to-ug.distrouter.mtn.co.ug.jpg --]
[-- Type: image/jpeg, Size: 176091 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] [Bloat] blip: a tool for seeing internet latency with javascript
2013-04-28 14:56 ` [Cerowrt-devel] [Bloat] " Rich Brown
@ 2013-04-28 18:02 ` Maciej Soltysiak
0 siblings, 0 replies; 6+ messages in thread
From: Maciej Soltysiak @ 2013-04-28 18:02 UTC (permalink / raw)
To: Rich Brown; +Cc: codel, cerowrt-devel, bloat
[-- Attachment #1: Type: text/plain, Size: 2511 bytes --]
At home with latest cero, I'm getting results similar to Rich.
I'm wondering how this will look tomorrow when I run it at company network,
which is incredibly complex WAN path, proxied, with things like riverbed
and checkpoint along the way.
Maciej
On Sun, Apr 28, 2013 at 4:56 PM, Rich Brown <richb.hanover@gmail.com> wrote:
> This is indeed a cool hack. I was astonished for a moment, because it was
> a bedrock belief that you can't send pings from Javascript. And in fact,
> that is still true.
>
> Apenwarr's code sends short HTTP queries of the format shown below to each
> of two hosts:
>
> http://gstatic.com/generate_204
> http://apenwarr.ca/blip/
>
> The Blip tool shows ~60-70ms for the gstatic host, and ~130 msec for the
> latter. Ping times are ~52 msec and 125msec, respectively. These times seem
> to track response times by my eye (no serious analysis) to load both on my
> primary (bloated) router and CeroWrt.
>
> Still a cool hack.
>
> Rich
>
> -------------------------
> HTTP Request & Response for typical blip "ping"
>
> OPTIONS /generate_204 HTTP/1.1
> Host: gstatic.com
> Connection: keep-alive
> Access-Control-Request-Method: GET
> Origin: http://gfblip.appspot.com
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3)
> AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
> Access-Control-Request-Headers: accept, origin, x-requested-with
> Accept: */*
> Referer: http://gfblip.appspot.com/
> Accept-Encoding: gzip,deflate,sdch
> Accept-Language: en-US,en;q=0.8
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
>
> HTTP/1.1 204 No Content
> Content-Length: 0
> Content-Type: text/html; charset=UTF-8
> Date: Sun, 28 Apr 2013 12:37:17 GMT
> Server: GFE/2.0
>
>
> On Apr 26, 2013, at 7:04 PM, Dave Taht <dave.taht@gmail.com> wrote:
>
> > Apenwarr has developed a really unique tool for seeing latency and
> > packet loss via javascript. I had no idea this was possible:
> >
> > http://apenwarr.ca/log/?m=201304#26
> >
> >
> >
> > --
> > Dave Täht
> >
> > Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
[-- Attachment #2: Type: text/html, Size: 3817 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] [Bloat] blip: a tool for seeing internet latency with javascript
2013-04-26 23:04 [Cerowrt-devel] " Dave Taht
@ 2013-04-28 14:56 ` Rich Brown
2013-04-28 18:02 ` Maciej Soltysiak
2013-04-28 23:53 ` Fred Baker (fred)
1 sibling, 1 reply; 6+ messages in thread
From: Rich Brown @ 2013-04-28 14:56 UTC (permalink / raw)
To: Dave Taht; +Cc: codel, cerowrt-devel, bloat
This is indeed a cool hack. I was astonished for a moment, because it was a bedrock belief that you can't send pings from Javascript. And in fact, that is still true.
Apenwarr's code sends short HTTP queries of the format shown below to each of two hosts:
http://gstatic.com/generate_204
http://apenwarr.ca/blip/
The Blip tool shows ~60-70ms for the gstatic host, and ~130 msec for the latter. Ping times are ~52 msec and 125msec, respectively. These times seem to track response times by my eye (no serious analysis) to load both on my primary (bloated) router and CeroWrt.
Still a cool hack.
Rich
-------------------------
HTTP Request & Response for typical blip "ping"
OPTIONS /generate_204 HTTP/1.1
Host: gstatic.com
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://gfblip.appspot.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
Access-Control-Request-Headers: accept, origin, x-requested-with
Accept: */*
Referer: http://gfblip.appspot.com/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
HTTP/1.1 204 No Content
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Sun, 28 Apr 2013 12:37:17 GMT
Server: GFE/2.0
On Apr 26, 2013, at 7:04 PM, Dave Taht <dave.taht@gmail.com> wrote:
> Apenwarr has developed a really unique tool for seeing latency and
> packet loss via javascript. I had no idea this was possible:
>
> http://apenwarr.ca/log/?m=201304#26
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-05-01 2:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-28 18:52 [Cerowrt-devel] [Bloat] blip: a tool for seeing internet latency with javascript dpreed
2013-04-29 0:37 ` [Cerowrt-devel] [Codel] " Jim Gettys
2013-05-01 2:39 ` Rich Brown
-- strict thread matches above, loose matches on Subject: below --
2013-04-26 23:04 [Cerowrt-devel] " Dave Taht
2013-04-28 14:56 ` [Cerowrt-devel] [Bloat] " Rich Brown
2013-04-28 18:02 ` Maciej Soltysiak
2013-04-28 23:53 ` Fred Baker (fred)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox