On 05/06/2016 05:54 PM, Dave Taht wrote:
On Fri, May 6, 2016 at 4:00 PM, Ben Greear <[email protected]> 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 <[email protected]> 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Lede-dev mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/lede-dev
