[Cerowrt-devel] Better results from CeroWrt 3.10.28-16

Dave Taht dave.taht at gmail.com
Sun Mar 2 21:00:10 EST 2014

it's in tc's output

qdisc nfq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 300
target 14.8ms interval 109.8ms
 Sent 122649261 bytes 332175 pkt (dropped 129389, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0.
  maxpacket 0 drop_overlimit 0 new_flow_count 37646 ecn_mark 0
  new_flows_len 1 old_flows_len 2

It's late in england. going to bed before ietf tomorrow/

(I don't have a mac anymore and never thought to do a caipture at this rate.

I think the mac is iw4, but as we have 4 uploads going we are
effectively iw16 at
rrul startup, and yet, here we are trying to cut latencies to 15ms.

what I'm interested in determining is if the mac flows are experiencing RTOs,
and/or falling back to iw2...

For way more detail on the joys of iwX at high and low bandwidths:


JG also has a rant on iw10 considered harmful. This is iw4 considered harmful
at speeds below 2mbit....

I have been trying to come up with a way to for default gws to communicate
a good iw size for a while and/or have a plot of behaviors at this speed.

On Sun, Mar 2, 2014 at 5:49 PM, Rich Brown <richb.hanover at gmail.com> wrote:
> Dave,
>> Target 30ms would be interesting. 30+ % packet loss on this test (and
>> your link is still operable!)
> Wait. How can you detect the packet loss from the data I sent along?
>> At your speed range the behavior of the tcp upload is governed by the
>> initial window size more than anything else. I doubt the
>> mac adjusts that properly so it keeps hammering away at it... my
>> concern from looking at your upload graphs was that you were
>> actually getting hammered so hard you were actually going through RTO
>> (receive timeout) on the uploads.
> Yuck. That would be bad.
> re: Wireshark. I'll try to get it soon.
> Thanks.
> Rich

Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

More information about the Cerowrt-devel mailing list