[ath9k-devel] ath9k monitor mode injection packet delay

Can you post a trace showing the incoming packet, transmitting packet,
transmitting complete packet?


-adrian


On 5 July 2016 at 04:24, Cesar <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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
>>>>>
>>>
>>>
>>>
>>>
>
>
>
>