* [ath9k-devel] ath9k monitor mode injection packet delay @ 2016-06-28 3:55 Cesar 2016-06-28 20:05 ` Adrian Chadd 0 siblings, 1 reply; 6+ messages in thread From: Cesar @ 2016-06-28 3:55 UTC (permalink / raw) To: ath9k-devel Hello all, We?ve recently tried to test packet injection performace in ath9k monitor mode. We set 2 laptops in monitor mode , PC 1 send a 500 Byte packets out, and PC 2 return a 500 Bytes packet back at once when it receives the packet of PC 1. Then we measured the RTT time and found it's about 1000us !!! Test environment: NIC: AR9287 driver: ath9k system: ubuntu 14.04 with kernel 3.14.57 send rate : at a fixed rate 54Mb We tried to send packets as "low" as possible in driver stack, and we're sure that we disabled the CCA and backoff using flags below: AR_DIAG_FORCE_CH_IDLE_HIGH AR_DIAG_IGNORE_VIRT_CS AR_D_GBL_IFS_MISC_IGNORE_BACKOFF besides we change the aifs to 1 and cwmin cwmax to 0 in ath_txq_setup to ensure there's no backoff. we even put our laptaps to a underground garage where channel is almost clean.But the test results is still about 1000us.... We've been stucked for serveral months, Any suggestion? Any feedback welcome... Thnkz in advance!!! Cesar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160628/191bdc9e/attachment.htm ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] ath9k monitor mode injection packet delay 2016-06-28 3:55 [ath9k-devel] ath9k monitor mode injection packet delay Cesar @ 2016-06-28 20:05 ` Adrian Chadd 2016-06-29 2:05 ` Cesar 0 siblings, 1 reply; 6+ messages in thread From: Adrian Chadd @ 2016-06-28 20:05 UTC (permalink / raw) To: ath9k-devel Hi, can you try this using pci/pcie devices instead of USB? There may be USB scheduling things in the way. On 27 June 2016 at 20:55, Cesar <caesargo@163.com> wrote: > Hello all, > We?ve recently tried to test packet injection performace in ath9k monitor > mode. We set 2 laptops in monitor mode , PC 1 send a 500 Byte packets out, > and PC 2 return a 500 Bytes packet back at once when it receives the packet > of PC 1. Then we measured the RTT time and found it's about 1000us !!! > > Test environment: > NIC: AR9287 > driver: ath9k > system: ubuntu 14.04 with kernel 3.14.57 > send rate : at a fixed rate 54Mb > > > We tried to send packets as "low" as possible in driver stack, and we're > sure that we disabled the CCA and backoff using flags below: > > AR_DIAG_FORCE_CH_IDLE_HIGH > AR_DIAG_IGNORE_VIRT_CS > AR_D_GBL_IFS_MISC_IGNORE_BACKOFF > > besides we change the aifs to 1 and cwmin cwmax to 0 in ath_txq_setup to > ensure there's no backoff. we even put our laptaps to a underground garage > where channel is almost clean.But the test results is still about 1000us.... > > We've been stucked for serveral months, Any suggestion? > Any feedback welcome... > Thnkz in advance!!! > > Cesar > > > > > > > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] ath9k monitor mode injection packet delay 2016-06-28 20:05 ` Adrian Chadd @ 2016-06-29 2:05 ` Cesar 2016-06-29 2:46 ` Adrian Chadd 0 siblings, 1 reply; 6+ messages in thread From: Cesar @ 2016-06-29 2:05 UTC (permalink / raw) To: ath9k-devel Dear Adrian Chadd, Thanks for your reply. It's correct that USB may introduce some delays, but in our experiment we use mini-pcie devices indeed... Cesar At 2016-06-29 04:05:32, "Adrian Chadd" <adrian@freebsd.org> wrote: >Hi, > >can you try this using pci/pcie devices instead of USB? There may be >USB scheduling things in the way. > >On 27 June 2016 at 20:55, Cesar <caesargo@163.com> wrote: >> Hello all, >> We?ve recently tried to test packet injection performace in ath9k monitor >> mode. We set 2 laptops in monitor mode , PC 1 send a 500 Byte packets out, >> and PC 2 return a 500 Bytes packet back at once when it receives the packet >> of PC 1. Then we measured the RTT time and found it's about 1000us !!! >> >> Test environment: >> NIC: AR9287 >> driver: ath9k >> system: ubuntu 14.04 with kernel 3.14.57 >> send rate : at a fixed rate 54Mb >> >> >> We tried to send packets as "low" as possible in driver stack, and we're >> sure that we disabled the CCA and backoff using flags below: >> >> AR_DIAG_FORCE_CH_IDLE_HIGH >> AR_DIAG_IGNORE_VIRT_CS >> AR_D_GBL_IFS_MISC_IGNORE_BACKOFF >> >> besides we change the aifs to 1 and cwmin cwmax to 0 in ath_txq_setup to >> ensure there's no backoff. we even put our laptaps to a underground garage >> where channel is almost clean.But the test results is still about 1000us.... >> >> We've been stucked for serveral months, Any suggestion? >> Any feedback welcome... >> Thnkz in advance!!! >> >> Cesar >> >> >> >> >> >> >> >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel at lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160629/b9bab7a5/attachment.htm ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] ath9k monitor mode injection packet delay 2016-06-29 2:05 ` Cesar @ 2016-06-29 2:46 ` Adrian Chadd 2016-07-05 11:24 ` Cesar 0 siblings, 1 reply; 6+ messages in thread From: Adrian Chadd @ 2016-06-29 2:46 UTC (permalink / raw) To: ath9k-devel hi! ok. 1ms is a long amount of time. Maybe use the tracing feature in ath9k and/or add some debugging in the RX and TX paths that log the TSC (system clock) value whenever the RX path and TX queue path fires? See if it's scheduling things to the hardware quickly or not. It may be something really silly like context switching between the RX and TX threads of the driver. -adrian On 28 June 2016 at 19:05, Cesar <caesargo@163.com> wrote: > Dear Adrian Chadd, > > Thanks for your reply. It's correct that USB may introduce some delays, but > in our experiment we use mini-pcie devices indeed... > > Cesar > > > > > > > > At 2016-06-29 04:05:32, "Adrian Chadd" <adrian@freebsd.org> wrote: >>Hi, >> >>can you try this using pci/pcie devices instead of USB? There may be >>USB scheduling things in the way. >> >>On 27 June 2016 at 20:55, Cesar <caesargo@163.com> wrote: >>> Hello all, >>> We?ve recently tried to test packet injection performace in ath9k monitor >>> mode. We set 2 laptops in monitor mode , PC 1 send a 500 Byte packets >>> out, >>> and PC 2 return a 500 Bytes packet back at once when it receives the >>> packet >>> of PC 1. Then we measured the RTT time and found it's about 1000us !!! >>> >>> Test environment: >>> NIC: AR9287 >>> driver: ath9k >>> system: ubuntu 14.04 with kernel 3.14.57 >>> send rate : at a fixed rate 54Mb >>> >>> >>> We tried to send packets as "low" as possible in driver stack, and we're >>> sure that we disabled the CCA and backoff using flags below: >>> >>> AR_DIAG_FORCE_CH_IDLE_HIGH >>> AR_DIAG_IGNORE_VIRT_CS >>> AR_D_GBL_IFS_MISC_IGNORE_BACKOFF >>> >>> besides we change the aifs to 1 and cwmin cwmax to 0 in ath_txq_setup to >>> ensure there's no backoff. we even put our laptaps to a underground >>> garage >>> where channel is almost clean.But the test results is still about >>> 1000us.... >>> >>> We've been stucked for serveral months, Any suggestion? >>> Any feedback welcome... >>> Thnkz in advance!!! >>> >>> Cesar >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> ath9k-devel mailing list >>> ath9k-devel at lists.ath9k.org >>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>> > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] ath9k monitor mode injection packet delay 2016-06-29 2:46 ` Adrian Chadd @ 2016-07-05 11:24 ` Cesar 2016-07-06 15:18 ` Adrian Chadd 0 siblings, 1 reply; 6+ messages in thread From: Cesar @ 2016-07-05 11:24 UTC (permalink / raw) To: ath9k-devel Dear Adrian Chadd, Thanks for your suggestion... After that we did some experiments following your suggestion. We enable ath9k debug mode, the log shows the tx delay is about 150us. [ 1865.064485] ath: phy4: transmitting packet, skb: f32ecd80 [ 1865.064505] ath: phy4: qnum: 1, txq depth: 0 [ 1865.064512] ath: phy4: TXDP[1] = 32ec0000 (f2ec0000) [ 1865.064516] ath: phy4: Enable TXE on queue: 1 [ 1865.064561] ath: phy4: tx queue 1 (32ec0000), link f2ec0000 [ 1865.064615] ath: phy4: tx queue 1 (32ec0000), link f2ec0000 [ 1865.064622] ath: phy4: TX complete: skb: f32ecd80 Considering that the printk() may introduce some delay, so we use trace_printk() at the same place then disable the debug mode, the result didn't change much. And we measured the rx delay use trace_printk() too, from the rx_tasklet to the upper layer the delay is about 50us. So in theory the RTT should be (150+50) *2 = 400 us.. But the total turn-around delay is still 1000us... We don't know where the delay could happen, maybe the packet does not truly send out when it displays "TX complete"? Or packet could not enter ath_isr at at the first time when packet arrived? Any other suggestions? Thanks Cesar At 2016-06-29 10:46:18, "Adrian Chadd" <adrian@freebsd.org> wrote: >hi! > >ok. 1ms is a long amount of time. Maybe use the tracing feature in >ath9k and/or add some debugging in the RX and TX paths that log the >TSC (system clock) value whenever the RX path and TX queue path fires? > >See if it's scheduling things to the hardware quickly or not. It may >be something really silly like context switching between the RX and TX >threads of the driver. > > > >-adrian > > >On 28 June 2016 at 19:05, Cesar <caesargo@163.com> wrote: >> Dear Adrian Chadd, >> >> Thanks for your reply. It's correct that USB may introduce some delays, but >> in our experiment we use mini-pcie devices indeed... >> >> Cesar >> >> >> >> >> >> >> >> At 2016-06-29 04:05:32, "Adrian Chadd" <adrian@freebsd.org> wrote: >>>Hi, >>> >>>can you try this using pci/pcie devices instead of USB? There may be >>>USB scheduling things in the way. >>> >>>On 27 June 2016 at 20:55, Cesar <caesargo@163.com> wrote: >>>> Hello all, >>>> We?ve recently tried to test packet injection performace in ath9k monitor >>>> mode. We set 2 laptops in monitor mode , PC 1 send a 500 Byte packets >>>> out, >>>> and PC 2 return a 500 Bytes packet back at once when it receives the >>>> packet >>>> of PC 1. Then we measured the RTT time and found it's about 1000us !!! >>>> >>>> Test environment: >>>> NIC: AR9287 >>>> driver: ath9k >>>> system: ubuntu 14.04 with kernel 3.14.57 >>>> send rate : at a fixed rate 54Mb >>>> >>>> >>>> We tried to send packets as "low" as possible in driver stack, and we're >>>> sure that we disabled the CCA and backoff using flags below: >>>> >>>> AR_DIAG_FORCE_CH_IDLE_HIGH >>>> AR_DIAG_IGNORE_VIRT_CS >>>> AR_D_GBL_IFS_MISC_IGNORE_BACKOFF >>>> >>>> besides we change the aifs to 1 and cwmin cwmax to 0 in ath_txq_setup to >>>> ensure there's no backoff. we even put our laptaps to a underground >>>> garage >>>> where channel is almost clean.But the test results is still about >>>> 1000us.... >>>> >>>> We've been stucked for serveral months, Any suggestion? >>>> Any feedback welcome... >>>> Thnkz in advance!!! >>>> >>>> Cesar >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> ath9k-devel mailing list >>>> ath9k-devel at lists.ath9k.org >>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160705/3a414bf6/attachment.htm ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] ath9k monitor mode injection packet delay 2016-07-05 11:24 ` Cesar @ 2016-07-06 15:18 ` Adrian Chadd 0 siblings, 0 replies; 6+ messages in thread From: Adrian Chadd @ 2016-07-06 15:18 UTC (permalink / raw) To: ath9k-devel Can you post a trace showing the incoming packet, transmitting packet, transmitting complete packet? -adrian On 5 July 2016 at 04:24, Cesar <caesargo@163.com> wrote: > Dear Adrian Chadd, > > Thanks for your suggestion... > After that we did some experiments following your suggestion. We enable > ath9k debug mode, the log shows the tx delay is about 150us. > > [ 1865.064485] ath: phy4: transmitting packet, skb: f32ecd80 > [ 1865.064505] ath: phy4: qnum: 1, txq depth: 0 > [ 1865.064512] ath: phy4: TXDP[1] = 32ec0000 (f2ec0000) > [ 1865.064516] ath: phy4: Enable TXE on queue: 1 > [ 1865.064561] ath: phy4: tx queue 1 (32ec0000), link f2ec0000 > [ 1865.064615] ath: phy4: tx queue 1 (32ec0000), link f2ec0000 > [ 1865.064622] ath: phy4: TX complete: skb: f32ecd80 > > Considering that the printk() may introduce some delay, so we use > trace_printk() at the same place then disable the debug mode, the result > didn't change much. > And we measured the rx delay use trace_printk() too, from the rx_tasklet to > the upper layer the delay is about 50us. > > So in theory the RTT should be (150+50) *2 = 400 us.. But the total > turn-around delay is still 1000us... We don't know where the delay could > happen, maybe the packet does not truly send out when it displays "TX > complete"? Or packet could not enter ath_isr at at the first time when > packet arrived? > > Any other suggestions? > Thanks > > Cesar > > > > > > At 2016-06-29 10:46:18, "Adrian Chadd" <adrian@freebsd.org> wrote: >>hi! >> >>ok. 1ms is a long amount of time. Maybe use the tracing feature in >>ath9k and/or add some debugging in the RX and TX paths that log the >>TSC (system clock) value whenever the RX path and TX queue path fires? >> >>See if it's scheduling things to the hardware quickly or not. It may >>be something really silly like context switching between the RX and TX >>threads of the driver. >> >> >> >>-adrian >> >> >>On 28 June 2016 at 19:05, Cesar <caesargo@163.com> wrote: >>> Dear Adrian Chadd, >>> >>> Thanks for your reply. It's correct that USB may introduce some delays, >>> but >>> in our experiment we use mini-pcie devices indeed... >>> >>> Cesar >>> >>> >>> >>> >>> >>> >>> >>> At 2016-06-29 04:05:32, "Adrian Chadd" <adrian@freebsd.org> wrote: >>>>Hi, >>>> >>>>can you try this using pci/pcie devices instead of USB? There may be >>>>USB scheduling things in the way. >>>> >>>>On 27 June 2016 at 20:55, Cesar <caesargo@163.com> wrote: >>>>> Hello all, >>>>> We?ve recently tried to test packet injection performace in ath9k >>>>> monitor >>>>> mode. We set 2 laptops in monitor mode , PC 1 send a 500 Byte packets >>>>> out, >>>>> and PC 2 return a 500 Bytes packet back at once when it receives the >>>>> packet >>>>> of PC 1. Then we measured the RTT time and found it's about 1000us !!! >>>>> >>>>> Test environment: >>>>> NIC: AR9287 >>>>> driver: ath9k >>>>> system: ubuntu 14.04 with kernel 3.14.57 >>>>> send rate : at a fixed rate 54Mb >>>>> >>>>> >>>>> We tried to send packets as "low" as possible in driver stack, and >>>>> we're >>>>> sure that we disabled the CCA and backoff using flags below: >>>>> >>>>> AR_DIAG_FORCE_CH_IDLE_HIGH >>>>> AR_DIAG_IGNORE_VIRT_CS >>>>> AR_D_GBL_IFS_MISC_IGNORE_BACKOFF >>>>> >>>>> besides we change the aifs to 1 and cwmin cwmax to 0 in ath_txq_setup >>>>> to >>>>> ensure there's no backoff. we even put our laptaps to a underground >>>>> garage >>>>> where channel is almost clean.But the test results is still about >>>>> 1000us.... >>>>> >>>>> We've been stucked for serveral months, Any suggestion? >>>>> Any feedback welcome... >>>>> Thnkz in advance!!! >>>>> >>>>> Cesar >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> ath9k-devel mailing list >>>>> ath9k-devel at lists.ath9k.org >>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>>> >>> >>> >>> >>> > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-07-06 15:18 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-28 3:55 [ath9k-devel] ath9k monitor mode injection packet delay Cesar 2016-06-28 20:05 ` Adrian Chadd 2016-06-29 2:05 ` Cesar 2016-06-29 2:46 ` Adrian Chadd 2016-07-05 11:24 ` Cesar 2016-07-06 15:18 ` Adrian Chadd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).