On Thu, Apr 6, 2017 at 8:58 AM, Toke Høiland-Jørgensen <toke@xxxxxxx> wrote:
> Eric Dumazet <eric.dumazet@xxxxxxxxx> writes:
>
>> On Thu, 2017-04-06 at 11:38 +0200, Toke Høiland-Jørgensen wrote:
>>
>>> +
>>> + if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
>>> + sta->cparams.target = MS2TIME(50);
>>> + sta->cparams.interval = MS2TIME(300);
>>> + sta->cparams.ecn = false;
>>> + } else {
>>> + sta->cparams.target = MS2TIME(20);
>>> + sta->cparams.interval = MS2TIME(100);
>>> + sta->cparams.ecn = true;
>>> + }
>>> +}
>>
>> Why ECN is flipped on/off like that ?
>
> The reasoning is that at really low bandwidths we're better off dropping
> the packet and getting potentially latency-sensitive data queued behind
> it through (see Dave's various rants with the topic "Packets have
> mass").
My general take on wifi is that if you are running at - particularly,
stuck at - a low rate (sub 6mbits in the case of this code) - you have
so many other problems like retransmits, interference, etc, in the
first place, that the presence or absence of codel here is just a
small contributor to that noise.
We could leave ecn at whatever it is set to here and not flip it on or
off. It does seem sane to twiddle the parameters enough to make sure
codel doesn't trigger at less than a MTU vs the achieved rate.
>> ECN really should be an admin choice.
>
> Well, the trouble is that the mac80211 queues don't really have an admin
> interface currently. So it'll always use ECN (before this change).
Should we add a sysfs api to this?
>> Also, this change in parameters looks suspect to me, adding a bimodal
>> behavior. I would consult Kathleen and Van on this possibility.
It's sort of trimodal, actually. I think a more effective approach
would be codel's default were the normal 5% of 100ms, bumping it up
(as per the above) when we're having bad connectivity.... and we tried
to tackle excessive retransmits harder, and addressed the side
impacts of multicast, instead, as much bigger parts of the problem.
> Yeah, I agree that it's somewhat of a hack from a theoretical point of
> view. I've also been experimenting with Kathy's recommended way of
> dealing with bursty MACs (turning off CoDel when there's less than an
> MTU's worth of data left), but have not had a lot of success with it.
I'm not in a position to resume trying myself.
> Guess I can go back and try some variants on that, unless someone else
> has better ideas?
Just as stuck as you are!
>
> -Toke
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@xxxxxxxxxxxxxxxxxxxxx
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
