Re: [chrony-users] Issue with chrony dropping PPS signal

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]



2PPM = 2 10^-6 which means that in 1 day, it could be out by 200 ms. To test
you want to let your clock be disciplined for at least a day with the GPS, and
then let it freewheel and compare with the rtc.
But I certainly agree that it would be better to have the gps signal. I also
do find it strange that outside, you would be losing the GPS signal for long
times, even at 53 deg north, even with a not great antenna. Is there a defect
with the gps receiver? In fact the density of sattelites there should be at
about the greatest density, since the orbits have an inclination of 55 deg,
and thus they spend more time on the east-west zenith arc at that lattitude.

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/

On Sat, 6 Mar 2021, Vincenzo Miceli wrote:

[CAUTION: Non-UBC Email] Bill, the rtc is temp controlled specc'ed at 2ppms. My minimum specification for deviation from UTM is <1msec
at all time. The system as it is now has been capable of <0.1msec excluding cold starts and config testing. At the moment it is right
at the window facing south, but it will be in the field in operation next to an astronomical telescope. Yes I'm at 53deg N :-)

I should be able to do an experiment were I let freewheel the server and poll the rtc to test your hypothesis.

Thanks!

Enzo

Get Outlook for Android


______________________________________________________________________________________________________________________________________
From: Bill Unruh <unruh@xxxxxxxxxxxxxx>
Sent: Saturday, 6 March 2021, 17:17
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [chrony-users] Issue with chrony dropping PPS signal

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.





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/