[ath9k-devel] ath9k monitor mode injection packet delay

[ath9k-devel] ath9k monitor mode injection packet delay

[Cesar]

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 

[ath9k-devel] ath9k monitor mode injection packet delay

[Adrian Chadd]

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
>

[ath9k-devel] ath9k monitor mode injection packet delay

[Cesar]

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 

[ath9k-devel] ath9k monitor mode injection packet delay

[Adrian Chadd]

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
>>>
>
>
>
>

[ath9k-devel] ath9k monitor mode injection packet delay

[Cesar]

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 

[ath9k-devel] ath9k monitor mode injection packet delay

[Adrian Chadd]

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
>>>>>
>>>
>>>
>>>
>>>
>
>
>
>