Re: [Bloat] GSO

[Jesper Dangaard Brouer <jdb@comx.dk>]

On Sat, 2011-02-26 at 03:41 +0100, Dave Täht wrote:
> Jesper Dangaard Brouer <hawk@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.


--
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