[LEDE-DEV] RFC: Throughput testing results.

[Ben Greear]

On 05/06/2016 05:54 PM, Dave Taht wrote:
> On Fri, May 6, 2016 at 4:00 PM, Ben Greear <greearb at candelatech.com> wrote:
>> On 05/06/2016 12:05 PM, David Lang wrote:
>>>
>>> On Fri, 6 May 2016, Ben Greear wrote:
>>>
>>>> On 05/06/2016 10:20 AM, Toke Høiland-Jørgensen wrote:
>>>>>
>>>>> Ben Greear <greearb at candelatech.com> writes:
>>>>>
>>>>>> I am interested in feedback on the testing output. My goal is to add a
>>>>>> few more different hardware configurations and then do nightly (or at
>>>>>> least weekly) tests.
>>>>>
>>>>>
>>>>> So that is showing up to 10s of *seconds* of latency, right? (I'm not
>>>>> sure I'm reading the units right).
>>>>
>>>>
>>>> Yes, 10 seconds of latency.  My traffic generator is using pfifo-fast,
>>>> RENO, and default socket sizes, so it can be at least part of the
>>>> problem.
>>>
>>>
>>> That's so much latency that you may as well be down.
>>>
>>> Please look at the make-wifi-fast mailing list and the tests that are
>>> being done there. they show latency spikes as well as throughput, and show
>>> how it is very
>>> possible to get low latency without affecting throughput (in some cases,
>>> throughput actually increases)
>>
>>
>> I did some tcp/udp mix, tcp only, udp only download tests, with fq_codel and
>> fifo-fast on the traffic
>> generator.  AP was un-changed, seems LEDE uses fq_codel by default.
>> Generator is using 4.4.8+ kernel, and it looks
>> like fq_codel works nicely!
>
> I have *no idea* what I'm looking at here:
>
> http://www.candelatech.com/examples/ventana/ventana-tcp-codel-dl_1462569548/chart-2.png
>
> 60 stations and 4sec latency?

Each of those red squares is the one-way latency for one of the 64 tcp connections.
There are 64 virtual stations, one TCP connection per station (in the right-hand side).

The black line graph shows number of active stations, so on the left there are fewer
stations and thus fewer tcp connections.

I'm only sending one-way traffic (not counting ACKs), so no round-trip time is
reported.

The timestamps are calculated when I push the data into the socket, subtracted from
the time the data is received from the peer socket.  I am sending 64k 'TCP' packets,
so the timestamp is not on a per-packet basis, but more of how long it takes to send
64k.  I will re-run with MTU sized 'packets' next time and see if it changes much.

I ran several tests, and some looked a bit better than this, but it is not that much
of an outlier...  They are definitely better than what I saw with fifo-fast as far
as latency is concerned, however.

Thanks,
Ben

>
>> http://www.candelatech.com/examples/ventana/
>>
>> We'll run some tests on some of our higher-performing APs and see if
>> fq_codel works well there
>> too when we get a chance....
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>
>
>

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com