Lets make wifi fast again!
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Pete Heist <peteheist@gmail.com>
Cc: make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] Estimating WiFi congestion using different-prio pings
Date: Sat, 13 Jan 2018 12:49:07 +0100	[thread overview]
Message-ID: <87fu7avv0s.fsf@toke.dk> (raw)
In-Reply-To: <1265AA25-398F-4FA1-9D6B-279178D52EEB@gmail.com>

Pete Heist <peteheist@gmail.com> writes:

>> On Jan 12, 2018, at 1:33 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> Some people over at Skype have implemented a technique for a client to
>> estimate congestion at the WiFi AP by pinging the AP at VO and BE
>> priority and measuring the difference in response times. Pretty neat,
>> except that it would presumably break if the AP was FQ-CoDel-enabled...
>> 
>> Paper here, including a description of the bandwidth estimation stuff
>> they apply to Skype based on the information:
>> https://dl.acm.org/citation.cfm?doid=3143361.3143390
>> 
>> -Toke
>
> Interesting, I wonder if this could be used to evaluate congestion
> within an ISP’s backhaul (but the article is behind a paywall).
>
> FreeNet Liberec currently uses SmokePing with ICMP. They have dozens
> of APs, but here’s what results look like to the AP I use:
> http://www.drhleny.cz/bufferbloat/smokeping/vysina.png
>
> They’re not all as rosy: http://www.drhleny.cz/bufferbloat/smokeping/studankaA.png
>
> When I get back to it, I want to write a SmokePing plugin for irtt to
> try in the same environment. The results may be interesting, because
> I’ve proven for myself that Ubiquiti is prioritizing ICMP, so I
> suspect that what we’re seeing in the SmokePing results is a measure
> of connectivity and maybe contention as well, but not congestion or
> user-perceived latency. And even though the ping results to my AP
> don’t vary much, I feel like web surfing latency varies considerably,
> maybe dramatically, depending on the time of day. I’d like to prove
> that.
>
> The summary of what they did at Skype makes me think it would also be
> interesting to see the _difference_ between ICMP and irtt (UDP at best
> effort)...

Any prioritisation of ICMP may just be because ICMP replies are
generated by the kernel, whereas other traffic goes all the way to the
userspace application generating it. However, it is certainly possible
that ICMP is being prioritised - some people do that in an effort to
game benchmarks...

-Toke

  reply	other threads:[~2018-01-13 11:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 12:33 Toke Høiland-Jørgensen
2018-01-12 15:01 ` Dave Taht
2018-01-13 10:53 ` Pete Heist
2018-01-13 11:49   ` Toke Høiland-Jørgensen [this message]
2018-02-03 19:54     ` Pete Heist

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fu7avv0s.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=peteheist@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox