ine either way.
>
> Good point. The fact that this greatly mitigates a regression in DCTCP
> performance resulting from 3759824da87b30ce7a35b4873b62b0ba38905ef5
> ("tcp: PRR uses CRB mode by default and SS mode conditionally") IMHO
> seems to be a good argument for putting this pa
rformance resulting from 3759824da87b30ce7a35b4873b62b0ba38905ef5
("tcp: PRR uses CRB mode by default and SS mode conditionally") IMHO
seems to be a good argument for putting this patch ("tcp: ack
immediately when a cwr packet arrives") in the "net" branch and stable
releases.
thanks,
neal
Note that without this fix the 99% latencies when doing 10KB RPCs in a
congested network using DCTCP are 40ms vs. 190us with the patch. Also note that
these 40ms high tail latencies started after commit
3759824da87b30ce7a35b4873b62b0ba38905ef5 in Jul 2015, which triggered the
bugs/features we a
On 07/24/2018 10:12 AM, Neal Cardwell wrote:
> On Tue, Jul 24, 2018 at 1:07 PM Yuchung Cheng wrote:
>>
>> On Mon, Jul 23, 2018 at 7:23 PM, Daniel Borkmann
>> wrote:
>>> Should this go to net tree instead where all the other fixes went?
>> I am neutral but this feels more like a feature improv
On Tue, Jul 24, 2018 at 1:07 PM Yuchung Cheng wrote:
>
> On Mon, Jul 23, 2018 at 7:23 PM, Daniel Borkmann wrote:
> > Should this go to net tree instead where all the other fixes went?
> I am neutral but this feels more like a feature improvement
I agree this feels like a feature improvement rath
On Mon, Jul 23, 2018 at 7:23 PM, Daniel Borkmann wrote:
>
> On 07/24/2018 04:15 AM, Neal Cardwell wrote:
> > On Mon, Jul 23, 2018 at 8:49 PM Lawrence Brakmo wrote:
> >>
> >> We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
> >> problem is triggered when the last packet of a
On 07/24/2018 04:15 AM, Neal Cardwell wrote:
> On Mon, Jul 23, 2018 at 8:49 PM Lawrence Brakmo wrote:
>>
>> We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
>> problem is triggered when the last packet of a request arrives CE
>> marked. The reply will carry the ECE mark caus
On Mon, Jul 23, 2018 at 8:49 PM Lawrence Brakmo wrote:
>
> We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
> problem is triggered when the last packet of a request arrives CE
> marked. The reply will carry the ECE mark causing TCP to shrink its cwnd
> to 1 (because there ar
We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
problem is triggered when the last packet of a request arrives CE
marked. The reply will carry the ECE mark causing TCP to shrink its cwnd
to 1 (because there are no packets in flight). When the 1st packet of
the next request a
We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
problem is triggered when the last packet of a request arrives CE
marked. The reply will carry the ECE mark causing TCP to shrink its cwnd
to 1 (because there are no packets in flight). When the 1st packet of
the next request a
We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
problem is triggered when the last packet of a request arrives CE
marked. The reply will carry the ECE mark causing TCP to shrink its cwnd
to 1 (because there are no packets in flight). When the 1st packet of
the next request a
On 7/2/18, 7:57 AM, "Neal Cardwell" wrote:
On Sat, Jun 30, 2018 at 9:47 PM Lawrence Brakmo wrote:
> I see two issues, one is that entering quickack mode as you
> mentioned does not insure that it will still be on when the CWR
> arrives. The second issue is that the problem occurs
On Sat, Jun 30, 2018 at 9:47 PM Lawrence Brakmo wrote:
> I see two issues, one is that entering quickack mode as you
> mentioned does not insure that it will still be on when the CWR
> arrives. The second issue is that the problem occurs right after the
> receiver sends a small reply which results
On 6/30/18, 11:23 AM, "Neal Cardwell" wrote:
On Fri, Jun 29, 2018 at 9:48 PM Lawrence Brakmo wrote:
>
> We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
> problem is triggered when the last packet of a request arrives CE
> marked. The reply will carry t
On Fri, Jun 29, 2018 at 9:48 PM Lawrence Brakmo wrote:
>
> We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
> problem is triggered when the last packet of a request arrives CE
> marked. The reply will carry the ECE mark causing TCP to shrink its cwnd
> to 1 (because there ar
We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
problem is triggered when the last packet of a request arrives CE
marked. The reply will carry the ECE mark causing TCP to shrink its cwnd
to 1 (because there are no packets in flight). When the 1st packet of
the next request a
On Sun, 17 Sep 2006 12:11:01 +0200
bert hubert <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 17, 2006 at 08:32:14AM +0900, Stephen Hemminger wrote:
>
> > By building all the possiblities into the kernel, ie. not as modules
> > you get the last one registered. TCP LP is probably the worst one
> > to us
On Sun, Sep 17, 2006 at 08:32:14AM +0900, Stephen Hemminger wrote:
> By building all the possiblities into the kernel, ie. not as modules
> you get the last one registered. TCP LP is probably the worst one
> to use, because it is designed for bulk low priority applications.
> It also is one of the
On Sun, 17 Sep 2006 00:19:48 +0200
bert hubert <[EMAIL PROTECTED]> wrote:
> The bad news is that I haven't yet been able to capture traces.
> Once every three days or so I get a crash of 2.6.18-rc[67] which
> *probably* end in tcp_ack(), but I don't have the exact dump.
>
> My .config is indeed
The bad news is that I haven't yet been able to capture traces.
Once every three days or so I get a crash of 2.6.18-rc[67] which
*probably* end in tcp_ack(), but I don't have the exact dump.
My .config is indeed heavy on TCP congestion stuff:
$ zcat /proc/config.gz | grep -i tcp
CONFIG_INET_TCP_
On Thu, 24 Aug 2006 23:03:22 +0800
"Majumder, Rajib" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I had a fundamental question regarding stack. When does TCP ack a segment? Is
> it immediately receiving a segment or after copying the data from kernel to
> user i.e a
Hi,
I had a fundamental question regarding stack. When does TCP ack a segment? Is
it immediately receiving a segment or after copying the data from kernel to
user i.e after read() system call returns?
Any input is highly appreciated.
Thanks
Rajib
22 matches
Mail list logo
