Re: [chrony-users] PPS time

I currently have a UBlox 7 GPS receiver connected via serial cable to a Linux system and using it to provide a stratum (0/1) network clock that is synched to GPS time.

I used information from the GPSD web site as far as set up and configuration: https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html This provides a good introduction to setting up a GPS network clock that makes use of both GPS time messages from the GPS receiver and usage of the PPS (Pulse Per Second) signal often coming in on one of the serial control lines (DTR, DCD,??). Basically you use GPSD to talk to the GPS receiver, which uses KPPS (kernel module) to handle the PPS interrupt. GPSD handles all the details of serial port & where the PPS signal is coming from. CHRONYD sets up a socket connection or shared memory segment to GPSD for getting the PPS information. You configure CHRONYD to recognize it by having something like:

refclock SHM 0 refid GPS precision 1e-1 offset 0.0 delay 0.2
refclock SOCK /var/run/chrony.ttyS0.sock refid PPS

in /etc/chrony.conf

Hope this helps some

John

On Tue, Jul 16, 2019 at 3:10 PM Olivier Delbeke <olivier.delbeke@xxxxxxxxx> wrote:

>> So I'm wondering if there's a good way around this. Is there a way to configure chrony to look for, in effect, /dev/pps*?
Well, if I remember well, the usual way to work around this is to use udev-rules that will always rename the automatically generated device into whatever you choose (like /dev/mypps), and that you can use in your chrony configuration. These rules (although 1-line of code) are not straightforward to debug, though.

KR,

Olivier

On Tue, Jul 16, 2019 at 9:00 PM Steve Summit <scs@xxxxxxxxxx> wrote:
Several days ago, I wrote:
> ...If I want to use "raw" PPS, I need to (a) configure chronyd with
> something like "refclock PPS /dev/pps0" and (b) configure the Linux
> kernel so that /dev/pps0 reflects my actual PPS input.

With thanks to previous assistance from this list, I've got
chrony listening to /dev/pps0 directly, and it's working great.
But -- there's always a "but", isn't there? -- something else
has come up.

I'm getting the impression that /dev/pps0 is a particularly
virtual form of device. It seems to be created on the fly, when
the PPS line discipline is attached to an actual serial port, by
a program such as gpsd or ldattach. But if that process is ever
performed again -- if gpsd or ldattach should ever exit and be
restarted -- next time, the virtual device that's created might
be /dev/pps1.

(Oddly, at least on my system, further restarts seem to
recreate pps1 over and over again; I don't get a sequence pps2,
pps3, pps4 as I might otherwise expect.)

But of course this means that my shiny new chrony configuration
with its "refclock PPS /dev/pps0" line already has a blemish on
it, in that it's theoretically vulnerable to a restart of an
unrelated process which might yank /dev/pps0 out from under it.

So I'm wondering if there's a good way around this. Is there
a way to configure chrony to look for, in effect, /dev/pps*?

(I suspect the answer is "no"; it would be kind of crazy to have
chronyd not only do that sort of sh-style globbing, but also to
detect that, say, pps0 had disappeared out from under it and
that it therefore had to perform the expansion again and open
a different fd.)

Barring that -- although I guess this is more of a question for
the LinuxPPS folks -- is there a way to get pps0 "nailed down",
so that it doesn't change to pps1 if it's recreated? (Perhaps,
as I've seen some discussion of on the net, I should be using a
udev rule to explicitly create pps0.)

Thanks for any additional suggestions.

--
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.

John Burton, Ph.D.
MTEQ, Inc.

10440 Furnace Rd., Suite 204 Office: 540-658-2720 x1407
Lorton, VA 22079-2630 Mobile: 757-508-6208
jburton@xxxxxxxx Fax: 540-288-2515

Please note that the contents of this email including all attachments may be privileged or confidential in nature and are intended solely for the named recipients. If you have received this message in error, please contact the sender immediately and be aware that the use, copying, or dissemination of this information is prohibited.