netdev - Re: [PATCH 0/6] TCP CUBIC and Hystart

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimi+nJ1-PO+JYjckg-Pw3+6-zJvqPvhMjf+1Lua@mail.gmail.com>
Date:	Fri, 11 Mar 2011 10:58:05 -0500
From:	Sangtae Ha <sangtae.ha@...il.com>
To:	Lucas Nussbaum <lucas.nussbaum@...ia.fr>
Cc:	Stephen Hemminger <shemminger@...tta.com>, davem@...emloft.net,
	rhee@...u.edu, netdev@...r.kernel.org
Subject: Re: [PATCH 0/6] TCP CUBIC and Hystart

Hi Lucas,

>From your setup, ca->delay_min is 90 and this means the one-way delay
is 90 >> 4 (5ms).
And our gap detection threshold is 2ms, which means that if the gap is
loosely spread over 5ms with delayed ACKs, it can early terminate the
slow start. But, given the optimal cwnd is 941 in your setup, exiting
slow start one RTT before the loss (half of the optimal cwnd) is what
hystart does.

Since the resolution is now ms, can you change the gap detection to
1ms and run it again?
Also, the following change you did doesn't hurt (1ms more train to
detect the ACK train).

if ((s32)(now - ca->round_start) > ca->delay_min >> 4)

I am also testing the algorithm with HZ=100ms and 1000ms in my network
and will share the results soon.

Sangtae


On Fri, Mar 11, 2011 at 5:28 AM, Lucas Nussbaum <lucas.nussbaum@...ia.fr> wrote:
> On 10/03/11 at 08:51 -0800, Stephen Hemminger wrote:
>> This patch set is my attempt at addressing the problems discovered
>> by Lucas Nussbaum.
>
> With those patches applied (and the fix I mentioned separately), it
> works much better (still with HZ=250).
>
> When a delayed ack train is detected, slow start ends with cwnd ~= 580
> (sometimes a bit lower).
> When no delayed ack train is detected, slow start ends with the detection of the
> delay increase at cwnd in the [700:1100] range.
>
> performance is still not as good as without hystart, but it is more
> acceptable:
>
> nuttcp -i1 -n1g graphene-34.nancy.grid5000.fr
>   94.8125 MB /   1.00 sec =  795.3059 Mbps     0 retrans
>  112.2500 MB /   1.00 sec =  941.6325 Mbps     0 retrans
>  112.2500 MB /   1.00 sec =  941.6222 Mbps     0 retrans
>  112.2500 MB /   1.00 sec =  941.6335 Mbps     0 retrans
>  112.2500 MB /   1.00 sec =  941.6354 Mbps     0 retrans
>  112.2500 MB /   1.00 sec =  941.6231 Mbps     0 retrans
>  112.2500 MB /   1.00 sec =  941.5883 Mbps     0 retrans
>  112.2500 MB /   1.00 sec =  941.6297 Mbps     0 retrans
>  112.2500 MB /   1.00 sec =  941.6391 Mbps     0 retrans
>
>  1024.0000 MB /   9.29 sec =  924.7155 Mbps 14 %TX 28 %RX 0 retrans 11.39 msRTT
> During that run, no ack train was detected, but delay increase was detected when cwnd=1105:
> hystart_update: cwnd=1105 ssthresh=1105 fnd=2 hs_det=3   cur_rtt=122 delay_min=90 DELTRE=16
>
> However:
> echo 1 > /proc/sys/net/ipv4/route/flush; nuttcp -i1 -n1g graphene-34.nancy.grid5000.fr
>   49.5000 MB /   1.00 sec =  415.2278 Mbps     0 retrans
>   59.0000 MB /   1.00 sec =  494.9318 Mbps     0 retrans
>   62.1875 MB /   1.00 sec =  521.6535 Mbps     0 retrans
>   64.1250 MB /   1.00 sec =  537.9329 Mbps     0 retrans
>   67.0625 MB /   1.00 sec =  562.5486 Mbps     0 retrans
>   69.4375 MB /   1.00 sec =  582.4840 Mbps     0 retrans
>   72.3750 MB /   1.00 sec =  607.1395 Mbps     0 retrans
>   75.3125 MB /   1.00 sec =  631.7557 Mbps     0 retrans
>   83.1250 MB /   1.00 sec =  697.2975 Mbps     0 retrans
>   94.3125 MB /   1.00 sec =  791.1569 Mbps     0 retrans
>  107.6250 MB /   1.00 sec =  902.8194 Mbps     0 retrans
>  112.2500 MB /   1.00 sec =  941.6231 Mbps     0 retrans
>
>  1024.0000 MB /  12.97 sec =  662.2669 Mbps 10 %TX 20 %RX 0 retrans 11.39 msRTT
> [ 3050.712333] found ACK TRAIN: cwnd=493 now=2757023598 ca->last_ack=2757023598 ca->round_start=2757023593 ca->delay_min=90 delay_min>>4=5
> [ 3050.726045] hystart_update: cwnd=493 ssthresh=493 fnd=1 hs_det=3   cur_rtt=91 delay_min=90 DELTRE=16
> (delayed ack train detected when cwnd=493 => slower convergence)
>
> It seems that the ack train length detection is still a bit too sensitive.
> Changing:
>        if ((s32)(now - ca->round_start) >= ca->delay_min >> 4)
> To:
>        if ((s32)(now - ca->round_start) > ca->delay_min >> 4)
> makes things slightly better, but slow start still exits too early. (optimal cwnd=941).
>
> I'm not sure if we can really do something more about that. The detection by
> ack train length is inherently more likely to trigger false positives since all
> acks are considered, not just a few acks at the beginning of the train.  I'm
> tempted to suggest to disable the ack train length detection by default, but
> then it probably solves problems for other people, and the decrease in
> performance is more acceptable now.
> --
> | 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