public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Richard Cochran <richardcochran@gmail.com>, netdev@vger.kernel.org
Subject: Re: phc2sys - does it work?
Date: Sun, 26 Jul 2020 22:53:21 +0300	[thread overview]
Message-ID: <20200726195321.hwf22sqy7tada47k@skbuf> (raw)
In-Reply-To: <20200726110104.GV1605@shell.armlinux.org.uk>

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

      parent reply	other threads:[~2020-07-26 19:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-25 12:49 phc2sys - does it work? Russell King - ARM Linux admin
2020-07-25 13:29 ` Vladimir Oltean
2020-07-26 11:01   ` Russell King - ARM Linux admin
2020-07-26 18:05     ` Richard Cochran
2020-07-26 21:29       ` Russell King - ARM Linux admin
2020-07-27 14:10         ` Richard Cochran
2020-07-26 19:53     ` Vladimir Oltean [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200726195321.hwf22sqy7tada47k@skbuf \
    --to=olteanv@gmail.com \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox