> If the firmware/NIC is putting it on air at a particular encoding,
> then I think the stack should report it exactly as it is on air if
> possible.
It already does. We're only debating what bitrate to report :P
Anyway, I don't have the latest patch anymore - somebody please resend
it.
On 10/04/2016 02:32 AM, Johannes Berg wrote:
Sorry - needed some time to think through this thread again.
I think it is a moot point as far as this change goes: Regardless of
whether the NIC should or not, it _does_. So, mis-reporting it up
the stack only hides the issue and does not even
Sorry - needed some time to think through this thread again.
> I think it is a moot point as far as this change goes: Regardless of
> whether the NIC should or not, it _does_. So, mis-reporting it up
> the stack only hides the issue and does not even give the user a clue
> that on-the-air
On 09/19/2016 02:00 AM, Johannes Berg wrote:
Actually, can you apply the v2 (cfg80211: add bitrate for 20MHz MCS
9) of this? Systems guys confirmed they use MCS 9 @ 20MHz when LDPC
is enabled. Also confirmed bitrate should be ok.
I don't really understand that. How can the bitrate be "OK"
On 19-9-2016 11:00, Johannes Berg wrote:
>
>> Actually, can you apply the v2 (cfg80211: add bitrate for 20MHz MCS
>> 9) of this? Systems guys confirmed they use MCS 9 @ 20MHz when LDPC
>> is enabled. Also confirmed bitrate should be ok.
>
> I don't really understand that. How can the bitrate
> Actually, can you apply the v2 (cfg80211: add bitrate for 20MHz MCS
> 9) of this? Systems guys confirmed they use MCS 9 @ 20MHz when LDPC
> is enabled. Also confirmed bitrate should be ok.
I don't really understand that. How can the bitrate be "OK" when the
spec explicitly says it cannot be
On Tue, 2016-09-13 at 20:02 +0200, Johannes Berg wrote:
> > Yeah so apparently the overhead involved in 256-QAM 5/6 (MCS 9)
> > results in lower effective bitrate than just using MCS 8 (unless
> > you're using 3 spatial streams).
>
> Ah. I took a - very brief - look at why this one is invalid and
> Yeah so apparently the overhead involved in 256-QAM 5/6 (MCS 9)
> results in lower effective bitrate than just using MCS 8 (unless
> you're using 3 spatial streams).
Ah. I took a - very brief - look at why this one is invalid and
couldn't figure it out.
> Sounds like a rate control or
On Mon, 2016-09-12 at 08:43 +0200, Johannes Berg wrote:
> On Wed, 2016-09-07 at 18:20 +, Pedersen, Thomas wrote:
> >
> > On 09/06/2016 12:07 PM, Ben Greear wrote:
> > >
> > >
> > > On 09/06/2016 12:00 PM, Thomas Pedersen wrote:
> > > >
> > > >
> > > > Some drivers (ath10k) report MCS 9 @
On 09/11/2016 11:43 PM, Johannes Berg wrote:
On Wed, 2016-09-07 at 18:20 +, Pedersen, Thomas wrote:
On 09/06/2016 12:07 PM, Ben Greear wrote:
On 09/06/2016 12:00 PM, Thomas Pedersen wrote:
Some drivers (ath10k) report MCS 9 @ 20MHz, which
technically isn't allowed. To get more
On Wed, 2016-09-07 at 18:20 +, Pedersen, Thomas wrote:
> On 09/06/2016 12:07 PM, Ben Greear wrote:
> >
> > On 09/06/2016 12:00 PM, Thomas Pedersen wrote:
> > >
> > > Some drivers (ath10k) report MCS 9 @ 20MHz, which
> > > technically isn't allowed. To get more meaningful value
> > > than 0
On 09/06/2016 12:07 PM, Ben Greear wrote:
> On 09/06/2016 12:00 PM, Thomas Pedersen wrote:
>> Some drivers (ath10k) report MCS 9 @ 20MHz, which
>> technically isn't allowed. To get more meaningful value
>> than 0 out of this however, just cap the bitrate for 20MHz
>> to MCS 8.
>
> If it is
On 09/06/2016 12:00 PM, Thomas Pedersen wrote:
Some drivers (ath10k) report MCS 9 @ 20MHz, which
technically isn't allowed. To get more meaningful value
than 0 out of this however, just cap the bitrate for 20MHz
to MCS 8.
If it is actually reporting MCS9, why lie about it? Report it up
the
Some drivers (ath10k) report MCS 9 @ 20MHz, which
technically isn't allowed. To get more meaningful value
than 0 out of this however, just cap the bitrate for 20MHz
to MCS 8.
Signed-off-by: Thomas Pedersen
---
net/wireless/util.c | 4 +++-
1 file changed, 3 insertions(+),
14 matches
Mail list logo