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 guess if you get a large
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 spike
just
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 simple
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, will occur
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 DaveM if he has some
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 processing is
still
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 increases the
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 to mean a loss
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_rtt
On Wed, 28 Nov 2007 21:26:12 -0800
Shao Liu [EMAIL PROTECTED] wrote:
Hi Stephen and Lachlan,
Thanks for pointing out and fixing this bug.
For the max RTT problem, I have considered it also and I have some idea on
improve it. I also have some other places to improve. I will summarize all
!
-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
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 queueing
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.
So
13 matches
Mail list logo
