[Bloat] Bufferbloat related patches for the iwl3945

Dave Täht d at taht.net
Sun Feb 13 12:22:27 PST 2011


Nathaniel Smith beat me to posting patches this weekend. [1]

See:

http://thread.gmane.org/gmane.linux.kernel.wireless.general/64733

For details.

Perhaps this will spark some discussion here and elsewhere.

Nathaniel Smith writes:

> Thanks for the poke. I just sent the patches.
> I guess we'll see if anyone responds this time.
>
> I actually suspect that the approach I use in the patch is wrong in
> the long run, because it needs that magic constant ("2 ms"), and even
> then it can't properly take into account task switching latency (if it
> takes >2 ms to get back to the driver, then the queue may drain and we
> may lose some throughput, but who knows whether that's the case or
> not). What would be better would be some way to detect the case where:
> -- there were packets waiting at the next level up -- that would have
> been queued, except that the driver decided that it had enough packets
> queued already -- and then the driver's queue underflowed If we had
> this information, then the driver could do a better job of tuning; it
> already can measure excess buffer capacity, and then it'd be able to
> measure insufficient capacity directly, and adjust its buffer size
> accordingly.

I think that is a good start.

>
> If the network layer just had a counter that it incremented every time
> its queue transitioned from empty to non-empty or vice-versa, then we
> could detect the above situation as: the driver's queue is empty,
> incoming packets are choked, and the counter is odd and has the same
> value as it did when we last accepted a packet. But it doesn't have
> that counter, and I didn't feel inspired to try and get changes
> accepted to the generic networking code.
>
> I think I'd better work on my thesis instead of getting involved in
> the bufferbloat list ;-), and similarly am unlikely to follow up much
> on the ideas above, but feel free to forward to anyone who might be
> interested (or to the list in general).
>
> Cheers,
> -- Nathaniel

-- 
Dave Taht
http://nex-6.taht.net

1: In the future I will keep code related stuff on the bloat-devel list


More information about the Bloat mailing list