Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Stephen Hemminger <hidden>
Date: 2011-03-09 21:51:25
On Wed, 9 Mar 2011 22:33:56 +0100 Lucas Nussbaum [off-list ref] wrote:
On 09/03/11 at 13:12 -0800, Yuchung Cheng wrote:quoted
On Wed, Mar 9, 2011 at 12:01 PM, Stephen Hemminger [off-list ref] wrote:quoted
On Wed, 9 Mar 2011 19:25:05 +0100 Lucas Nussbaum [off-list ref] wrote:quoted
On 09/03/11 at 09:56 -0800, Stephen Hemminger wrote:quoted
On Wed, 9 Mar 2011 07:53:19 +0100 Lucas Nussbaum [off-list ref] wrote:quoted
On 08/03/11 at 20:30 -0500, Injong Rhee wrote:quoted
Now, both tools can be wrong. But that is not catastrophic since congestion avoidance can kick in to save the day. In a pipe where no other flows are competing, then exiting slow start too early can slow things down as the window can be still too small. But that is in fact when delays are most reliable. So those tests that say bad performance with hystart are in fact, where hystart is supposed to perform well.Hi, In my setup, there is no congestion at all (except the buffer bloat). Without Hystart, transferring 8 Gb of data takes 9s, with CUBIC exiting slow start at ~2000 packets. With Hystart, transferring 8 Gb of data takes 19s, with CUBIC exiting slow start at ~20 packets. I don't think that this is "hystart performing well". We could just as well remove slow start completely, and only do congestion avoidance, then. While I see the value in Hystart, it's clear that there are some flaws in the current implementation. It probably makes sense to disable hystart by default until those problems are fixed.What is the speed and RTT time of your network? I think you maybe blaming hystart for other issues in the network.What kind of issues? Host1 is connected through a gigabit ethernet LAN to Router1 Host2 is connected through a gigabit ethernet LAN to Router2 Router1 and Router2 are connected through an experimentation network at 10 Gb/s RTT between Host1 and Host2 is 11.3ms. The network is not congested.By my calculations (1G * 11.3ms) gives BDP of 941 packets which means CUBIC would ideally exit slow start at 900 or so packets. Old CUBIC slowstrart of 2000 packets means there is huge overshoot which means large packet loss burst which would cause a large CPU load on receiver processing SACK.It's not clear from Lucas's report that the hystart is exiting when cwnd=2000 or when sender has sent 2000 packets. Lucas could you clarify?When cwnd is around 2000.
What is HZ on the kernel configuration. Part of the problem is the hystart code was only tested with HZ=1000 and there are some bad assumptions there. --