Unicast packets stop being transmitted to a particular station, under load, when WPA2 is enabled

[Adrian Chadd]

Hi,

When I get the firmware source from QCA and Ben, I'll dig into the IV
shit in more detail.

As for the 11e and txop stuff - absolutely. I've been wanting to add
some txop-time aware clue to the freebsd packet scheduler and rate
control code. aggregation and 11e work great, but you can't just
simply keep packing max-length aggregates in when your bulk-download
station is on MCS0. That's just plain dumb. Linux and FreeBSD don't
take that into account.

We can use AMPDU and AMSDU to better interface with the timing and
transmission constraints of doing things over the open air. We're just
not.

Now that I'm not working at QCA I do plan on adding that stuff to
FreeBSD's atheros driver and hopefully work with the ath9k team to get
that into the rate control code there too. As for the firmware, I'm
happy to also add that to firmware - but not until the firmware is
open sourced.


-a


On 16 May 2014 13:01, Dave Taht <dave.taht at gmail.com> wrote:
> On Wed, May 14, 2014 at 11:12 PM, Avery Pennarun <apenwarr at gmail.com> wrote:
>> On Wed, May 14, 2014 at 3:26 PM, Dave Taht <dave.taht at gmail.com> wrote:
>>> On Wed, May 14, 2014 at 12:07 PM, Avery Pennarun <apenwarr at gmail.com> wrote:
>>>> but meanwhile, I think I'm in a
>>>> big hurry so I probably want to just rip out all support for mapping
>>>> diffserv to QoS on the ath10k transmit side.  Does anyone have any
>>>> suggestions on where to look for my hack-and-slash operation?
>>>
>>> Tis easy to hack and slash it out of cfg80211_classify8021d in
>>> net/wireless/util.c
>>>
>>> Recently someone added a direct mapping from vlan priorities to wifi
>>> queues here - which is stupid, as the VO queue does not behave
>>> anything like the equivalent vlan priority queue does. I'd like to see
>>> that removed or mapped properly, also.
>>
>> Yup, replaced this function with 'return 0' and my problems are gone.
>> (Well okay, this problem is gone, and you're probably not interested
>> in my personal problems. :))
>
> The wifi alliance won't certify something that doesn't do 802.11e
> "correctly". Not that I care.
>
> A side effect of ripping this out is that some prioritized traffic, notably
> multicast & dhcp (marked with CS6) now gets head of line blocked
> in the BE queue until it can be delivered.
>
> A possible problem with this "fix" is that the underlying hw queues are
> still having some sort of problem in the driver, and doing a
> multicast flood (say, mdns-scan or uftp) while doing other traffic might
> trigger it again.
>
> The linux 4 exposed queue problem should long ago have been
> bumped to directly include a 5th queue observable and manageable
> for multicast events.
>
>> Obviously just completely disabling QoS multiple queues is not the
>> right long term fix, but as Dave pointed out, it wasn't clear the code
>> there was exactly what we want anyway, so I won't feel too guilty
>> about it.
>
> Well, after spending 4+ months trying to get to the bottom of this
> myself...
>
> ... I just also ripped 802.11e out of cerowrt in this same file for more
> testing.
>
> 802.11e in a packet aggregated world is both conceptually and
> operationally broken, when the real resource limit is txops,
> and cramming as many packets (sanely) into a txop is more the
> right thing.
>
> I've been showing that 4 hardware queues induces more latency
> than 1 for a long time now, I am inspired (before I commit to
> ripping out 802.11e entirely) to produce some graphs showing how
> horrible flooding those queues is, compared to having one queue.
>
> Now, getting away from doing QoS at this level opens up an opportunity
> in that there are still 4 independently programmable tx queues (from
> hostapd) and they could be used instead as a poor mans "mu-mimo" to
> drive multiple stations more sanely.
>
>> Meanwhile, hopefully someone with deeper knowledge than me
>> can figure out what's with the IVs.
>
> +10
>
>> Thanks!
>>
>> Avery
>
>
>
> --
> Dave Täht
>
> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k