On Fri, 7 Dec 2007, David Miller wrote:
> From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> Date: Fri, 7 Dec 2007 15:05:59 +0200 (EET)
>
> > On Fri, 7 Dec 2007, David Miller wrote:
> >
> > > From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> > > Date: Fri, 7 Dec 2007 13:05:46 +0200 (EET)
> > >
> > > > I gue
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 7 Dec 2007 15:05:59 +0200 (EET)
> On Fri, 7 Dec 2007, David Miller wrote:
>
> > From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> > Date: Fri, 7 Dec 2007 13:05:46 +0200 (EET)
> >
> > > I guess if you get a large cumulative ACK, the amount of process
On Fri, 7 Dec 2007, Ilpo Järvinen wrote:
> On Fri, 7 Dec 2007, David Miller wrote:
>
> > From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> > Date: Fri, 7 Dec 2007 13:05:46 +0200 (EET)
> >
> > > I guess if you get a large cumulative ACK, the amount of processing is
> > > still overwhelming (added Dave
On Fri, 7 Dec 2007, David Miller wrote:
> From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> Date: Fri, 7 Dec 2007 13:05:46 +0200 (EET)
>
> > I guess if you get a large cumulative ACK, the amount of processing is
> > still overwhelming (added DaveM if he has some idea how to combat it).
> >
> > Even a
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 7 Dec 2007 13:05:46 +0200 (EET)
> I guess if you get a large cumulative ACK, the amount of processing is
> still overwhelming (added DaveM if he has some idea how to combat it).
>
> Even a simple scenario (this isn't anything fancy at all, wil
On Thu, 6 Dec 2007, Lachlan Andrew wrote:
> On 04/12/2007, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> > On Mon, 3 Dec 2007, Lachlan Andrew wrote:
> > >
> > > When SACK is active, the per-packet processing becomes more involved,
> > > tracking the list of lost/SACKed packets. This causes a CPU spik
Greetings Ilpo,
On 04/12/2007, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Dec 2007, Lachlan Andrew wrote:
> >
> > When SACK is active, the per-packet processing becomes more involved,
> > tracking the list of lost/SACKed packets. This causes a CPU spike
> > just after a loss, which incr
On Mon, 3 Dec 2007, Lachlan Andrew wrote:
> On 03/12/2007, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > On Mon, 3 Dec 2007 15:59:23 -0800
> > "Shao Liu" <[EMAIL PROTECTED]> wrote:
> > > And also a question, why the samples when SACK is active are outliers?
> >
> > Any sample with SACK is going
Greetings,
On 03/12/2007, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Dec 2007 15:59:23 -0800
> "Shao Liu" <[EMAIL PROTECTED]> wrote:
> > And also a question, why the samples when SACK is active are outliers?
>
> Any sample with SACK is going to mean a loss or reordering has occurred.
On Mon, 3 Dec 2007 15:59:23 -0800
"Shao Liu" <[EMAIL PROTECTED]> wrote:
> Hi Stephen and Lachlan,
>
> Thanks for the discussion. The gradual aging is surely an option. And
> another possibility is that, we compute the RTT just before congestion
> notification, which ideally, represent the full qu
!
-Shao
-Original Message-
From: Lachlan Andrew [mailto:[EMAIL PROTECTED]
Sent: Monday, December 03, 2007 3:06 PM
To: Stephen Hemminger
Cc: [EMAIL PROTECTED]; David S. Miller; Herbert Xu; Douglas Leith;
Robert Shorten; netdev@vger.kernel.org
Subject: Re: [RFC] TCP illinois max rtt aging
Greetings Stephen,
Thanks. We'll have to play with the rate of ageing. I used the slower ageing
if (ca->cnt_rtt > 3) {
u64 mean_rtt = ca->sum_rtt;
do_div (mean_rtt, ca->cnt_rtt);
if (ca->max_rtt > mean_rtt)
ca->max
12 matches
Mail list logo
