[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110309220342.GA3719@xanadu.blop.info>
Date: Wed, 9 Mar 2011 23:03:42 +0100
From: Lucas Nussbaum <lucas.nussbaum@...ia.fr>
To: Stephen Hemminger <shemminger@...tta.com>
Cc: Yuchung Cheng <ycheng@...gle.com>, Injong Rhee <rhee@...u.edu>,
David Miller <davem@...emloft.net>, xiyou.wangcong@...il.com,
netdev@...r.kernel.org, sangtae.ha@...il.com
Subject: Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
On 09/03/11 at 13:51 -0800, Stephen Hemminger wrote:
> On Wed, 9 Mar 2011 22:33:56 +0100
> Lucas Nussbaum <lucas.nussbaum@...ia.fr> wrote:
>
> > On 09/03/11 at 13:12 -0800, Yuchung Cheng wrote:
> > > On Wed, Mar 9, 2011 at 12:01 PM, Stephen Hemminger
> > > <shemminger@...tta.com> wrote:
> > > > On Wed, 9 Mar 2011 19:25:05 +0100
> > > > Lucas Nussbaum <lucas.nussbaum@...ia.fr> wrote:
> > > >
> > > >> On 09/03/11 at 09:56 -0800, Stephen Hemminger wrote:
> > > >> > On Wed, 9 Mar 2011 07:53:19 +0100
> > > >> > Lucas Nussbaum <lucas.nussbaum@...ia.fr> wrote:
> > > >> >
> > > >> > > On 08/03/11 at 20:30 -0500, Injong Rhee wrote:
> > > >> > > > Now, both tools can be wrong. But that is not catastrophic since
> > > >> > > > congestion avoidance can kick in to save the day. In a pipe where no
> > > >> > > > other flows are competing, then exiting slow start too early can
> > > >> > > > slow things down as the window can be still too small. But that is
> > > >> > > > in fact when delays are most reliable. So those tests that say bad
> > > >> > > > performance with hystart are in fact, where hystart is supposed to
> > > >> > > > perform well.
> > > >> > >
> > > >> > > Hi,
> > > >> > >
> > > >> > > In my setup, there is no congestion at all (except the buffer bloat).
> > > >> > > Without Hystart, transferring 8 Gb of data takes 9s, with CUBIC exiting
> > > >> > > slow start at ~2000 packets.
> > > >> > > With Hystart, transferring 8 Gb of data takes 19s, with CUBIC exiting
> > > >> > > slow start at ~20 packets.
> > > >> > > I don't think that this is "hystart performing well". We could just as
> > > >> > > well remove slow start completely, and only do congestion avoidance,
> > > >> > > then.
> > > >> > >
> > > >> > > While I see the value in Hystart, it's clear that there are some flaws
> > > >> > > in the current implementation. It probably makes sense to disable
> > > >> > > hystart by default until those problems are fixed.
> > > >> >
> > > >> > What is the speed and RTT time of your network?
> > > >> > I think you maybe blaming hystart for other issues in the network.
> > > >>
> > > >> What kind of issues?
> > > >>
> > > >> Host1 is connected through a gigabit ethernet LAN to Router1
> > > >> Host2 is connected through a gigabit ethernet LAN to Router2
> > > >> Router1 and Router2 are connected through an experimentation network at
> > > >> 10 Gb/s
> > > >> RTT between Host1 and Host2 is 11.3ms.
> > > >> The network is not congested.
> > > >
> > > > By my calculations (1G * 11.3ms) gives BDP of 941 packets which means
> > > > CUBIC would ideally exit slow start at 900 or so packets. Old CUBIC
> > > > slowstrart of 2000 packets means there is huge overshoot which means
> > > > large packet loss burst which would cause a large CPU load on receiver
> > > > processing SACK.
> > > It's not clear from Lucas's report that the hystart is exiting when
> > > cwnd=2000 or when sender has sent 2000 packets.
> > > Lucas could you clarify?
> >
> > When cwnd is around 2000.
>
> What is HZ on the kernel configuration. Part of the problem is the hystart
> code was only tested with HZ=1000 and there are some bad assumptions there.
$ grep HZ /boot/config-2.6.32-5-amd64
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@...ia.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists