| Message ID | 20110308093215.GA23842@xanadu.blop.info |
|---|---|
| State | Superseded, archived |
| Delegated to: | David Miller |
| Headers | show |
On Tue, 08 Mar 2011 10:32:15 +0100, Lucas Nussbaum wrote: > + { > +// printk("hystart_update: cwnd=%u found=%d > delay_min=%u cur_jif=%u round_start=%u curr_rtt=%u\n", tp->snd_cwnd, > ca->found, ca Please remove this line from your patch. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 8 Mar 2011 10:32:15 +0100 Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote: > CUBIC Hystart uses two heuristics to exit slow start earlier, before > losses start to occur. Unfortunately, it tends to exit slow start far too > early, causing poor performance since convergence to the optimal cwnd is > then very slow. This was reported in > http://permalink.gmane.org/gmane.linux.network/188169 and > https://partner-bugzilla.redhat.com/show_bug.cgi?id=616985 Ignore the RHEL bug. RHEL 5 ships with TCP BIC (not CUBIC) by default. There are many research papers which show that BIC is too aggressive, and not fair.
On 10/03/11 at 15:28 -0800, Stephen Hemminger wrote: > On Tue, 8 Mar 2011 10:32:15 +0100 > Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote: > > > CUBIC Hystart uses two heuristics to exit slow start earlier, before > > losses start to occur. Unfortunately, it tends to exit slow start far too > > early, causing poor performance since convergence to the optimal cwnd is > > then very slow. This was reported in > > http://permalink.gmane.org/gmane.linux.network/188169 and > > https://partner-bugzilla.redhat.com/show_bug.cgi?id=616985 > > Ignore the RHEL bug. RHEL 5 ships with TCP BIC (not CUBIC) by default. > There are many research papers which show that BIC is too aggressive, > and not fair. According to the bug report, the server is running RHEL6 (with CUBIC and Hystart), it's the client that is running RHEL5.
diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c index 71d5f2f..a973a49 100644 --- a/net/ipv4/tcp_cubic.c +++ b/net/ipv4/tcp_cubic.c @@ -344,7 +344,7 @@ static void hystart_update(struct sock *sk, u32 delay) /* first detection parameter - ack-train detection */ if (curr_jiffies - ca->last_jiffies <= msecs_to_jiffies(2)) { ca->last_jiffies = curr_jiffies; - if (curr_jiffies - ca->round_start >= ca->delay_min>>4) + if (curr_jiffies - ca->round_start >= ca->delay_min>>2) ca->found |= HYSTART_ACK_TRAIN; } @@ -355,8 +355,7 @@ static void hystart_update(struct sock *sk, u32 delay) ca->sample_cnt++; } else { - if (ca->curr_rtt > ca->delay_min + - HYSTART_DELAY_THRESH(ca->delay_min>>4)) + if (ca->curr_rtt > ca->delay_min<<1) ca->found |= HYSTART_DELAY; } /* @@ -364,7 +363,10 @@ static void hystart_update(struct sock *sk, u32 delay) * we exit from slow start immediately. */ if (ca->found & hystart_detect) + { +// printk("hystart_update: cwnd=%u found=%d delay_min=%u cur_jif=%u round_start=%u curr_rtt=%u\n", tp->snd_cwnd, ca->found, ca tp->snd_ssthresh = tp->snd_cwnd; + } } } -- To unsubscribe from this list: send the line "unsubscribe netdev" in
CUBIC Hystart uses two heuristics to exit slow start earlier, before losses start to occur. Unfortunately, it tends to exit slow start far too early, causing poor performance since convergence to the optimal cwnd is then very slow. This was reported in http://permalink.gmane.org/gmane.linux.network/188169 and https://partner-bugzilla.redhat.com/show_bug.cgi?id=616985 I am using an experimental testbed (http://www.grid5000.fr/) with two machines connected using Gigabit ethernet to a dedicated 10-Gb backbone. RTT between both machines is 11.3ms. Using TCP CUBIC without Hystart, cwnd grows to ~2200. With Hystart enabled, CUBIC exits slow start with cwnd lower than 100, and often lower than 20, which leads to the poor performance that I reported. After instrumenting TCP CUBIC, I found out that the segment-to-ack RTT tends to vary quite a lot even when the network is not congested, due to several factors including the fact that TCP sends packet in burst (so the packets are queued locally before being sent, increasing their RTT), and delayed ACKs on the destination host. The patch below increases the thresholds used by the two Hystart heuristics. First, the length of an ACK train needs to reach 2*minRTT. Second, the max RTT of a group of packets also needs to reach 2*minRTT. In my setup, this causes Hystart to exit slow start when cwnd is in the 1900-2000 range using the ACK train heuristics, and sometimes to exit in the 700-900 range using the delay increase heuristic, dramatically improving performance. I've left commented out a printk that is useful for debugging the exit point of Hystart. And I could provide access to my testbed if someone wants to do further experiments. Signed-off-by: Lucas Nussbaum <lucas.nussbaum@loria.fr>