But if the chrony instance has been disciplined for a while by a working
chrony, it should be far better, even freewheeling, than the rtc. rtcs are not
designed for accuracy-- just getting the time to approximately the right time
on bootup. Ie, I would trust a freewheeling computer that had been disciplined
more than I would an rtc. (remember that rtc's are also affected by
temperature).
What is the maximum tolerable deviation from UTC for your clock? And how long
does the gps signal drop out? Where is your antenna-- can it see the southern
sky (assuming you are in the nothern Hemisphere).
On Sat, 6 Mar 2021, Vincenzo Miceli wrote:
> [CAUTION: Non-UBC Email]
>
> Because that is the easiest way I see for the client to know that something is not right with the time server. This is an isolated system with no access to other network NTP servers. And if the client is aware of a time issue then its software can act accordingly.
I guess another alternative would be for chrony to use the onboard RTC (DS3231) as time source, I did try to get chrony to talk to the RTC but I always received drivers errors on rpi buster...
> I'm pretty sure a proper antenna will do as that is what the other "reference" rpi is using while this sketchy one has a small ceramic patch inside a 1mm PLA dome. That's easy and cheap to test anyway...
> To answer your other question, yes the freewheeling rpi drifts less at 2.4msec/day while the Win 10 NUC at 8.7msec/day (roughly over a couple of hours). These figures are likely to get much worse though over longer period of time and temp fluctuations...
the DS3231 should do be better longer term.
>
> Thanks!
>
> Enzo
>
> [cid:df79ac97-f603-4f8e-9a75-a6f0bbd8b734]
> ________________________________
> From: Bill Unruh <unruh@xxxxxxxxxxxxxx>
> Sent: Friday 5 March 2021 20:10
> To: chrony-users@xxxxxxxxxxxxxxxxxxxx <chrony-users@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [chrony-users] Issue with chrony dropping PPS signal
>
> Why? The server will keep freewheeling, with both its offset and its rate
> having been adjusted to UTC, so it should keep pretty good time for quite a
> while (even better if you have temperature corrections incorporated into
> chrony). Are all your client clocks that good that they can all keep
> freewheeling time that is as good as or better than your server, since that is
> what will happen if your server stops serving time.
>
> Once your position is known, even one sattelite should give good time. It
> sounds like it is the receiver that is problematic. Is your antenna really
> that borderline?
>
>
> William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
> Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
> UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
> Canada V6T 1Z1 ____|____ and Gravity ______|_
www.theory.physics.ubc.ca/<http://www.theory.physics.ubc.ca/>
>
> On Fri, 5 Mar 2021, Vincenzo Miceli wrote:
>
>> [CAUTION: Non-UBC Email] Hi Miroslav, Hal,
>>
>> it turns out that the GPS loses satellite fix and the PPS stops as you have predicted. I can fix that by using an active antenna with
>> much better gain.
>> Is there any way for chrony to stop provide time to clients if the PPS signal is lost?
>>
>> Thanks again!!
>>
>> Enzo
>>
>> ______________________________________________________________________________________________________________________________________
>> From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
>> Sent: Thursday 4 March 2021 13:19
>> To: chrony-users@xxxxxxxxxxxxxxxxxxxx <chrony-users@xxxxxxxxxxxxxxxxxxxx>
>> Subject: Re: [chrony-users] Issue with chrony dropping PPS signal
>> On Thu, Mar 04, 2021 at 01:19:51PM +0000, Vincenzo Miceli wrote:
>>> Thanks Miroslav,
>>>
>>> I want to make sure I understand... you are asking to run something like watch -n 1 'cat /sys/class/pps/pps0/assert' next time I
>> detect the issue and see if the result is changing to indicate PPS is still being issued by the GPS right?
>>> I'll do that then.
>>
>> Yes, or collect it in a log to not miss it, e.g. every 10 seconds, or
>> use the script Hal linked.
>>
>> --
>> Miroslav Lichvar
>>
>>
>> --
>> To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
>> with "unsubscribe" in the subject.
>> For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
>> with "help" in the subject.
>> Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
>>
>>
>>
>
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.