high RTT in 40 MHz channel width

[Iñaki Pascual]

Hi Ben,

thanks for your comments. Please see my in-line answers in your email below.

Best regards,

Iñaki

On 30/04/16 18:50, Ben Greear wrote:
> Since UDP seems to mostly not be effected, maybe it has something
> to do with your tcp stack and/or congestion control?
Yes, we agree the problem is TCP-related so we have performed some tests 
(described below) using hping3 TCP
>
> You could sniff on the wlan0 interface, as well as on-air, and compare 
> timestamps
> to see if the firmware is being slow about putting the TCP frames on the
> air?
>
we did as you say and the results are
TCP hping request on-air timeStamp:             15:11:19,194250000
TCP hping request on-interface timeStamp:   15:11:19,194253000
TCP hping reply on-interface timeStamp:       15:11:19,194280000
TCP hping reply on-air timeStamp:                 15:11:19,197582000

So it looks like the firmware takes 3.3 ms to process/send the reply 
frame. This number is in line with the aprox. 7.7 ms RTT we are 
measuring (3,3 ms *2 + aprox 1 ms delay)
We repeated the experiment with other machines and channels and the 
results are consistent.

> What TCP congestion control are you using?
>
reno
> And also, if there is any interference on the secondary channels, the 
> NIC will hold
> off transmitting.  So, you would not even see retransmits in this case.
>
for these tests, in order to to avoid interferences, we put down all 
other wireless interfaces and equipments in our testbed
> Have you tried in regular managed mode (AP/STA) to see if it is the 
> same with CT firmware?
>
we tried this test, but we were not able to configure the client with BW 
40MHz nor 20MHz, only 80MHz. The average measured RTT for 80 MHz was 3.5 
ms, same as ad-hoc mode.
> You could try stock firmware in AP/STA mode.  If CT firmware shows
> a regression, I will be happy to look at it.
we tried with an Ubuntu 14.04 fresh install, kernel and firmware are:
driver: ath10k_pci
version: 4.2.0-34-generic
firmware-version: 1.0.0.636
we run the test in ad-hoc mode, we could not configure BW 80 MHz (not 
supported)
results:
40MHz
round-trip min/avg/max = 0.5/2.8/5.5 ms
20MHz
round-trip min/avg/max = 0.4/2.5/4.4 ms
> Finally, you might try the latest CT firmware in case it acts better.  I
> ripped out some queue control in the non-full builds somewhat recently,
> and possibly that would decrease latency.
>
we tried with
firmware-version: 10.1.467-ct-_fH-016-b797ef5
results show almost same RTT values

> Thanks,
> Ben
>
>
> On 04/30/2016 09:39 AM, Jose Núñez-Martínez (CTTC) wrote:
>> Hi all,
>> just to clarify, results are ms. And stations are in IBSS mode.
>>
>> BW 20 MHz: TCP 0.9ms UDP 1.1ms
>> BW 40 MHz: TCP 7.7ms UDP 1.3ms
>> BW 80 MHz: TCP 3.5ms UDP 1.3ms
>>
>> Behavior with 40MHz and 80MHz channel bandwidth is really weird 
>> taking into account there are no retransmissions. Anyone facing this 
>> kind of problem?
>>
>> Thanks,
>> Jose
>>
>> On 04/29/2016 07:12 PM, Iñaki Pascual wrote:
>>> Hi,
>>>
>>> I am measuring TCP and UDP latency (actually RTT) and I am getting 
>>> too high values when working with channels with 40MHz (also with 
>>> 80MHz) width.
>>>
>>> I am using hping3 for testing and these are the RTT avg values:
>>>
>>> BW 20 MHz: TCP 0.9 UDP 1.1
>>> BW 40 MHz: TCP 7.7 UDP 1.3
>>> BW 80 MHz: TCP 3.5 UDP 1.3
>>>
>>> I have tried different channels with similar results. According 
>>> hping there are no packet loss and with wireshark I don't see any 
>>> retransmission.
>>>
>>> I am using:
>>> driver: ath10k_pci
>>> version: 4.2.0+
>>> firmware-version: 10.1.467-ct-com-full-014-96d543
>>>
>>> Any ideas?
>>>
>>> Bests,
>>>
>>> Iñaki
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>