[ath9k-devel] ath9k monitor mode injection packet delay

[Cesar <caesargo@163.com>]

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