netdev - Re: phc2sys - does it work?

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]

Message-ID: <20200726195321.hwf22sqy7tada47k@skbuf>
Date:   Sun, 26 Jul 2020 22:53:21 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Richard Cochran <richardcochran@...il.com>, netdev@...r.kernel.org
Subject: Re: phc2sys - does it work?

On Sun, Jul 26, 2020 at 12:01:05PM +0100, Russell King - ARM Linux admin wrote:
> 
> Another solution would be to avoid running NTP on any machine intending
> to be the source of PTP time on a network, but that then brings up the
> problem that you can't synchronise the PTP time source to a reference
> time, which rather makes PTP pointless unless all that you're after is
> "all my local machines say the same wrong time."
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

TL;DR: if your PHC supports external timestamping (extts), use that,
plus a GPS module. Then synchonize CLOCK_REALTIME to the PHC and not the
other way around.

I guess there is some truth to the saying that "a man with one clock
knows what time it is; a man with two clocks is never sure".

In my corner of the universe, you would never want a 1588 GM to be
disciplined to a Stratum >= 2 NTP server, and possibly never over NTP at
large. That is, _if_ you want your 1588 timing domain to be traceable to
TAI at all (and if the use case doesn't require that, you're 100% better
off leaving the 1588 GM free-running).  Jitter propagates transitively,
and there are few worse things you can do to a synchronization network
than serve a time that is jittery in the first place.

The biggest source of jitter is so-called 'software synchronization'
(aka without hardware assist). phc2sys is a prime example of that, but
also NTP in the configuration most people use it in. There are ways to
improve that (the various species of SYSOFF), and while they do work
fine, the brick wall between hardware and software synchronization still
exists. The one place where it is fine is at the leaves of the clock
distribution tree, aka syncing the system time to the PHC. There, even
if you want to do some periodic tasks based on the PTP schedule, the
scheduling jitter is probably large enough anyway that software
synchronization is not your biggest concern.

-Vladimir