From: Bill Fink <[EMAIL PROTECTED]>
Date: Tue, 12 Jun 2007 23:38:14 -0400
> If there was a benefit, perhaps it would be useful to have a
> per-route option for setting the initial_ssthresh.
We have this per-route setting already, BIC and CUBIC just override it
with their local initial_ssthresh va
On Tue, 12 Jun 2007, Stephen Hemminger wrote:
> On Tue, 12 Jun 2007 15:12:58 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Bill Fink <[EMAIL PROTECTED]>
> > Date: Wed, 16 May 2007 02:44:09 -0400
> >
> > > [EMAIL PROTECTED] ~]# netstat -s | grep -i retrans
> > > 25446 segm
On Tue, 12 Jun 2007 15:12:58 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Bill Fink <[EMAIL PROTECTED]>
> Date: Wed, 16 May 2007 02:44:09 -0400
>
> > [EMAIL PROTECTED] ~]# netstat -s | grep -i retrans
> > 25446 segments retransmited
> > 20936 fast retransmits
> > 4503 r
From: Bill Fink <[EMAIL PROTECTED]>
Date: Wed, 16 May 2007 02:44:09 -0400
> [EMAIL PROTECTED] ~]# netstat -s | grep -i retrans
> 25446 segments retransmited
> 20936 fast retransmits
> 4503 retransmits in slow start
> 4 sack retransmits failed
>
> It then only took 2.14 seconds to
gt; >
> > P.S. When getting into the the 10 Gbps range, I'm not sure there's
> > any way to avoid the types of large increases during "slow start"
> > that you mention, if you want to achieve those kinds of data
> > ra
minger" <[EMAIL PROTECTED]>
> To: "David Miller" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
>
> Sent: Thursday, May 10, 2007 4:45 PM
> Subject: Re: 2.6.20.7 TCP cubic (and bic) initial slow start way
OTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
>
> Sent: Thursday, May 10, 2007 4:45 PM
> Subject: Re: 2.6.20.7 TCP cubic (and bic) initial slow start way too slow?
>
>
> > On Thu, 10 May 2007 13:35:22 -0700 (PDT)
inger" <[EMAIL PROTECTED]>
To: "David Miller" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
Sent: Thursday, May 10, 2007 4:45 PM
Subject: Re: 2.6.20.7 TCP cubic (and bic) initial slow start way too slow?
On
On Thu, 10 May 2007 13:35:22 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: [EMAIL PROTECTED]
> Date: Thu, 10 May 2007 14:39:25 -0400 (EDT)
>
> >
> > Bill,
> > Could you test with the lastest version of CUBIC? this is not the latest
> > version of it you tested.
>
> Rhee-sangsang-n
From: [EMAIL PROTECTED]
Date: Thu, 10 May 2007 14:39:25 -0400 (EDT)
>
> Bill,
> Could you test with the lastest version of CUBIC? this is not the latest
> version of it you tested.
Rhee-sangsang-nim, it might be a lot easier for people if you provide
a patch against the current tree for users to
Bill,
Could you test with the lastest version of CUBIC? this is not the latest
version of it you tested.
Injong
> As a followup, I ran a somewhat interesting test. I increased the
> requested socket buffer size to 100 MB, which is sufficient to
> overstress the capabilities of the netem delay em
Hi Bill,
Thank you for your good work!
As you mentioned that we've been considering the problems of less
aggressiveness of BIC and CUBIC. We are testing BIC and CUBIC for as
many bottleneck bandwidths (from 1MB - 1GB) and possibly up to 10GB
capacity.
One of the reasons we clamp the "slow start"
As a followup, I ran a somewhat interesting test. I increased the
requested socket buffer size to 100 MB, which is sufficient to
overstress the capabilities of the netem delay emulator (which can
handle up to about 8.5 Gbps). This causes some packet loss when
using the standard Reno agressive "sl
Hi Sangtae,
On Tue, 8 May 2007, SANGTAE HA wrote:
> Hi Bill,
>
> At this time, BIC and CUBIC use a less aggressive slow start than
> other protocols. Because we observed "slow start" is somewhat
> aggressive and introduced a lot of packet losses. This may be changed
> to standard "slow start" in
Hi Bill,
At this time, BIC and CUBIC use a less aggressive slow start than
other protocols. Because we observed "slow start" is somewhat
aggressive and introduced a lot of packet losses. This may be changed
to standard "slow start" in later version of BIC and CUBIC, but, at
this time, we still us
The initial TCP slow start on 2.6.20.7 cubic (and to a lesser
extent bic) seems to be way too slow. With an ~80 ms RTT, this
is what cubic delivers (thirty second test with one second interval
reporting and specifying a socket buffer size of 60 MB):
[EMAIL PROTECTED] ~]# netstat -s | grep -i retr
16 matches
Mail list logo
