Can you post a trace showing the incoming packet, transmitting packet, transmitting complete packet?
-adrian On 5 July 2016 at 04:24, Cesar <caesa...@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" <adr...@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 <caesa...@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" <adr...@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 <caesa...@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@lists.ath9k.org >>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>>> >>> >>> >>> >>> > > > > _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
