this really, really, really is the wrong list for this dialog. cc-ing codel
On Mon, Jul 8, 2013 at 11:04 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Mon, 8 Jul 2013, Toke Høiland-Jørgensen wrote:
Did a few test runs on my setup. Here are some figures (can't go higher
than 100mbit with
On Tue, 2013-07-09 at 09:57 +0200, Toke Høiland-Jørgensen wrote:
Mikael Abrahamsson swm...@swm.pp.se writes:
For me, it shows that FQ_CODEL indeed affects TCP performance
negatively for long links, however it looks like the impact is only
about 20-30%.
As far as I can tell, fq_codel's
Eric Dumazet eric.duma...@gmail.com writes:
What do you mean ? This makes little sense to me.
The data from my previous post
(http://archive.tohojo.dk/bufferbloat-data/long-rtt/throughput.txt)
shows fq_codel achieving higher aggregate throughput in some cases than
pfifo_fast does.
I did not
Eric Dumazet eric.duma...@gmail.com writes:
Its really too basic for my needs.
It decides to put the new packet at the front of transmit queue.
Right I see.
If you use netem to add a delay, then adding reordering is only a
matter of using a variable/randomized delay.
Yeah, realised that;
On Tue, 2013-07-09 at 15:13 +0200, Toke Høiland-Jørgensen wrote:
Eric Dumazet eric.duma...@gmail.com writes:
What do you mean ? This makes little sense to me.
The data from my previous post
(http://archive.tohojo.dk/bufferbloat-data/long-rtt/throughput.txt)
shows fq_codel achieving
Eric Dumazet eric.duma...@gmail.com writes:
OK, thats a total of 200 ms RTT. Its a pretty high value :(
Yeah, that was the point; Mikael requested such a test be run, and I
happened to be near my lab setup yesterday, so thought I'd run it.
Could you send tc -s qdisc taken at netem box ?
Not
Eric Dumazet eric.duma...@gmail.com writes:
It would be nice it the rrul results could include a nstat snapshot
nstat /dev/null ; rrul_tests ; nstat
Sure, can do. Is that from the client machine or the netem box?
-Toke
signature.asc
Description: PGP signature
