* [Make-wifi-fast] per sta queuing - the ath9k statistics @ 2016-03-08 5:01 Dave Taht 2016-03-08 8:25 ` moeller0 0 siblings, 1 reply; 3+ messages in thread From: Dave Taht @ 2016-03-08 5:01 UTC (permalink / raw) To: Felix Fietkau, make-wifi-fast; +Cc: linux-wireless 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. 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. 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Make-wifi-fast] per sta queuing - the ath9k statistics 2016-03-08 5:01 [Make-wifi-fast] per sta queuing - the ath9k statistics Dave Taht @ 2016-03-08 8:25 ` moeller0 2016-03-08 8:35 ` David Lang 0 siblings, 1 reply; 3+ messages in thread From: moeller0 @ 2016-03-08 8:25 UTC (permalink / raw) To: Dave Täht; +Cc: Felix Fietkau, make-wifi-fast Hi Dave, Oh, this looks nice. > On Mar 8, 2016, at 06:01 , Dave Taht <dave.taht@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? > > 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@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Make-wifi-fast] per sta queuing - the ath9k statistics 2016-03-08 8:25 ` moeller0 @ 2016-03-08 8:35 ` David Lang 0 siblings, 0 replies; 3+ messages in thread From: David Lang @ 2016-03-08 8:35 UTC (permalink / raw) To: moeller0; +Cc: Dave Täht, make-wifi-fast [-- Attachment #1: Type: TEXT/PLAIN, Size: 3573 bytes --] On Tue, 8 Mar 2016, moeller0 wrote: > > Hi Dave, > > Oh, this looks nice. > >> On Mar 8, 2016, at 06:01 , Dave Taht <dave.taht@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@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/make-wifi-fast > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-03-08 8:36 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-08 5:01 [Make-wifi-fast] per sta queuing - the ath9k statistics Dave Taht 2016-03-08 8:25 ` moeller0 2016-03-08 8:35 ` David Lang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox