[Bloat] GSO

[Dave Täht]

Jesper Dangaard Brouer <jdb at comx.dk> writes:

> On Sat, 2011-02-26 at 03:41 +0100, Dave Täht wrote:
>> Jesper Dangaard Brouer <hawk at comx.dk> writes:
>> > On Fri, 2011-02-25 at 17:33 +0100, Eric Dumazet wrote:
>> >> Le vendredi 25 février 2011 à 16:48 +0100, Jesper Dangaard Brouer a
>> >> écrit :
>> >>
>> >> > Disabling GSO on speed server fixed the problem as can be seen on graph:
>> >> > http://people.netfilter.org/hawk/dropbox/bloat_vs_GSO/speed-to-grantoften-solved.png
>> >> >
>> >> > The really strange part when troubleshooting this issue was that the
>> >> > throughput as fine between the two customer end-boxes ("grantoften" and
>> >> > "pc314a") as can be see here:
>> >> > http://people.netfilter.org/hawk/dropbox/bloat_vs_GSO/pc314a-to-grantoften-1.png
>> >> >
> ...
>> > The graph is generated (with GNUplot) with data from the
>> > throughput-latency tool called "thrulay".  Its created by Stanislav
>> > Shalunov, and its homepage is here: http://shlang.com/thrulay/
>> >
>> > I really love this "thrulay" tool, as it measure both the throughput and
>> > records the TCP sessions experienced delay.  And the output can be used
>> > directly by GNUplot. Nice! :-)
>> 
>> I find the 10ms granularity on both graphs rather interesting. One of my
>> issues with HTB (when last I checked) is that it does odd things across
>> the clock interval.
>
> This case/graphs have nothing to do with the HTB qdisc.  The traffic is
> not affected by the HTB shaper (on the path) as the customer actually
> have a 110Mbit/s bandwidth limit (as we always give customers 10% extra
> to avoid any complaints about overhead).
>
> If I change the customers bandwidth to 90 Mbit/s or 93 Mbit/s, which
> makes the HTB shaper (+the SFQ scheduler) have effect, then the customer
> experience is perfect, as I have solved the bufferbloat issue.  The
> problem is of cause that marketing want to sell 100Mbit/s, not 90Mbit/s
> or 93Mbit/s. Thus, I cannot really implement the fix :-(.
>
> But, you memory is not totally faulted regrading HTB ;-)
> HTB used to be affected by the HZ clock interval, but I think Stephen
> Hemminger fixed that by using the highres timer API.  And I fixed the
> "no_hyst" case where HTB could introduce spikes of three times the
> expected delay.

So, thank you both for the HTB fixes (belatedly). There is at least one
academic paper I've read fairly recently that is now thoroughly
obsoleted by events.

That said, I conflated two things in my question. The first was the old
HTB problem. 

The second was that your data has strong signals at exactly 10 and 20ms,
which implies your tool or your kernel - or something else - is not
using high res timers... ?

>
>
> --
> Med venlig hilsen / Best regards
>   Jesper Brouer
>   ComX Networks A/S
>   Linux Network Kernel Developer
>   Cand. Scient Datalog / MSc.CS
>   Author of http://adsl-optimizer.dk
>   LinkedIn: http://www.linkedin.com/in/brouer
>
>

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