Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <hawk@comx.dk>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: bloat-devel@lists.bufferbloat.net, herbert@gondor.apana.org.au,
	Van Jacobson <van@parc.com>,
	shalunov@shlang.com, bloat@lists.bufferbloat.net
Subject: Re: GSO (was: Please enter issues into the issue tracker - Issue system organisation needed)
Date: Fri, 25 Feb 2011 18:15:04 +0100	[thread overview]
Message-ID: <1298654104.28000.52.camel@traveldev.cxnet.dk> (raw)
In-Reply-To: <1298651627.2659.84.camel@edumazet-laptop>

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 :
> 
> > Yes, both servers (/proc/sys/net/ipv4/tcp_sack = 1).
> > 
> > I think that the bufferbloat theory is that SACKs will not work, due to
> > the long delays introduced by buffers(bloat).   In this case, you can
> > see on the graph, a max RTT around 150 ms and an average of 20 ms.  
> > 
> > While another, more well behaved path in the network to the speed
> > server, I would only see a max RTT around 25 ms and an average of 15 ms,
> > see:
> > http://people.netfilter.org/hawk/dropbox/bloat_vs_GSO/speed-to-pc314a-1.png
> > 
> > You can also see this path had an ave of 90Mbit/s, but with significant
> > throughput drops (the 92Mbit/s line is an artificial line on the graph).
> > This behavior is probaly caused by the GSO effect.
> > 
> > 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! :-)

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



  reply	other threads:[~2011-02-25 17:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-24 14:19 Please enter issues into the issue tracker - Issue system organisation needed Jim Gettys
2011-02-24 15:00 ` [Bloat] " Fred Baker
2011-02-24 16:32   ` Jim Gettys
2011-02-24 17:08     ` Eric Dumazet
2011-02-24 18:31       ` Dave Täht
2011-02-24 19:29         ` Eric Dumazet
2011-02-25 11:21           ` GSO (was: Please enter issues into the issue tracker - Issue system organisation needed) Jesper Dangaard Brouer
2011-02-25 11:54             ` Eric Dumazet
2011-02-25 15:48               ` Jesper Dangaard Brouer
2011-02-25 16:19                 ` Eric Dumazet
2011-02-25 16:33                 ` Eric Dumazet
2011-02-25 17:15                   ` Jesper Dangaard Brouer [this message]
2011-02-26  2:41                     ` GSO Dave Täht
2011-03-02  8:30                       ` GSO Jesper Dangaard Brouer
2011-03-04  2:23                         ` GSO Dave Täht
2011-02-24 23:15         ` debloat-testing: Kitten not eaten - was Re: [Bloat] Please enter issues into the issue tracker - Issue system organisation needed Jim Gettys
2011-02-24 23:18           ` Dave Täht
2011-02-24 23:31             ` Jim Gettys
2011-02-25 15:40         ` John W. Linville

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1298654104.28000.52.camel@traveldev.cxnet.dk \
    --to=hawk@comx.dk \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=bloat@lists.bufferbloat.net \
    --cc=eric.dumazet@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=shalunov@shlang.com \
    --cc=van@parc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox