[ath9k-devel] ath9k monitor mode injection packet delay

Discussion:

Cesar

2016-06-28 03:55:14 UTC

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

Adrian Chadd

2016-06-28 20:05:32 UTC

Permalink

Hi,

can you try this using pci/pcie devices instead of USB? There may be
USB scheduling things in the way.

Post by 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 !!!
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
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
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Cesar

2016-06-29 02:05:09 UTC

Permalink

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

Post by Adrian Chadd
Hi,
can you try this using pci/pcie devices instead of USB? There may be
USB scheduling things in the way.

Post by 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 !!!
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
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
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Adrian Chadd

2016-06-29 02:46:18 UTC

Permalink

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

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

Post by Adrian Chadd
Hi,
can you try this using pci/pcie devices instead of USB? There may be
USB scheduling things in the way.

Cesar

2016-07-05 11:24:34 UTC

Permalink

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

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

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

Post by Adrian Chadd
Hi,
can you try this using pci/pcie devices instead of USB? There may be
USB scheduling things in the way.

Adrian Chadd

2016-07-06 15:18:44 UTC

Permalink

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

-adrian

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

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

Post by Adrian Chadd
Hi,
can you try this using pci/pcie devices instead of USB? There may be
USB scheduling things in the way.