diff options
author | 2017-05-17 16:06:03 -0400 | |
---|---|---|
committer | 2017-05-17 16:06:03 -0400 | |
commit | e26925ec03b31f5ae4c1fc544515486229334ef9 (patch) | |
tree | 6f1502edf55ecb7205660d62bd683ebcf912cfea /include/linux/skb_array.h | |
parent | sch_dsmark: Fix uninitialized variable warning. (diff) | |
parent | tcp: switch TCP TS option (RFC 7323) to 1ms clock (diff) | |
download | linux-rng-e26925ec03b31f5ae4c1fc544515486229334ef9.tar.xz linux-rng-e26925ec03b31f5ae4c1fc544515486229334ef9.zip |
Merge branch 'tcp-TCP-TS-option-use-1-ms-clock'
Eric Dumazet says:
====================
tcp: TCP TS option use 1 ms clock
TCP Timestamps option is defined in RFC 7323
Traditionally on linux, it has been tied to the internal
'jiffy' variable, because it had been a cheap and good enough
generator.
Unfortunately some distros use HZ=250 or even HZ=100 leading
to not very useful TCP timestamps.
For TCP flows in the DC, Google has used usec resolution for more
than two years with great success [1].
RCVBUF autotuning is more precise.
This series converts tp->tcp_mstamp to a plain u64 value storing
a 1 usec TCP clock.
This choice will allow us to upstream the 1 usec TS option as
discussed in IETF 97.
Kathleen Nichols [2] and others advocate for 1ms TS clocks for
network analysis. (1ms being the lowest value supported by RFC 7323.)
[1] https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf
[2] http://netseminar.stanford.edu/seminars/02_02_17.pdf
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/linux/skb_array.h')
0 files changed, 0 insertions, 0 deletions