diff options
author | 2019-12-23 12:27:52 -0800 | |
---|---|---|
committer | 2019-12-27 16:29:14 -0800 | |
commit | cff04e2da308c522f654237b45dd64248fe8d1fa (patch) | |
tree | a21a359b1de5cf4f4471caadd2dd2c55ccad8913 /Makefile | |
parent | tcp_cubic: remove one conditional from hystart_update() (diff) | |
download | linux-dev-cff04e2da308c522f654237b45dd64248fe8d1fa.tar.xz linux-dev-cff04e2da308c522f654237b45dd64248fe8d1fa.zip |
tcp_cubic: switch bictcp_clock() to usec resolution
Current 1ms clock feeds ca->round_start, ca->delay_min,
ca->last_ack.
This is quite problematic for data-center flows, where delay_min
is way below 1 ms.
This means Hystart Train detection triggers every time jiffies value
is updated, since "((s32)(now - ca->round_start) > ca->delay_min >> 4)"
expression becomes true.
This kind of random behavior can be solved by reusing the existing
usec timestamp that TCP keeps in tp->tcp_mstamp
Note that a followup patch will tweak things a bit, because
during slow start, GRO aggregation on receivers naturally
increases the RTT as TSO packets gradually come to ~64KB size.
To recap, right after this patch CUBIC Hystart train detection
is more aggressive, since short RTT flows might exit slow start at
cwnd = 20, instead of being possibly unbounded.
Following patch will address this problem.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions