All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "Toke Høiland-Jørgensen" <toke@toke.dk>,
	make-wifi-fast@lists.bufferbloat.net,
	linux-wireless@vger.kernel.org
Subject: Re: [Make-wifi-fast] [RFC] mac80211: Add airtime fairness accounting
Date: Fri, 6 Oct 2017 15:40:14 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.1710061536220.4994@nftneq.ynat.uz> (raw)
In-Reply-To: <1507310319.19300.28.camel@sipsolutions.net>

On Fri, 6 Oct 2017, Johannes Berg wrote:

>> Well, calculating the duration from the rate and size is what ath9k
>> is currently doing, and that has all the information available to do
>> so (I did verify that the airtime was almost identical on the TX and
>> RX side for the same traffic).
>
> It's still iffy - with aggregation you might have a better idea of the
> total airtime, but not really see - in the higher layers - all the
> padding that comes between A-MPDUs etc. I think many drivers could do
> better by exposing the total airtime from the device/firmware, whereas
> exposing _all_ the little details that you need to calculate it post-
> facto will be really difficult, and make the calculation really hard.

perfect is the enemy of good enough :-)

I don't think the intent is to try and be a perfect accounting, if the total 
calculated time ends up being > 100%, it doesn't really matter, what matters is 
the relative behavior of the stations, and while the naive calculation fails to 
properly reward a station that's being more efficient, it is still good enough 
to punish stations using lower bandwidth modes (which is a far larger cause of 
problems)

while it's ideal to have the driver provide the airtime, falling back to a naive 
(but relativly cheap) calculation if a time isn't provided.

David Lang

  reply	other threads:[~2017-10-06 22:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-06 11:52 [RFC] mac80211: Add airtime fairness accounting Toke Høiland-Jørgensen
2017-10-06 14:07 ` Johannes Berg
2017-10-06 14:29   ` Toke Høiland-Jørgensen
2017-10-06 17:18     ` Johannes Berg
2017-10-06 22:40       ` David Lang [this message]
2017-10-07 11:22       ` Toke Høiland-Jørgensen
2017-10-09  7:15         ` Johannes Berg
2017-10-09  7:50           ` [Make-wifi-fast] " David Lang
2017-10-09  9:42           ` Toke Høiland-Jørgensen
2017-10-09 11:40             ` Johannes Berg
2017-10-09 12:38               ` Toke Høiland-Jørgensen
2017-10-09 18:50                 ` Johannes Berg
2017-10-09 20:25                   ` Toke Høiland-Jørgensen
2017-10-11  8:55                     ` Johannes Berg
2017-10-11 13:50                       ` Toke Høiland-Jørgensen
     [not found]   ` <CAJq5cE0YewMkTcuWM_tRjJnP2vLa_cvoQEsgz8JhGLHxOOSRsw@mail.gmail.com>
2017-10-06 17:12     ` [Make-wifi-fast] " Johannes Berg

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

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

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1710061536220.4994@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=toke@toke.dk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.