Message-ID: <20110311102809.GB15941@xanadu.blop.info>
Date:	Fri, 11 Mar 2011 11:28:09 +0100
From:	Lucas Nussbaum <lucas.nussbaum@...ia.fr>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	davem@...emloft.net, sangtae.ha@...il.com, rhee@...u.edu,
	netdev@...r.kernel.org
Subject: Re: [PATCH 0/6] TCP CUBIC and Hystart

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

Powered by blists - more mailing lists