* Problem with 9984 in routed mode with 512b frames. @ 2019-05-15 1:52 Ben Greear 2019-05-15 4:26 ` Sebastian Gottschall 0 siblings, 1 reply; 21+ messages in thread From: Ben Greear @ 2019-05-15 1:52 UTC (permalink / raw) To: ath10k Hello, I found a strange issue and curious if someone has seen similar. I made an AP where the AP interface acts as a routed interface. I generate traffic through another interface in the router. When sending 300Mbps of 512 byte UDP payloads, in the downstream direction, and with the station being a 1x1 /AC device, then the AP NIC appears to mostly lock up within about 1 minute. I still see beacons, but no data frames. In some cases, I reproduced with very slow speed traffic as well. I tried using a mostly un-modified firmware (ie, similar to upstream QCA), as well as my hacked upon firmware, and all act similarly. I'm using the 4.20 kernel, but at least for now, it does not appear to be a kernel issue. If I use larger MTU sized frames, or have a 2x2 station instead of 1x1 then it is much harder to reproduce (and maybe cannot be reproduced). Also, when generating traffic directly on the AP device instead of using the routed interface as a traffic source, it is harder to reproduce. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-15 1:52 Problem with 9984 in routed mode with 512b frames Ben Greear @ 2019-05-15 4:26 ` Sebastian Gottschall 2019-05-15 12:20 ` Ben Greear 0 siblings, 1 reply; 21+ messages in thread From: Sebastian Gottschall @ 2019-05-15 4:26 UTC (permalink / raw) To: Ben Greear, ath10k can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) Sebastian Am 15.05.2019 um 03:52 schrieb Ben Greear: > Hello, > > I found a strange issue and curious if someone has seen similar. > > I made an AP where the AP interface acts as a routed interface. I > generate > traffic through another interface in the router. When sending 300Mbps > of 512 byte > UDP payloads, in the downstream direction, and with the station being > a 1x1 /AC device, > then the AP NIC appears to mostly lock up within about 1 minute. I > still see beacons, but no > data frames. In some cases, I reproduced with very slow speed traffic > as well. > > I tried using a mostly un-modified firmware (ie, similar to upstream > QCA), as well as my > hacked upon firmware, and all act similarly. I'm using the 4.20 > kernel, but at least for now, > it does not appear to be a kernel issue. > > If I use larger MTU sized frames, or have a 2x2 station instead of 1x1 > then it is much harder > to reproduce (and maybe cannot be reproduced). Also, when generating > traffic directly on > the AP device instead of using the routed interface as a traffic > source, it is harder to > reproduce. > > Thanks, > Ben > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-15 4:26 ` Sebastian Gottschall @ 2019-05-15 12:20 ` Ben Greear 2019-05-15 12:26 ` Sebastian Gottschall 0 siblings, 1 reply; 21+ messages in thread From: Ben Greear @ 2019-05-15 12:20 UTC (permalink / raw) To: Sebastian Gottschall, ath10k On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: > can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) I am using our own traffic generator, but I imagine iperf3 should work fine too. I am testing on x86-64 and so forth. Maybe you can test with UDP small-packet load on your platform in routed mode (ie, external iperf generator through your AP) and see if you see issues? From debugging yesterday, I see a lot of tx-hang notifications in the firmware, and I also believe I saw it trying to transmit with a 0 rate-indx, which is 11Mbps CCK, which is invalid for 5Ghz. I'll be debugging that more today. I don't know if stock firmware fails for the same reasons, but the symptom looked the same. Thanks, Ben > > Sebastian > > Am 15.05.2019 um 03:52 schrieb Ben Greear: >> Hello, >> >> I found a strange issue and curious if someone has seen similar. >> >> I made an AP where the AP interface acts as a routed interface. I generate >> traffic through another interface in the router. When sending 300Mbps of 512 byte >> UDP payloads, in the downstream direction, and with the station being a 1x1 /AC device, >> then the AP NIC appears to mostly lock up within about 1 minute. I still see beacons, but no >> data frames. In some cases, I reproduced with very slow speed traffic as well. >> >> I tried using a mostly un-modified firmware (ie, similar to upstream QCA), as well as my >> hacked upon firmware, and all act similarly. I'm using the 4.20 kernel, but at least for now, >> it does not appear to be a kernel issue. >> >> If I use larger MTU sized frames, or have a 2x2 station instead of 1x1 then it is much harder >> to reproduce (and maybe cannot be reproduced). Also, when generating traffic directly on >> the AP device instead of using the routed interface as a traffic source, it is harder to >> reproduce. >> >> Thanks, >> Ben >> > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-15 12:20 ` Ben Greear @ 2019-05-15 12:26 ` Sebastian Gottschall 2019-05-15 13:00 ` Ben Greear 0 siblings, 1 reply; 21+ messages in thread From: Sebastian Gottschall @ 2019-05-15 12:26 UTC (permalink / raw) To: Ben Greear, ath10k Am 15.05.2019 um 14:20 schrieb Ben Greear: > On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: >> can you send me a detailed instruction for testing this on my >> devices? so which commands have been used for generating the traffic >> etc. (iperf3?) > > I am using our own traffic generator, but I imagine iperf3 should work > fine too. > > I am testing on x86-64 and so forth. Maybe you can test with UDP > small-packet load on your platform > in routed mode (ie, external iperf generator through your AP) and see > if you see issues? thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario is identical which raised up your issue, it would be find if we have identical software for testing including the same options > > From debugging yesterday, I see a lot of tx-hang notifications in the > firmware, and > I also believe I saw it trying to transmit with a 0 rate-indx, which > is 11Mbps CCK, > which is invalid for 5Ghz. I'll be debugging that more today. I > don't know if stock > firmware fails for the same reasons, but the symptom looked the same. could be a buffer overflow/locking due a udp flooding. so a missing check to drop packets which are out of limit or a too restrictive buffer management. like static frame buffers of max mtu size, but its just used partially by frame due the small size of the udp packets. you may know it better since you have much better knowledge about the firmware internals. > > Thanks, > Ben > >> >> Sebastian >> >> Am 15.05.2019 um 03:52 schrieb Ben Greear: >>> Hello, >>> >>> I found a strange issue and curious if someone has seen similar. >>> >>> I made an AP where the AP interface acts as a routed interface. I >>> generate >>> traffic through another interface in the router. When sending >>> 300Mbps of 512 byte >>> UDP payloads, in the downstream direction, and with the station >>> being a 1x1 /AC device, >>> then the AP NIC appears to mostly lock up within about 1 minute. I >>> still see beacons, but no >>> data frames. In some cases, I reproduced with very slow speed >>> traffic as well. >>> >>> I tried using a mostly un-modified firmware (ie, similar to upstream >>> QCA), as well as my >>> hacked upon firmware, and all act similarly. I'm using the 4.20 >>> kernel, but at least for now, >>> it does not appear to be a kernel issue. >>> >>> If I use larger MTU sized frames, or have a 2x2 station instead of >>> 1x1 then it is much harder >>> to reproduce (and maybe cannot be reproduced). Also, when >>> generating traffic directly on >>> the AP device instead of using the routed interface as a traffic >>> source, it is harder to >>> reproduce. >>> >>> Thanks, >>> Ben >>> >> > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-15 12:26 ` Sebastian Gottschall @ 2019-05-15 13:00 ` Ben Greear 2019-05-16 19:40 ` Ben Greear 0 siblings, 1 reply; 21+ messages in thread From: Ben Greear @ 2019-05-15 13:00 UTC (permalink / raw) To: Sebastian Gottschall, ath10k On 5/15/19 5:26 AM, Sebastian Gottschall wrote: > > Am 15.05.2019 um 14:20 schrieb Ben Greear: >> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: >>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) >> >> I am using our own traffic generator, but I imagine iperf3 should work fine too. >> >> I am testing on x86-64 and so forth. Maybe you can test with UDP small-packet load on your platform >> in routed mode (ie, external iperf generator through your AP) and see if you see issues? > thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario > is identical which raised up your issue, it would be find if we have identical software for testing including the same options One of our other engineers will try to reproduce it on a different system today. And in case you are sniffing during your own testing, I'd be curious if you see any AMSDU frames? I only see AMPDUS full of single-packet frames. I would expect several of the 512b frames to be put into AMSDU sub-frames. I plan to look into that after I figure out the tx stall issue. Thanks, Ben >> >> From debugging yesterday, I see a lot of tx-hang notifications in the firmware, and >> I also believe I saw it trying to transmit with a 0 rate-indx, which is 11Mbps CCK, >> which is invalid for 5Ghz. I'll be debugging that more today. I don't know if stock >> firmware fails for the same reasons, but the symptom looked the same. > could be a buffer overflow/locking due a udp flooding. so a missing check to drop packets which are out of limit or a too restrictive buffer management. > like static frame buffers of max mtu size, but its just used partially by frame due the small size of the udp packets. you may know it better since you have > much better > knowledge about the firmware internals. >> >> Thanks, >> Ben >> >>> >>> Sebastian >>> >>> Am 15.05.2019 um 03:52 schrieb Ben Greear: >>>> Hello, >>>> >>>> I found a strange issue and curious if someone has seen similar. >>>> >>>> I made an AP where the AP interface acts as a routed interface. I generate >>>> traffic through another interface in the router. When sending 300Mbps of 512 byte >>>> UDP payloads, in the downstream direction, and with the station being a 1x1 /AC device, >>>> then the AP NIC appears to mostly lock up within about 1 minute. I still see beacons, but no >>>> data frames. In some cases, I reproduced with very slow speed traffic as well. >>>> >>>> I tried using a mostly un-modified firmware (ie, similar to upstream QCA), as well as my >>>> hacked upon firmware, and all act similarly. I'm using the 4.20 kernel, but at least for now, >>>> it does not appear to be a kernel issue. >>>> >>>> If I use larger MTU sized frames, or have a 2x2 station instead of 1x1 then it is much harder >>>> to reproduce (and maybe cannot be reproduced). Also, when generating traffic directly on >>>> the AP device instead of using the routed interface as a traffic source, it is harder to >>>> reproduce. >>>> >>>> Thanks, >>>> Ben >>>> >>> >> > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-15 13:00 ` Ben Greear @ 2019-05-16 19:40 ` Ben Greear 2019-05-16 19:55 ` Adrian Chadd 2019-05-17 4:21 ` Sebastian Gottschall 0 siblings, 2 replies; 21+ messages in thread From: Ben Greear @ 2019-05-16 19:40 UTC (permalink / raw) To: Sebastian Gottschall, ath10k On 5/15/19 6:00 AM, Ben Greear wrote: > On 5/15/19 5:26 AM, Sebastian Gottschall wrote: >> >> Am 15.05.2019 um 14:20 schrieb Ben Greear: >>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: >>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) >>> >>> I am using our own traffic generator, but I imagine iperf3 should work fine too. >>> >>> I am testing on x86-64 and so forth. Maybe you can test with UDP small-packet load on your platform >>> in routed mode (ie, external iperf generator through your AP) and see if you see issues? >> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario >> is identical which raised up your issue, it would be find if we have identical software for testing including the same options I think I found the issue. The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates. It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the single OFDM rate is the fault). If you can edit firmware, then setting this to 0 probably fixes the issue. g_rc_cck_rate_allowed I think to reproduce you'd need to send high speed traffic in a situation where the RF environment is going to make rate-ctrl fail quite a bit. (Slow speed should work too, but it would likely take a lot longer). And, it is always possible that whatever I saw when testing mostly-stock FW is different from what I eventually debugged to in my firmware. Still, from looking at MCS vs SNR charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-16 19:40 ` Ben Greear @ 2019-05-16 19:55 ` Adrian Chadd 2019-05-16 20:09 ` Ben Greear 2019-05-17 4:21 ` Sebastian Gottschall 1 sibling, 1 reply; 21+ messages in thread From: Adrian Chadd @ 2019-05-16 19:55 UTC (permalink / raw) To: Ben Greear; +Cc: Sebastian Gottschall, ath10k You can totally go down to OFDM yeah but you then need to send it at 20MHz and non-AMPDU. Is it maybe the retry code + rate control code is retagging an AMPDU at a lower rate and it's transitioning down to CCK/OFDM without breaking the AMPDU apart? -a On Thu, 16 May 2019 at 12:40, Ben Greear <greearb@candelatech.com> wrote: > > On 5/15/19 6:00 AM, Ben Greear wrote: > > On 5/15/19 5:26 AM, Sebastian Gottschall wrote: > >> > >> Am 15.05.2019 um 14:20 schrieb Ben Greear: > >>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: > >>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) > >>> > >>> I am using our own traffic generator, but I imagine iperf3 should work fine too. > >>> > >>> I am testing on x86-64 and so forth. Maybe you can test with UDP small-packet load on your platform > >>> in routed mode (ie, external iperf generator through your AP) and see if you see issues? > >> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario > >> is identical which raised up your issue, it would be find if we have identical software for testing including the same options > > I think I found the issue. The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates. > It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the > single OFDM rate is the fault). > > If you can edit firmware, then setting this to 0 probably fixes the issue. > > g_rc_cck_rate_allowed > > I think to reproduce you'd need to send high speed traffic in a situation where the > RF environment is going to make rate-ctrl fail quite a bit. (Slow speed should > work too, but it would likely take a lot longer). > > And, it is always possible that whatever I saw when testing mostly-stock FW is different > from what I eventually debugged to in my firmware. Still, from looking at MCS vs SNR > charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz. > > Thanks, > Ben > > -- > Ben Greear <greearb@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-16 19:55 ` Adrian Chadd @ 2019-05-16 20:09 ` Ben Greear 2019-05-16 20:16 ` Adrian Chadd 0 siblings, 1 reply; 21+ messages in thread From: Ben Greear @ 2019-05-16 20:09 UTC (permalink / raw) To: Adrian Chadd; +Cc: Sebastian Gottschall, ath10k On 5/16/19 12:55 PM, Adrian Chadd wrote: > You can totally go down to OFDM yeah but you then need to send it at > 20MHz and non-AMPDU. > > Is it maybe the retry code + rate control code is retagging an AMPDU > at a lower rate and it's transitioning down to CCK/OFDM without > breaking the AMPDU apart? It was sending a one-frame AMPDU, and one frame AMSDU for that matter. Maybe there is some bit in the tx descriptor that needed to be twiddled as well to make OFDM able to work, but I don't know what that would be. Is there any advantage of (any) OFDM over MCS0 HT 20Mhz as far as range or SNR goes? The chart I found made it look like there was not, and if not, then why bother at all with OFDM if peer advertises HT/VHT rates? Thanks, Ben > > > -a > > On Thu, 16 May 2019 at 12:40, Ben Greear <greearb@candelatech.com> wrote: >> >> On 5/15/19 6:00 AM, Ben Greear wrote: >>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote: >>>> >>>> Am 15.05.2019 um 14:20 schrieb Ben Greear: >>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: >>>>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) >>>>> >>>>> I am using our own traffic generator, but I imagine iperf3 should work fine too. >>>>> >>>>> I am testing on x86-64 and so forth. Maybe you can test with UDP small-packet load on your platform >>>>> in routed mode (ie, external iperf generator through your AP) and see if you see issues? >>>> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario >>>> is identical which raised up your issue, it would be find if we have identical software for testing including the same options >> >> I think I found the issue. The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates. >> It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the >> single OFDM rate is the fault). >> >> If you can edit firmware, then setting this to 0 probably fixes the issue. >> >> g_rc_cck_rate_allowed >> >> I think to reproduce you'd need to send high speed traffic in a situation where the >> RF environment is going to make rate-ctrl fail quite a bit. (Slow speed should >> work too, but it would likely take a lot longer). >> >> And, it is always possible that whatever I saw when testing mostly-stock FW is different >> from what I eventually debugged to in my firmware. Still, from looking at MCS vs SNR >> charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz. >> >> Thanks, >> Ben >> >> -- >> Ben Greear <greearb@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-16 20:09 ` Ben Greear @ 2019-05-16 20:16 ` Adrian Chadd 2019-05-16 20:20 ` Ben Greear 0 siblings, 1 reply; 21+ messages in thread From: Adrian Chadd @ 2019-05-16 20:16 UTC (permalink / raw) To: Ben Greear; +Cc: Sebastian Gottschall, ath10k You can't do AMPDU with OFDM/CCK. If they're setting the AMPDU bit then that's wrong. it needs to be individual MPDU/PPDUs. There's a benefit for CCK. OFDM 6M is I think roughly the same as OFDM MCS0. But CCK is a lot more reliable. -adrian On Thu, 16 May 2019 at 13:10, Ben Greear <greearb@candelatech.com> wrote: > > On 5/16/19 12:55 PM, Adrian Chadd wrote: > > You can totally go down to OFDM yeah but you then need to send it at > > 20MHz and non-AMPDU. > > > > Is it maybe the retry code + rate control code is retagging an AMPDU > > at a lower rate and it's transitioning down to CCK/OFDM without > > breaking the AMPDU apart? > > It was sending a one-frame AMPDU, and one frame AMSDU for that matter. Maybe > there is some bit in the tx descriptor that needed to be twiddled as well > to make OFDM able to work, but I don't know what that would be. > > Is there any advantage of (any) OFDM over MCS0 HT 20Mhz as far as range or > SNR goes? The chart I found made it look like there was not, and if > not, then why bother at all with OFDM if peer advertises HT/VHT rates? > > Thanks, > Ben > > > > > > > -a > > > > On Thu, 16 May 2019 at 12:40, Ben Greear <greearb@candelatech.com> wrote: > >> > >> On 5/15/19 6:00 AM, Ben Greear wrote: > >>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote: > >>>> > >>>> Am 15.05.2019 um 14:20 schrieb Ben Greear: > >>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: > >>>>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) > >>>>> > >>>>> I am using our own traffic generator, but I imagine iperf3 should work fine too. > >>>>> > >>>>> I am testing on x86-64 and so forth. Maybe you can test with UDP small-packet load on your platform > >>>>> in routed mode (ie, external iperf generator through your AP) and see if you see issues? > >>>> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario > >>>> is identical which raised up your issue, it would be find if we have identical software for testing including the same options > >> > >> I think I found the issue. The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates. > >> It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the > >> single OFDM rate is the fault). > >> > >> If you can edit firmware, then setting this to 0 probably fixes the issue. > >> > >> g_rc_cck_rate_allowed > >> > >> I think to reproduce you'd need to send high speed traffic in a situation where the > >> RF environment is going to make rate-ctrl fail quite a bit. (Slow speed should > >> work too, but it would likely take a lot longer). > >> > >> And, it is always possible that whatever I saw when testing mostly-stock FW is different > >> from what I eventually debugged to in my firmware. Still, from looking at MCS vs SNR > >> charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz. > >> > >> Thanks, > >> Ben > >> > >> -- > >> Ben Greear <greearb@candelatech.com> > >> Candela Technologies Inc http://www.candelatech.com > >> > >> > >> _______________________________________________ > >> ath10k mailing list > >> ath10k@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/ath10k > > > > > -- > Ben Greear <greearb@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-16 20:16 ` Adrian Chadd @ 2019-05-16 20:20 ` Ben Greear 2019-05-16 20:35 ` Adrian Chadd 0 siblings, 1 reply; 21+ messages in thread From: Ben Greear @ 2019-05-16 20:20 UTC (permalink / raw) To: Adrian Chadd; +Cc: Sebastian Gottschall, ath10k On 5/16/19 1:16 PM, Adrian Chadd wrote: > You can't do AMPDU with OFDM/CCK. If they're setting the AMPDU bit > then that's wrong. it needs to be individual MPDU/PPDUs. > > There's a benefit for CCK. OFDM 6M is I think roughly the same as OFDM > MCS0. But CCK is a lot more reliable. 5Ghz can (should) not do CCK anyway. Do you have any reference for why you think CCK will be better? The one I found shows otherwise: https://d2cpnw0u24fjm4.cloudfront.net/wp-content/uploads/LaminatedCard_RevolutionWiFiMCStoSNRSinglePage.png Thanks, Ben > > > -adrian > > On Thu, 16 May 2019 at 13:10, Ben Greear <greearb@candelatech.com> wrote: >> >> On 5/16/19 12:55 PM, Adrian Chadd wrote: >>> You can totally go down to OFDM yeah but you then need to send it at >>> 20MHz and non-AMPDU. >>> >>> Is it maybe the retry code + rate control code is retagging an AMPDU >>> at a lower rate and it's transitioning down to CCK/OFDM without >>> breaking the AMPDU apart? >> >> It was sending a one-frame AMPDU, and one frame AMSDU for that matter. Maybe >> there is some bit in the tx descriptor that needed to be twiddled as well >> to make OFDM able to work, but I don't know what that would be. >> >> Is there any advantage of (any) OFDM over MCS0 HT 20Mhz as far as range or >> SNR goes? The chart I found made it look like there was not, and if >> not, then why bother at all with OFDM if peer advertises HT/VHT rates? >> >> Thanks, >> Ben >> >>> >>> >>> -a >>> >>> On Thu, 16 May 2019 at 12:40, Ben Greear <greearb@candelatech.com> wrote: >>>> >>>> On 5/15/19 6:00 AM, Ben Greear wrote: >>>>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote: >>>>>> >>>>>> Am 15.05.2019 um 14:20 schrieb Ben Greear: >>>>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: >>>>>>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) >>>>>>> >>>>>>> I am using our own traffic generator, but I imagine iperf3 should work fine too. >>>>>>> >>>>>>> I am testing on x86-64 and so forth. Maybe you can test with UDP small-packet load on your platform >>>>>>> in routed mode (ie, external iperf generator through your AP) and see if you see issues? >>>>>> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario >>>>>> is identical which raised up your issue, it would be find if we have identical software for testing including the same options >>>> >>>> I think I found the issue. The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates. >>>> It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the >>>> single OFDM rate is the fault). >>>> >>>> If you can edit firmware, then setting this to 0 probably fixes the issue. >>>> >>>> g_rc_cck_rate_allowed >>>> >>>> I think to reproduce you'd need to send high speed traffic in a situation where the >>>> RF environment is going to make rate-ctrl fail quite a bit. (Slow speed should >>>> work too, but it would likely take a lot longer). >>>> >>>> And, it is always possible that whatever I saw when testing mostly-stock FW is different >>>> from what I eventually debugged to in my firmware. Still, from looking at MCS vs SNR >>>> charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz. >>>> >>>> Thanks, >>>> Ben >>>> >>>> -- >>>> Ben Greear <greearb@candelatech.com> >>>> Candela Technologies Inc http://www.candelatech.com >>>> >>>> >>>> _______________________________________________ >>>> ath10k mailing list >>>> ath10k@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> >> -- >> Ben Greear <greearb@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-16 20:20 ` Ben Greear @ 2019-05-16 20:35 ` Adrian Chadd 0 siblings, 0 replies; 21+ messages in thread From: Adrian Chadd @ 2019-05-16 20:35 UTC (permalink / raw) To: Ben Greear; +Cc: Sebastian Gottschall, ath10k On Thu, 16 May 2019 at 13:20, Ben Greear <greearb@candelatech.com> wrote: > > On 5/16/19 1:16 PM, Adrian Chadd wrote: > > You can't do AMPDU with OFDM/CCK. If they're setting the AMPDU bit > > then that's wrong. it needs to be individual MPDU/PPDUs. > > > > There's a benefit for CCK. OFDM 6M is I think roughly the same as OFDM > > MCS0. But CCK is a lot more reliable. > > 5Ghz can (should) not do CCK anyway. Do you have any reference for why > you think CCK will be better? The one I found shows otherwise: > > https://d2cpnw0u24fjm4.cloudfront.net/wp-content/uploads/LaminatedCard_RevolutionWiFiMCStoSNRSinglePage.png Well, you should try measuring it :-) I remember stories of decoding CCK frames with MRC-CCK at an RSSI of 0 or -1... And yes, you shouldn't do CCK on 5G, but some wifi PHYs do support it ("support" "it")... -adrian _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-16 19:40 ` Ben Greear 2019-05-16 19:55 ` Adrian Chadd @ 2019-05-17 4:21 ` Sebastian Gottschall 2019-05-17 11:48 ` Ben Greear 1 sibling, 1 reply; 21+ messages in thread From: Sebastian Gottschall @ 2019-05-17 4:21 UTC (permalink / raw) To: ath10k Am 16.05.2019 um 21:40 schrieb Ben Greear: > On 5/15/19 6:00 AM, Ben Greear wrote: >> On 5/15/19 5:26 AM, Sebastian Gottschall wrote: >>> >>> Am 15.05.2019 um 14:20 schrieb Ben Greear: >>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: >>>>> can you send me a detailed instruction for testing this on my >>>>> devices? so which commands have been used for generating the >>>>> traffic etc. (iperf3?) >>>> >>>> I am using our own traffic generator, but I imagine iperf3 should >>>> work fine too. >>>> >>>> I am testing on x86-64 and so forth. Maybe you can test with UDP >>>> small-packet load on your platform >>>> in routed mode (ie, external iperf generator through your AP) and >>>> see if you see issues? >>> thats the plan. can you do a test with iperf3 to see if its >>> reproduceable. i mean i will test it on ipq based boards and x64. >>> but to make sure that the scenario >>> is identical which raised up your issue, it would be find if we have >>> identical software for testing including the same options > > I think I found the issue. The rate-ctrl logic in the firmware allows > a transition from HT/VHT 20 MCS0 down to OFDM rates. > It seems the hardware does not like to see an AMPDU with an OFDM rate > for 20Mhz and a VHT rate for 80Mhz (or maybe just the > single OFDM rate is the fault). > > If you can edit firmware, then setting this to 0 probably fixes the > issue. > > g_rc_cck_rate_allowed according to the code this variable has only effect on 2.4 ghz. the fallback to cck rates will only be done if phymode is 2.4 ghz > > I think to reproduce you'd need to send high speed traffic in a > situation where the > RF environment is going to make rate-ctrl fail quite a bit. (Slow > speed should > work too, but it would likely take a lot longer). > > And, it is always possible that whatever I saw when testing > mostly-stock FW is different > from what I eventually debugged to in my firmware. Still, from > looking at MCS vs SNR > charts, there seems to be no advantage to trying OFDM vs MCS0 for 20Mhz. > > Thanks, > Ben > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-17 4:21 ` Sebastian Gottschall @ 2019-05-17 11:48 ` Ben Greear 2019-05-17 15:05 ` Sebastian Gottschall 0 siblings, 1 reply; 21+ messages in thread From: Ben Greear @ 2019-05-17 11:48 UTC (permalink / raw) To: Sebastian Gottschall, ath10k On 05/16/2019 09:21 PM, Sebastian Gottschall wrote: > > Am 16.05.2019 um 21:40 schrieb Ben Greear: >> On 5/15/19 6:00 AM, Ben Greear wrote: >>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote: >>>> >>>> Am 15.05.2019 um 14:20 schrieb Ben Greear: >>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: >>>>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) >>>>> >>>>> I am using our own traffic generator, but I imagine iperf3 should work fine too. >>>>> >>>>> I am testing on x86-64 and so forth. Maybe you can test with UDP small-packet load on your platform >>>>> in routed mode (ie, external iperf generator through your AP) and see if you see issues? >>>> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario >>>> is identical which raised up your issue, it would be find if we have identical software for testing including the same options >> >> I think I found the issue. The rate-ctrl logic in the firmware allows a transition from HT/VHT 20 MCS0 down to OFDM rates. >> It seems the hardware does not like to see an AMPDU with an OFDM rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the >> single OFDM rate is the fault). >> >> If you can edit firmware, then setting this to 0 probably fixes the issue. >> >> g_rc_cck_rate_allowed > > according to the code this variable has only effect on 2.4 ghz. the fallback to cck rates will only be done if phymode is 2.4 ghz Ok, maybe the symptom I saw with stock-ish firmware was due to some other cause. In my firmware, I had "fixed" that cck-fallback to use OFDM rates in case CCK was not available, so mine was definitely trying to use an OFDM rate. That said, very likely the same bug exists in upstream QCA firmware for 2.4Ghz radios where CCK is available, so still might be worth fixing or at least adding API to let the user disable the fallback in case strange problems are seen. I am guessing that if it really wants to send OFDM/CCK rates, then it will have to use a different TID that is not set up for AMPDUs, and the current code does not deal with that as far as I can tell. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-17 11:48 ` Ben Greear @ 2019-05-17 15:05 ` Sebastian Gottschall 2019-05-17 15:47 ` Adrian Chadd 0 siblings, 1 reply; 21+ messages in thread From: Sebastian Gottschall @ 2019-05-17 15:05 UTC (permalink / raw) To: ath10k Am 17.05.2019 um 13:48 schrieb Ben Greear: > > > On 05/16/2019 09:21 PM, Sebastian Gottschall wrote: >> >> Am 16.05.2019 um 21:40 schrieb Ben Greear: >>> On 5/15/19 6:00 AM, Ben Greear wrote: >>>> On 5/15/19 5:26 AM, Sebastian Gottschall wrote: >>>>> >>>>> Am 15.05.2019 um 14:20 schrieb Ben Greear: >>>>>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote: >>>>>>> can you send me a detailed instruction for testing this on my >>>>>>> devices? so which commands have been used for generating the >>>>>>> traffic etc. (iperf3?) >>>>>> >>>>>> I am using our own traffic generator, but I imagine iperf3 should >>>>>> work fine too. >>>>>> >>>>>> I am testing on x86-64 and so forth. Maybe you can test with UDP >>>>>> small-packet load on your platform >>>>>> in routed mode (ie, external iperf generator through your AP) and >>>>>> see if you see issues? >>>>> thats the plan. can you do a test with iperf3 to see if its >>>>> reproduceable. i mean i will test it on ipq based boards and x64. >>>>> but to make sure that the scenario >>>>> is identical which raised up your issue, it would be find if we >>>>> have identical software for testing including the same options >>> >>> I think I found the issue. The rate-ctrl logic in the firmware >>> allows a transition from HT/VHT 20 MCS0 down to OFDM rates. >>> It seems the hardware does not like to see an AMPDU with an OFDM >>> rate for 20Mhz and a VHT rate for 80Mhz (or maybe just the >>> single OFDM rate is the fault). >>> >>> If you can edit firmware, then setting this to 0 probably fixes the >>> issue. >>> >>> g_rc_cck_rate_allowed >> >> according to the code this variable has only effect on 2.4 ghz. the >> fallback to cck rates will only be done if phymode is 2.4 ghz > > Ok, maybe the symptom I saw with stock-ish firmware was due to some > other cause. In my firmware, > I had "fixed" that cck-fallback to use OFDM rates in case CCK was not > available, so mine was > definitely trying to use an OFDM rate. > > That said, very likely the same bug exists in upstream QCA firmware > for 2.4Ghz radios where CCK is available, > so still might be worth fixing or at least adding API to let the user > disable the fallback in case strange > problems are seen. > > I am guessing that if it really wants to send OFDM/CCK rates, then it > will have to use a different > TID that is not set up for AMPDUs, and the current code does not deal > with that as far as I can tell. personally i think going back to basic rates like 2 mbit makes no sense anyway. its that dead slow that a connection must break and has to be broken if this doesnt work. still a shame that beacons are still transmitted in this way and multicast/broadcast packets as well which causes a hell of problems. but thats for backward compatibility of cause > > Thanks, > Ben > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-17 15:05 ` Sebastian Gottschall @ 2019-05-17 15:47 ` Adrian Chadd 2019-05-17 16:00 ` Ben Greear 2019-05-20 16:58 ` Sebastian Gottschall 0 siblings, 2 replies; 21+ messages in thread From: Adrian Chadd @ 2019-05-17 15:47 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: ath10k On Fri, 17 May 2019 at 08:06, Sebastian Gottschall <s.gottschall@newmedia-net.de> wrote: > personally i think going back to basic rates like 2 mbit makes no sense > anyway. its that dead slow that a connection must break and has to be > broken if this doesnt work. > still a shame that beacons are still transmitted in this way and > multicast/broadcast packets as well which causes a hell of problems. but > thats for backward compatibility of cause It depends on what kind of channel you are. Not everyone is deploying super dense enterprise APs. :-) The 11ac and 11ax chips that do constant frequency readjusting work better in things like moving drones, where you have constant doppler shift. I know some people doing drone work that just don't bother with MCS and aggregation because they need a super reliable channel and the conditions constantly shift. That said, they're very sad that they can't hack on the 11ac/11ax firmware to fix some err, less optimal decisions in their use case space like they can with ath5k/ath9k. ISTR back at QCA days there were some people on the systems team that could demonstrate CCK was more stable in some use cases and so didn't like the Linux rate control behaviour of not falling back to CCK in 2G 11n mode. There was .. pushback against the linux upstream rate control in this respect right until the linux folk totally deprecated the QCA rate control in ath9k. :) (And then bugs like what ben is seeing :) Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit that tries to send AMPDU frames in non-11n rates? -adrian _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-17 15:47 ` Adrian Chadd @ 2019-05-17 16:00 ` Ben Greear 2019-05-17 16:12 ` Adrian Chadd 2019-05-20 16:59 ` Sebastian Gottschall 2019-05-20 16:58 ` Sebastian Gottschall 1 sibling, 2 replies; 21+ messages in thread From: Ben Greear @ 2019-05-17 16:00 UTC (permalink / raw) To: Adrian Chadd, Sebastian Gottschall; +Cc: ath10k On 5/17/19 8:47 AM, Adrian Chadd wrote: > On Fri, 17 May 2019 at 08:06, Sebastian Gottschall > <s.gottschall@newmedia-net.de> wrote: > > >> personally i think going back to basic rates like 2 mbit makes no sense >> anyway. its that dead slow that a connection must break and has to be >> broken if this doesnt work. >> still a shame that beacons are still transmitted in this way and >> multicast/broadcast packets as well which causes a hell of problems. but >> thats for backward compatibility of cause > > It depends on what kind of channel you are. Not everyone is deploying > super dense enterprise APs. :-) > > The 11ac and 11ax chips that do constant frequency readjusting work > better in things like moving drones, where you have constant doppler > shift. I know some people doing drone work that just don't bother with > MCS and aggregation because they need a super reliable channel and the > conditions constantly shift. > > That said, they're very sad that they can't hack on the 11ac/11ax > firmware to fix some err, less optimal decisions in their use case > space like they can with ath5k/ath9k. > > ISTR back at QCA days there were some people on the systems team that > could demonstrate CCK was more stable in some use cases and so didn't > like the Linux rate control behaviour of not falling back to CCK in 2G > 11n mode. There was .. pushback against the linux upstream rate > control in this respect right until the linux folk totally deprecated > the QCA rate control in ath9k. :) > > (And then bugs like what ben is seeing :) > > Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit > that tries to send AMPDU frames in non-11n rates? Yes, disabling the fallback appears to have fixed my issue. I did not try to fix the fallback code because I think it will be quite complicated to do it properly (I suspect a different tid must be used for this to work). I'm not even entirely sure of exactly why the transmit logic fails in this case, and by the time rate-ctrl logic is queried, I think it is too late to easily change tids. And FYI, in my firmware/driver, you can now specify the exact preamble-type, mcs, bandwidth, txpower, retransmit count, etc on a per packet basis. I'm not sure of all the bugs and limitations in this code, but it at least mostly works as hoped for the ways we are using it (rx sensitivity test rigs, etc). Might be of interest if someone wants to do a somewhat limited user-space rate-ctrl for ath10k wave-2. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-17 16:00 ` Ben Greear @ 2019-05-17 16:12 ` Adrian Chadd 2019-05-20 16:59 ` Sebastian Gottschall 1 sibling, 0 replies; 21+ messages in thread From: Adrian Chadd @ 2019-05-17 16:12 UTC (permalink / raw) To: Ben Greear; +Cc: Sebastian Gottschall, ath10k On Fri, 17 May 2019 at 09:00, Ben Greear <greearb@candelatech.com> wrote: > > On 5/17/19 8:47 AM, Adrian Chadd wrote: > > On Fri, 17 May 2019 at 08:06, Sebastian Gottschall > > <s.gottschall@newmedia-net.de> wrote: > > > > > >> personally i think going back to basic rates like 2 mbit makes no sense > >> anyway. its that dead slow that a connection must break and has to be > >> broken if this doesnt work. > >> still a shame that beacons are still transmitted in this way and > >> multicast/broadcast packets as well which causes a hell of problems. but > >> thats for backward compatibility of cause > > > > It depends on what kind of channel you are. Not everyone is deploying > > super dense enterprise APs. :-) > > > > The 11ac and 11ax chips that do constant frequency readjusting work > > better in things like moving drones, where you have constant doppler > > shift. I know some people doing drone work that just don't bother with > > MCS and aggregation because they need a super reliable channel and the > > conditions constantly shift. > > > > That said, they're very sad that they can't hack on the 11ac/11ax > > firmware to fix some err, less optimal decisions in their use case > > space like they can with ath5k/ath9k. > > > > ISTR back at QCA days there were some people on the systems team that > > could demonstrate CCK was more stable in some use cases and so didn't > > like the Linux rate control behaviour of not falling back to CCK in 2G > > 11n mode. There was .. pushback against the linux upstream rate > > control in this respect right until the linux folk totally deprecated > > the QCA rate control in ath9k. :) > > > > (And then bugs like what ben is seeing :) > > > > Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit > > that tries to send AMPDU frames in non-11n rates? > > Yes, disabling the fallback appears to have fixed my issue. > > I did not try to fix the fallback code because I think it will be quite > complicated to do it properly (I suspect a different tid must be used for this > to work). I'm not even entirely sure of exactly why the transmit logic fails > in this case, and by the time rate-ctrl logic is queried, I think it is too > late to easily change tids. Ok. I'll reach to you offline (irc maybe?) and let's see if we can get QCA to fix this in their firmware. I know there's a LOT of things that need fixing in the upstream firmware but this is a pretty big bug that needs squishing for everyone. Thanks! -adrian _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-17 16:00 ` Ben Greear 2019-05-17 16:12 ` Adrian Chadd @ 2019-05-20 16:59 ` Sebastian Gottschall 2019-05-20 19:25 ` Adrian Chadd 1 sibling, 1 reply; 21+ messages in thread From: Sebastian Gottschall @ 2019-05-20 16:59 UTC (permalink / raw) To: Ben Greear, Adrian Chadd; +Cc: ath10k Am 17.05.2019 um 18:00 schrieb Ben Greear: > On 5/17/19 8:47 AM, Adrian Chadd wrote: >> On Fri, 17 May 2019 at 08:06, Sebastian Gottschall >> <s.gottschall@newmedia-net.de> wrote: >> >> >>> personally i think going back to basic rates like 2 mbit makes no sense >>> anyway. its that dead slow that a connection must break and has to be >>> broken if this doesnt work. >>> still a shame that beacons are still transmitted in this way and >>> multicast/broadcast packets as well which causes a hell of problems. >>> but >>> thats for backward compatibility of cause >> >> It depends on what kind of channel you are. Not everyone is deploying >> super dense enterprise APs. :-) >> >> The 11ac and 11ax chips that do constant frequency readjusting work >> better in things like moving drones, where you have constant doppler >> shift. I know some people doing drone work that just don't bother with >> MCS and aggregation because they need a super reliable channel and the >> conditions constantly shift. >> >> That said, they're very sad that they can't hack on the 11ac/11ax >> firmware to fix some err, less optimal decisions in their use case >> space like they can with ath5k/ath9k. >> >> ISTR back at QCA days there were some people on the systems team that >> could demonstrate CCK was more stable in some use cases and so didn't >> like the Linux rate control behaviour of not falling back to CCK in 2G >> 11n mode. There was .. pushback against the linux upstream rate >> control in this respect right until the linux folk totally deprecated >> the QCA rate control in ath9k. :) >> >> (And then bugs like what ben is seeing :) >> >> Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit >> that tries to send AMPDU frames in non-11n rates? > > Yes, disabling the fallback appears to have fixed my issue. > > I did not try to fix the fallback code because I think it will be quite > complicated to do it properly (I suspect a different tid must be used > for this > to work). I'm not even entirely sure of exactly why the transmit > logic fails > in this case, and by the time rate-ctrl logic is queried, I think it > is too > late to easily change tids. > > And FYI, in my firmware/driver, you can now specify the exact > preamble-type, mcs, bandwidth, txpower, > retransmit count, etc on a per packet basis. I'm not sure of all the > bugs and limitations > in this code, but it at least mostly works as hoped for the ways we > are using it > (rx sensitivity test rigs, etc). > > Might be of interest if someone wants to do a somewhat limited > user-space rate-ctrl for > ath10k wave-2. the curious thing is still that the fallback code applies only for 2.4 ghz so it would never have affected 802.11ac > > Thanks, > Ben > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-20 16:59 ` Sebastian Gottschall @ 2019-05-20 19:25 ` Adrian Chadd 2019-05-20 19:54 ` Ben Greear 0 siblings, 1 reply; 21+ messages in thread From: Adrian Chadd @ 2019-05-20 19:25 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: Ben Greear, ath10k On Mon, 20 May 2019 at 09:59, Sebastian Gottschall <s.gottschall@newmedia-net.de> wrote: > the curious thing is still that the fallback code applies only for 2.4 > ghz so it would never have affected 802.11ac Hm, does RC fall back to 11na or 11a rates when doing 11ac? (in 5G mode.) It's good to know fixing that would fix it in 2.4GHz operation but yeah, I wonder about RC in 5G. -adian _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-20 19:25 ` Adrian Chadd @ 2019-05-20 19:54 ` Ben Greear 0 siblings, 0 replies; 21+ messages in thread From: Ben Greear @ 2019-05-20 19:54 UTC (permalink / raw) To: Adrian Chadd, Sebastian Gottschall; +Cc: ath10k On 5/20/19 12:25 PM, Adrian Chadd wrote: > On Mon, 20 May 2019 at 09:59, Sebastian Gottschall > <s.gottschall@newmedia-net.de> wrote: > > >> the curious thing is still that the fallback code applies only for 2.4 >> ghz so it would never have affected 802.11ac > > Hm, does RC fall back to 11na or 11a rates when doing 11ac? (in 5G > mode.) It's good to know fixing that would fix it in 2.4GHz operation > but yeah, I wonder about RC in 5G. It appears the rate-ctrl tries to fall to CCK 2Mbps or 1Mbps and skips a/g rates. /n rates are a subset of VHT, so those are used as part of normal VHT rate-ctrl. I have no explanation for why I saw the tx-hang in stock-ish firmware, which indeed should not have tried to use any a/g rates in 5Ghz. The high-level failure looked exactly like what I eventually debugged as falling back to /a rates in my firmware, for what that is worth. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Problem with 9984 in routed mode with 512b frames. 2019-05-17 15:47 ` Adrian Chadd 2019-05-17 16:00 ` Ben Greear @ 2019-05-20 16:58 ` Sebastian Gottschall 1 sibling, 0 replies; 21+ messages in thread From: Sebastian Gottschall @ 2019-05-20 16:58 UTC (permalink / raw) To: Adrian Chadd; +Cc: ath10k Am 17.05.2019 um 17:47 schrieb Adrian Chadd: > On Fri, 17 May 2019 at 08:06, Sebastian Gottschall > <s.gottschall@newmedia-net.de> wrote: > > >> personally i think going back to basic rates like 2 mbit makes no sense >> anyway. its that dead slow that a connection must break and has to be >> broken if this doesnt work. >> still a shame that beacons are still transmitted in this way and >> multicast/broadcast packets as well which causes a hell of problems. but >> thats for backward compatibility of cause > It depends on what kind of channel you are. Not everyone is deploying > super dense enterprise APs. :-) > > The 11ac and 11ax chips that do constant frequency readjusting work > better in things like moving drones, where you have constant doppler > shift. I know some people doing drone work that just don't bother with > MCS and aggregation because they need a super reliable channel and the > conditions constantly shift. > > That said, they're very sad that they can't hack on the 11ac/11ax > firmware to fix some err, less optimal decisions in their use case > space like they can with ath5k/ath9k. > > ISTR back at QCA days there were some people on the systems team that > could demonstrate CCK was more stable in some use cases and so didn't > like the Linux rate control behaviour of not falling back to CCK in 2G > 11n mode. There was .. pushback against the linux upstream rate > control in this respect right until the linux folk totally deprecated > the QCA rate control in ath9k. :) CCK is dead stable of cause, but also dead slow and its blocking the channel which decreases performance for all other people > > (And then bugs like what ben is seeing :) > > Ben - did disabling CCK/OFDM fallback rates help? Did you fix the bit > that tries to send AMPDU frames in non-11n rates? > > > -adrian > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2019-05-20 19:54 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-05-15 1:52 Problem with 9984 in routed mode with 512b frames Ben Greear 2019-05-15 4:26 ` Sebastian Gottschall 2019-05-15 12:20 ` Ben Greear 2019-05-15 12:26 ` Sebastian Gottschall 2019-05-15 13:00 ` Ben Greear 2019-05-16 19:40 ` Ben Greear 2019-05-16 19:55 ` Adrian Chadd 2019-05-16 20:09 ` Ben Greear 2019-05-16 20:16 ` Adrian Chadd 2019-05-16 20:20 ` Ben Greear 2019-05-16 20:35 ` Adrian Chadd 2019-05-17 4:21 ` Sebastian Gottschall 2019-05-17 11:48 ` Ben Greear 2019-05-17 15:05 ` Sebastian Gottschall 2019-05-17 15:47 ` Adrian Chadd 2019-05-17 16:00 ` Ben Greear 2019-05-17 16:12 ` Adrian Chadd 2019-05-20 16:59 ` Sebastian Gottschall 2019-05-20 19:25 ` Adrian Chadd 2019-05-20 19:54 ` Ben Greear 2019-05-20 16:58 ` Sebastian Gottschall
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
