Re: [ntpwg] Antw: Re: call for adoption (draft-dfranke-ntp-data-minimization)

[Miroslav Lichvar <[e-mail]>]

On Thu, Mar 30, 2017 at 08:06:31AM +0200, Ulrich Windl wrote:
> > IIRC you're correct, but the randomization is some number of whole
> > seconds. The fractional part of the second is determined by whenever
> > the SIGALRM happens to come in, which is not random. Anyhow, I think
> 
> Actually I think that part is (depending on the number of fractional digits you look at) actually more random than the rest. With today's CPUs it almost unpredictable to estimate the atual number of cycles a sequence of instructions takes. Do you have real-life statistics material to proove your claims?

I think the stability of the scheduling will depend on the HW, OS, and
how busy is the system. In most cases it will probably be better than
a typical network jitter on the Internet (few milliseconds). You can
check it with tcpdump:

# tcpdump -v -l -n port 123 and host $clientip and 'udp[8] & 15 = 3' | \
  grep '  Transmit'
          Transmit Timestamp:   3699846941.374009549 (2017/03/30 09:15:41)
          Transmit Timestamp:   3699846949.374010294 (2017/03/30 09:15:49)
          Transmit Timestamp:   3699846957.374027043 (2017/03/30 09:15:57)
          Transmit Timestamp:   3699846965.374011576 (2017/03/30 09:16:05)
          Transmit Timestamp:   3699846973.374011486 (2017/03/30 09:16:13)
          Transmit Timestamp:   3699846981.374003976 (2017/03/30 09:16:21)
          Transmit Timestamp:   3699846989.374010205 (2017/03/30 09:16:29)
          Transmit Timestamp:   3699846997.374008774 (2017/03/30 09:16:37)
          Transmit Timestamp:   3699847005.374012529 (2017/03/30 09:16:45)

In this case the ntpd client has scheduling stable to few tens of
microseconds, i.e. the transmit timestamp has about 15 constant bits.

-- 
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg