netdev - Re: [PATCH net-next 00/15] tcp: TCP TS option use 1 ms clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 17 May 2017 16:06:22 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     edumazet@...gle.com
Cc:     ncardwell@...gle.com, ycheng@...gle.com, soheil@...gle.com,
        weiwan@...gle.com, netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH net-next 00/15] tcp: TCP TS option use 1 ms clock

From: Eric Dumazet <edumazet@...gle.com>
Date: Tue, 16 May 2017 13:59:59 -0700

> 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

Series applied, thanks Eric.