On 05/16/2012 12:46 AM, Eric Dumazet wrote:
On Wed, 2012-05-16 at 00:20 -0700, Dave Taht wrote:
With ecn:
64 bytes from 149.20.63.18: icmp_req=46 ttl=64 time=10.6 ms
64 bytes from 149.20.63.18: icmp_req=47 ttl=64 time=5.66 ms
64 bytes from 149.20.63.18: icmp_req=48 ttl=64 time=11.8 ms
64 bytes from 149.20.63.18: icmp_req=49 ttl=64 time=3.68 ms
64 bytes from 149.20.63.18: icmp_req=50 ttl=64 time=10.2 ms
64 bytes from 149.20.63.18: icmp_req=51 ttl=64 time=12.8 ms
64 bytes from 149.20.63.18: icmp_req=52 ttl=64 time=2.62 ms
64 bytes from 149.20.63.18: icmp_req=53 ttl=64 time=7.86 ms
TCP_RR: 102
All of these sets of results need more rigor attached.
On TCP_RR pure workload, you have one packet in flight per flow.
ECN adds nothing in this case, only that no 'drops' occurs at all.
It might be good to change fq_codel to perform ECN mark only if flow
queue has more packets.
If not, plain drop.
I like netperf as much as anyone :) but keep in mind that the TCP_RR
test has only one segment outstanding at a time only when the
request/response size is < MSS and/or one has not enabled burst mode to
have multiple transactions in flight at one time.
Are we really likely to see a situation where all the flows are one
packet at a time? If all the flows are either that way naturally, or
have gotten there thanks to a one segment cwnd are we not already in a
very pathological situation?
For the impossible to define "fair" question, is it fair to drop a
flow's only packet if there are other, multiple-packet flows around?
rick jones
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
