[Make-wifi-fast] per sta queuing - the ath9k statistics
David Lang
david at lang.hm
Tue Mar 8 03:35:54 EST 2016
On Tue, 8 Mar 2016, moeller0 wrote:
>
> Hi Dave,
>
> Oh, this looks nice.
>
>> On Mar 8, 2016, at 06:01 , Dave Taht <dave.taht at gmail.com> wrote:
>>
>> I have put together some of the patches for fq_codel and per-station
>> queuing inside the mac80211 portion of the stack flying around on
>> linux-wireless, to no real visible effect as yet.
>
> Silly question: Is this really testing per-STA queuing? The client only connects to one AP, so all its upload packets can be aggregated into the same AMPDU; or rather in this case “per-station”/“per-AP” queueing degrades into a single queue, so what do you expect as visible effects here?
agreed, setup two clients, one at the highest speed available, one at the lowest
speed.
without the separate queuing, you should see large delays from the low speed
client getting it's burst of data (each station should get it's turn at
transmitting data, but the slow client will take far more airtime), while with
the separate queueing, it should get less airtime (should be equivalent airtime
with the slow client transmitting less data)
David Lang
>>
>> Mostly testing uploads at the moment, from an x86 based client. It's
>> not clear if I have the code path enabled, either, nor how to check,
>> from userspace. (?) Topology is
>>
>> x86 <-wifi-> wndr3800 <-ethernet-> pi
>>
>> Latency is still poor, throughput is down slightly. I will start
>> printk-ing tomorrow.
>>
>> I do have a few puzzling things
>>
>> A) re the ath9k statistics
>>
>> At the client (ubuntu x86, 4.5-rc7 + patches, Atheros AR5418 Wireless
>> Network Adapter [AR5008E ) I see
>>
>> http://pastebin.com/rvKJnc1y
>>
>> AMPDUs Queued HW: 0 0 0 0
>> AMPDUs Queued SW: 0 0 0 0
>> AMPDUs Completed: 1098389 7050 14967 0
>>
>> At the AP (cerowrt 3.10.50) I see
>>
>> http://pastebin.com/RTt7MNT6
>>
>> AMPDUs Queued SW: 3009455 364214 557331 0
>> AMPDUs Completed: 2961055 363353 556982 0
>> AMPDUs Retried: 115311 7833 21489 0
>>
>> In both cases the TX-Pkts-all is close to the AMPDUs completed figure.
>>
>> B) In the regular packet captures I see no tcp losses. I can see in an
>> aircap wifi retrying for every lost packet.
>
> I thought this is exactly what to expect from wifi’s attempts at “L1-retransmissions”, as long as the retransmissions ultimately are successful wifi will try to give the impression of a “perfect loss-less medium”, no?
>
>>
>> C) I do not see any ECN marks (presumably would be generated by the
>> codel implementation.)
>>
>> D) I do see things nicely "fq"'d on the captures but that might be by
>> cerowrt rather than the ieee mac
>>
>> E) tc qdisc show dev wlp2s0 shows the tc layer qdisc disabled
>>
>> qdisc noqueue 0: root refcnt 2
>>
>> which does imply that at least part of the new codepath is working,
>> but there are no stats out of that side yet...
>>
>> Ah, well, at least the patchset compiled and didn't crash the box.
>>
>> --
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> https://www.gofundme.com/savewifi
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
More information about the Make-wifi-fast
mailing list