Pros:
(1) it boosts performance in LAN where packet loss is serious.
(2) it is less dependent on ticks (expensive kern.hz on different platforms).
(3) it has less influence in WAN where RTT > 10ms and CUBIC's concave/convex approach dominates.
Cons:
not RFC8312 compliant
This change shows better performance than a finer timer approach. For example, we can compare below with the results from 10k or 100k **kern.hz** value in [[ https://wiki.freebsd.org/chengcui/testTCPCCinVM#test_result | testTCPCCinVM#test_result ]].
| kern.hz value | TCP congestion control algo | iperf result from 1% data packet drop rate | iperf result from 2% data packet drop rate |
| 100000 (100k) | stock cubic | 719 Mbits/sec | 547 Mbits/sec |
| 10000 (10k) | stock cubic | 923 Mbits/sec | 683 Mbits/sec |
| 1000 (1k) | stock cubic | 917 Mbits/sec | 527 Mbits/sec |
| 100 | stock cubic | **168** Mbits/sec | **83.8** Mbits/sec |
| 100 | this cubic patch | 921 Mbits/sec (+4.5X) | **876** Mbits/sec(+9.5X) |