This adds RX airtime to the airtime deficit used in the scheduler. This
is not a definite win, but I have only done very limited testing where
it has been included. Feel free to skip this patch when testing.
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/wireless/ath/ath9k/recv.c | 51 +++
hi,
I've been working on something similar in freebsd, so cool to see this
happening here!
The only thing missing atm is STBC and LDPC. My RX airtime code looks
basically like this one too; but I have TODO items for ensuring
LDPC/STBC calculations are sane.
-adrian
On 3 June 2016 at 09:51, T
On 5 June 2016 at 03:55, Toke Høiland-Jørgensen wrote:
> Adrian Chadd writes:
>
>> I've been working on something similar in freebsd, so cool to see this
>> happening here!
>
> Cool. Do you have code available somewhere?
not yet. It was mostly what you just did in ath9k anyway :)
The sample rat
[snip]
I also found one of my notes in my version of this - how can we
estimate the duration of an A-MPDU, when we only get hardware
de-encapsulated frames?
-adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailm
On 7 June 2016 at 04:12, Toke Høiland-Jørgensen wrote:
> Toke Høiland-Jørgensen writes:
>
>>> [snip]
>>>
>>> I also found one of my notes in my version of this - how can we
>>> estimate the duration of an A-MPDU, when we only get hardware
>>> de-encapsulated frames?
>>
>> Well in my case I'm side
Adrian Chadd writes:
> I've been working on something similar in freebsd, so cool to see this
> happening here!
Cool. Do you have code available somewhere?
> The only thing missing atm is STBC and LDPC. My RX airtime code looks
> basically like this one too; but I have TODO items for ensuring
>
Adrian Chadd writes:
> [snip]
>
> I also found one of my notes in my version of this - how can we
> estimate the duration of an A-MPDU, when we only get hardware
> de-encapsulated frames?
Well in my case I'm sidestepping this by getting the TX duration from a
register in the hardware. There seem
Toke Høiland-Jørgensen writes:
>> [snip]
>>
>> I also found one of my notes in my version of this - how can we
>> estimate the duration of an A-MPDU, when we only get hardware
>> de-encapsulated frames?
>
> Well in my case I'm sidestepping this by getting the TX duration from
> a register in the
Adrian Chadd writes:
> Right. In the case of RX'ing an A-MPDU, we only get told about the
> A-MPDU boundaries (isaggr/lastaggr or something in the RX descriptor)
> but nothing telling us how long the original RX'ed PPDU is.
>
> So if we get say 16 frames and we are missing the middle one, we can
