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
