Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Aaron Wood <woody77@gmail.com>,
	"cerowrt-devel\@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] gaming routers...
Date: Thu, 05 Jan 2017 12:04:32 +0100	[thread overview]
Message-ID: <8760ltzs1r.fsf@toke.dk> (raw)
In-Reply-To: <0336DE7E-A69C-4F1B-ADB7-0AE81DD8A657@gmail.com> (Jonathan Morton's message of "Wed, 4 Jan 2017 23:57:08 +0200")

Jonathan Morton <chromatix99@gmail.com> writes:

>> On 4 Jan, 2017, at 23:45, Aaron Wood <woody77@gmail.com> wrote:
>> 
>> "but it has revealed that the WRT32X is designed to automatically detect
>> computers using the Killer-line of network adapters, indicating it's probably
>> a gaming-focused PC from a company like Alienware, MSI, or Razer that requires
>> priority access to the home's internet. It does the same thing for an Xbox as
>> well, if console gaming is more your thing.”
>
> In other words, they’re aware of the (user level) problem, but they still don’t
> really “get it” at a technical solution level. And they call it “secret sauce”
> and hide the details, because they don’t want competitors to copy them.
>
>> Or it's looking at the mac ids of the devices, and queuing them separately,
>> with higher priority, but throttled to a percentage of overall bandwidth. Much
>> like the Cisco recommendations for voip traffic using EF.
>
> It’s looking at MACs all right, but not the way you suggest.  It’s just classifying certain vendor IDs as “voice” by default, and leaving the rest at “best effort”.
>
> It would however be very interesting to see whether we can measure the
> differences between this approach and the ath9k work - purely to illuminate
> whether the proprietary or open-source approaches are more effective in
> practice.

We did get some results comparing using the VO queue with the FQ-CoDel
MAC layer changes for the WiFi bufferbloat work. We used synthetic MOS
values as the metric for this (which I'm not sure if anyone actually
puts any trust in), but we did see that fixing the queueing gave us
*better* performance than we got using the VO queue before the fixes.

Post fixes, the VO queue still gives slightly better performance than
BE, but the difference is only slightly above the noise level.

-Toke

      parent reply	other threads:[~2017-01-05 11:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-04 21:37 Dave Taht
2017-01-04 21:45 ` Aaron Wood
2017-01-04 21:57   ` Jonathan Morton
2017-01-05  0:49     ` Aaron Wood
2017-01-05 11:04     ` Toke Høiland-Jørgensen [this message]

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/cerowrt-devel.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=8760ltzs1r.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=woody77@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