archive mirror
 help / color / mirror / Atom feed
From: Richard Cochran <>
To: Arnd Bergmann <>
	David Miller <>,
	YueHaibing <>,
	Networking <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
Date: Fri, 17 Aug 2018 20:09:53 -0400	[thread overview]
Message-ID: <20180818000953.GB13653@eeboy> (raw)
In-Reply-To: <>

On Fri, Aug 17, 2018 at 09:29:56PM +0200, Arnd Bergmann wrote:
> This certainly seems to be an "interesting" problem, given that the Linux
> implementations (other than the new lan743x) then start out with UTC,
> while the PTP spec mandates TAI. So even if the system clock is
> perfectly synchronized to UTC at boot,

When the system boots, it is not synchronized.  Only after ntpd or
ptp4l start their work can we say that.

> we set the PTP hardware 37 
> seconds slow.

> It would not be hard to change all PTP drivers to explicitly initialize to
> TAI, but that might create its own set of problems if random code
> depends on the current behavior.

Right. (But there was never any guarantee.)

Also, devices that don't have an RTC (like many embedded) start with
1970 anyhow.  So you really can't have "correct" time at boot.  The
question is, which incorrect time would you prefer?

IHMO a clearly wrong value is more useful than one that might be
mistaken as correct by a casual glance from the sysadmin.

> I also see that "phc_ctl /dev/ptp0 set" defaults to CLOCK_REALTIME
> and has no option to use CLOCK_TAI instead. How is this meant to
> work? I see a lot of other code that tries to deal with leap seconds and
> the tai offset, so I hope I was just misreading that code.

You *can* set UTC and then jump the clock by 37 in two steps.

But I don't see an simple solution for setting the TAI-UTC offset at
boot without actually consulting an outside source.  Even if you have
the NTP leap seconds file, how does the system know the file is up to

For PTP and PHC devices, there are two use cases.

1. The device is a slave.  In this case, applications need to wait
   until the PTP status bits say that the time is valid.  The invalid
   time before shouldn't be trusted at all.

2. The device is a grand master.  In this case, the PTP stack has to
   wait until its global time source (like GPS) is ready.  Then it
   will synchronize the local PHC to the global source, and only then
   should it advertise the valid bits.

So I don't think the particular kind of wrong start-up value makes
much difference in practice.

You could argue that if

  a) the system has an RTC, and
  b) the battery isn't dead, and
  c) there is a leap seconds file that isn't out of date,

then the initial PHC time will be less wrong (for some definition of
wrong) using TAI than if the driver had used UTC or 1970.

I myself can't get too excited about having "less wrong" time, but I
wouldn't mind trying to set TAI in the PHC layer if people feel
strongly about it.


  reply	other threads:[~2018-08-18  0:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-15 17:49 [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64 Arnd Bergmann
2018-08-15 18:03 ` Bryan.Whitehead
2018-08-15 20:33   ` Arnd Bergmann
2018-08-15 20:41     ` Bryan.Whitehead
2018-08-15 20:44       ` Arnd Bergmann
2018-08-15 20:50         ` Bryan.Whitehead
2018-08-17 16:25           ` Richard Cochran
2018-08-17 19:29             ` Arnd Bergmann
2018-08-18  0:09               ` Richard Cochran [this message]
2018-08-19 17:58 ` David Miller

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:

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

  git send-email \
    --in-reply-to=20180818000953.GB13653@eeboy \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).