Rasp Pi at +/- 1 us from GPS

[MLewis]

Hello,

On 26/11/2017 3:13 PM, Hal Murray wrote:
> I think it should do what you want if you set it up with only a localclock.
> (no normal servers)
I think I found it.
Similar use case as when the reference is System Time disciplined by PTP.

The local clock driver can also be used when an external synchronization 
source such as the IEEE 1588 Precision Time Protocol or NIST Lockclock 
directly synchronizes the computer time. Further information is on the 
External Clock Discipline and the Local Clock Driver page.
https://docs.ntpsec.org/latest/extern.html

> Nice.  Thanks.
> You don't need the RTC.  You can get the initial time over the net.
But the time I can get from the DS3231 RTC after outages should have 
drifted in microseconds, or tens of or hundreds of. So very fast sync to 
TOS by pps-client once booted and GPS solution provided. Lady Heather 
won't even get involved to provide a whole second (already better than 
300 ms).
And I have that independent of the internet being available; this time 
sever can be up and providing time to my local network.

An enhancement would be upon PPS loss apply recent system time drift 
corrections during holdover. (pps-client may already do this, or NTPsec 
may be able to do this as though PTP disciplining was lost.)

>
>> - (if I understand properly) pps-client takes a pair of GPIO pins and
>> calibrates latency, so its PPS adjustment is more accurate.
> Any numbers?
Just what the author provided at the git site.
The example shows the display of the correction offset, but that isn't 
appearing on my "status printout".
I may need to find a switch to set to get to see it.

On 26/11/2017 4:44 PM, Hal Murray wrote:
> devel at ntpsec.org said:
>> - pps-client installed as expected. One gets the Stretch source and
>> compiles the kernel as part of that.
> It would be interesting to poke around in pps-client to see what it actually
> does.
>
> There are two ways to use PPS.  One is to to capture the data and then feed
> the offset into a normal algorithm like ntpd uses.  The other is to set a
> mode bit so the kernel does all the work.
>
> The latter doesn't work with the NO_HZ scheduling option in the kernel.  Most
> distros ship a kernel with that option enabled to save power.  Rebuilding the
> kernel is a strong hint that they want to use the kernel mode.  If that's the
> case, you can use ntpd to do the same thing.  It's a flag bit to the PPS
> driver.
>
> It would be interesting to compare whatever pps-client does with what ntpd
> does (same kernel) with and without that flag.
The only clue I have is what the author wrote:
<quote>
As I recall, making direct changes to the system clock externally to 
PPS-Client caused some problems because the parts of NPT that are 
embedded in the kernel prevent slews to a new time of day of more than 
500 microseconds each second. I got around this by making the correction 
through its kernel driver below the NTP code. I don't know whether doing 
external time settings is still an issue in later Linux kernels.
<unquote>