| Re: [chrony-users] Newbie requesting help |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Mon, 21 Mar 2016, Stuart Maclean wrote:
I have a reference clock onboard an embedded system running a legacy
Linux 2.6.10. That kernel has no 'Linux PPS' support, nor have I yet
looked into patching it in.
My clock, call it C, outputs a 'seconds since epoch' counter over a
serial line to me, and also outputs a PPS, which is wired to an GPIO
pin. At
start of deployment, I can set the counter from a GPS source. GPS then
goes away.
There is no Internet access on this system. I want to use clock C to
maintain good Linux system time. I am hoping chronyd might help. I
have basically asked this same question on the ntpd mailing list, to no
avail.
I have written a Linux device driver which exposes two char devices:
/dev/clock
/dev/clockpps
A userspace read of /dev/clock blocks until C next increments its
counter, which is does when its PPS fires. The counter value is then
the result of the read.
Not sure why you want to do it this way. You say that you can use an
interrupt. Have that interrupt read the system clock and output that time to
the device (eg /dev/clock). Then you have to make sure that the system clock
is, initally, within .25 sec of the UTC.
A userspace read of /dev/clockpps blocks until C next outputs its PPS
signal. In the device driver, I grab Linux system time right in the
interrupt handler for the PPS/GPIO signal. I am installing the ISR
using a 'fast interrupt' handler too, so am doing all I can to minimize
latency between the pps occuring and me grabbing Linux time.
The linux system clock time at time of PPS is then fed back as the
result of the read of /dev/clockpps.
So, as I see it, I have two 'votes' for the correct time at moment of
PPS. The first is C's vote for the time, its simple 'seconds counter'.
The second is Linux's vote for the time, i.e. the software clock. In
my system, the software clock is driven by a 32KHz clock, using a jiffy
of 10ms. The resolution of that clock is then about 30us.
I was then under the impression that I would supply these two 'votes'
Only one vote is needed. And you only have one vote-- both times are
equivalent-- they come from the same source: your clock.
for the correct time to ntpd/chrony?? But when I looked into how gpsd
feeds its time parameters (ie a PPS event and a GPRMC string?) over SHM
to ntpd, I see that not one but TWO clock sources are used. Am I
GPSD grabs and interrupt, which tells it when the time on the exact second.
And it grabs the second source to tell it which second that is.
You already have that.
supposed to split my data into these two sources? Given that the
shmTime struct has a 'clockTimestamp' AND a 'receiveTimestamp', do I
need FOUR and not TWO timestamps to complete the shm implementation?
A ntp packet is four timestamps. When the request was sent, when the request
was received by the remote clock, when the time was sent out by the remote
clock, and when the time was received by the local system. In your case the
remote system and the local system are the same.
ntp ( which chrony also uses) determines the offset of your local system by
(t1+t4-(t2+t3))/2 Thus t2 and t3 should be the "on the second" times, and t1
and t4 the system time when the pulse comes in.
This will give a delay of 0, and an offset which is how much the local time is
off from UTC.
Your accuracy will now depend entirely on the accuracy of that clock chip.
Are you sure you cannot just use gps time?
Any help appreciated, and I apologize if I am not describing the problem
too well.
Stuart
--
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.