GSO

[Dave Täht]

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
>> > 
>> > 
>> 
>> Its a bit hard to interpret these graphs, I am a bit lost...
>> What exactly is sampled ? Is it from tcpdump analysis or output from
>> HTB/SFQ stats ?
>
> 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. 

My assumption is that both systems are running stock (100HZ) kernels?

What would a 1ms clock do on these plots? And/or the Linux-rt patch? 

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