[chrony-users] Newbie Help Needed

[Stuart Maclean]

I am essentially re-asking a question I posted to this list in early
2016 but never got a response I could understand, let alone implement.

My system is a legacy Linux 2.6.10 embedded system. There is no
/dev/pps* support in that kernel.

In my system there is no Internet access. I have a GPS device and a high
quality reference clock, call it C. At power up, I can sync C from the
GPS. GPS then goes away, my system is underwater for hours/days.

Clock C outputs a 'seconds-since-the-epoch string', call it S, if/when I
send it a 'request for time'. This two-ways comms is via serial
(rs232). The transmission of S by C happens when C's next PPS signal
fires. That PPS signal is also available to me as a GPIO pin which is
configured to produce a system interrupt.

I also have a cheap timer crystal, 32Khz, that serves as the default
'Linux system clock'. It is wildly inaccurate, and will slow
dramatically as my local water temperature changes (deeper water, lower
temperature). C is temperature compensated.

As you can imagine, I want to keep my Linux system time in line with,
i.e. disciplined from. my reference clock C.

Can chronyc do this? Do I have the appropriate set up for this to work?
I must admit that all the talk of 'ref clocks' and 'locking' confuses
me no end. I have NO idea what my .conf file would look like.

Any help very gratefully appreciated. Apologies for the sparse details.

Stuart

[Bill Unruh]

William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Stuart Maclean
I am essentially re-asking a question I posted to this list in early
2016 but never got a response I could understand, let alone implement.
My system is a legacy Linux 2.6.10 embedded system. There is no
/dev/pps* support in that kernel.

2.6 kernels certainly have pps support in the sense that modules for those
kernels can be loaded which read serial or GPIO lines and drive /dev/pps* from
that.

Look for modules kernel/drivers/pps/*

Post by Stuart Maclean
In my system there is no Internet access. I have a GPS device and a high
quality reference clock, call it C. At power up, I can sync C from the
GPS. GPS then goes away, my system is underwater for hours/days.

I am not sure what you mean by a "reference clock". What is it?

Post by Stuart Maclean
Clock C outputs a 'seconds-since-the-epoch string', call it S, if/when I
send it a 'request for time'. This two-ways comms is via serial

Serial communication is very slow. You basically cannot get better than
millisecond accuracy from a serial query.

Post by Stuart Maclean
(rs232). The transmission of S by C happens when C's next PPS signal
fires. That PPS signal is also available to me as a GPIO pin which is
configured to produce a system interrupt.

OK, you do have pps. Is the driver for that your own homegrown driver or is a
linux driver (like the pps-gpio module)?

Post by Stuart Maclean
I also have a cheap timer crystal, 32Khz, that serves as the default
'Linux system clock'. It is wildly inaccurate, and will slow
dramatically as my local water temperature changes (deeper water, lower
temperature). C is temperature compensated.

Yes, it would, although "wildly inaccurate is perhaps a bad overstatement. How
about giving actual figures? Ie I might expect the change in rate of the
crystal to be in the PPM range.

Post by Stuart Maclean
As you can imagine, I want to keep my Linux system time in line with,
i.e. disciplined from. my reference clock C.
Can chronyc do this? Do I have the appropriate set up for this to work?

Of course it can. You just need an appropriate driver to feed the time to a
shared memory segment (shm).

Post by Stuart Maclean
I must admit that all the talk of 'ref clocks' and 'locking' confuses
me no end. I have NO idea what my .conf file would look like.

Is this a commercial project? Ie, are you developing a device which you are
wanting to sell? Is that why you are as coy as you are?

Post by Stuart Maclean
Any help very gratefully appreciated. Apologies for the sparse details.

The sparser the details the worse the help will be.

Post by Stuart Maclean
Stuart
--
with "unsubscribe" in the subject.
with "help" in the subject.

[Stuart Maclean]

Bill, all,

there are 2.6 kernels and there are 2.6 kernels. That major.minor
version spans several years. I can assure you that in the 2.6.10 source
tree, there is no directory drivers/pps/.

This is not a commercial product no, it is for scientific research. My
clock is a Chip Scale Atomic Clock by a company called Symmetricom.

Currently my PPS driver is a Linux driver that I wrote. All I do when
the PPS interrupt fires is grab Linux system time and pass it back to a
user space program via a character device named /dev/csacpps.

My intent was that that program would also ready the serial line for the
CSAC's 'time counter since epoch', using a simple select+read+read main
loop, and place the two 'votes' for the correct current time (current
time meaning that instant when the CSAC's pps fired) in a SHM segment
that chronyc would read, and from there chrony would use adjtimex to
manipulate my system clock parameters so that, for a short time at
least, the system time would 'tick' at the same rate as the CSAC.

Like I said, I am not at all clued in to how one keeps a software clock
in sync with help from a device with much higher accuracy.

Stuart

Post by Bill Unruh
William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Stuart Maclean
I am essentially re-asking a question I posted to this list in early
2016 but never got a response I could understand, let alone implement.
My system is a legacy Linux 2.6.10 embedded system. There is no
/dev/pps* support in that kernel.

2.6 kernels certainly have pps support in the sense that modules for those
kernels can be loaded which read serial or GPIO lines and drive /dev/pps* from
that.
Look for modules kernel/drivers/pps/*

Post by Stuart Maclean
In my system there is no Internet access. I have a GPS device and a high
quality reference clock, call it C. At power up, I can sync C from the
GPS. GPS then goes away, my system is underwater for hours/days.

I am not sure what you mean by a "reference clock". What is it?

Post by Stuart Maclean
Clock C outputs a 'seconds-since-the-epoch string', call it S, if/when I
send it a 'request for time'. This two-ways comms is via serial

Serial communication is very slow. You basically cannot get better than
millisecond accuracy from a serial query.

Post by Stuart Maclean
(rs232). The transmission of S by C happens when C's next PPS signal
fires. That PPS signal is also available to me as a GPIO pin which is
configured to produce a system interrupt.

OK, you do have pps. Is the driver for that your own homegrown driver or is a
linux driver (like the pps-gpio module)?

Post by Stuart Maclean
I also have a cheap timer crystal, 32Khz, that serves as the default
'Linux system clock'. It is wildly inaccurate, and will slow
dramatically as my local water temperature changes (deeper water, lower
temperature). C is temperature compensated.

Yes, it would, although "wildly inaccurate is perhaps a bad
overstatement. How
about giving actual figures? Ie I might expect the change in rate of the
crystal to be in the PPM range.

Post by Stuart Maclean
As you can imagine, I want to keep my Linux system time in line with,
i.e. disciplined from. my reference clock C.
Can chronyc do this? Do I have the appropriate set up for this to work?

Of course it can. You just need an appropriate driver to feed the time to a
shared memory segment (shm).

Post by Stuart Maclean
I must admit that all the talk of 'ref clocks' and 'locking' confuses
me no end. I have NO idea what my .conf file would look like.

Is this a commercial project? Ie, are you developing a device which you are
wanting to sell? Is that why you are as coy as you are?

Post by Stuart Maclean
Any help very gratefully appreciated. Apologies for the sparse details.

The sparser the details the worse the help will be.

Post by Stuart Maclean
Stuart
--
with "unsubscribe" in the subject.
with "help" in the subject.

[Bill Unruh]

William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Stuart Maclean
Bill, all,
there are 2.6 kernels and there are 2.6 kernels. That major.minor version
spans several years. I can assure you that in the 2.6.10 source tree, there
is no directory drivers/pps/.
This is not a commercial product no, it is for scientific research. My clock
is a Chip Scale Atomic Clock by a company called Symmetricom.
Currently my PPS driver is a Linux driver that I wrote. All I do when the
PPS interrupt fires is grab Linux system time and pass it back to a user
space program via a character device named /dev/csacpps.

You could have your pps driver dump the time into an shm or a socket which
chrony can then read.

Post by Stuart Maclean
My intent was that that program would also ready the serial line for the
CSAC's 'time counter since epoch', using a simple select+read+read main loop,
and place the two 'votes' for the correct current time (current time meaning
that instant when the CSAC's pps fired) in a SHM segment that chronyc would
read, and from there chrony would use adjtimex to manipulate my system clock
parameters so that, for a short time at least, the system time would 'tick'
at the same rate as the CSAC.

Your system clock is sufficiently accurate that it can maintain time to better
than one second for a reasonable time period (minutes). Then the main thing is
to make sure that your system clock starts off with a time good to better than
a second, so you are sure that the seconds part of the time is correct. You
can do that from CSAC, from the network, or almost even from your wristwatch.
Thent he pps drives your system clock so that it is running accurately at the
same rate as the CSAC.

The "lock: option tells chrony that it should take the while seconds from that
source that you tell it to lock to , and the nanoseconds from the refclock
pps.

Post by Stuart Maclean
Like I said, I am not at all clued in to how one keeps a software clock in
sync with help from a device with much higher accuracy.

That is what chrony is for. It keeps adjusting the system clock rater (or
ratehr the translation between the ticking of the system oscillator and time)
to keep it in sync with the more accurate clock.

Post by Stuart Maclean
Stuart

Post by Bill Unruh
William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Stuart Maclean
I am essentially re-asking a question I posted to this list in early
2016 but never got a response I could understand, let alone implement.
My system is a legacy Linux 2.6.10 embedded system. There is no
/dev/pps* support in that kernel.

2.6 kernels certainly have pps support in the sense that modules for those
kernels can be loaded which read serial or GPIO lines and drive /dev/pps* from
that.
Look for modules kernel/drivers/pps/*

Post by Stuart Maclean
In my system there is no Internet access. I have a GPS device and a high
quality reference clock, call it C. At power up, I can sync C from the
GPS. GPS then goes away, my system is underwater for hours/days.

I am not sure what you mean by a "reference clock". What is it?

Post by Stuart Maclean
Clock C outputs a 'seconds-since-the-epoch string', call it S, if/when I
send it a 'request for time'. This two-ways comms is via serial

Serial communication is very slow. You basically cannot get better than
millisecond accuracy from a serial query.

Post by Stuart Maclean
(rs232). The transmission of S by C happens when C's next PPS signal
fires. That PPS signal is also available to me as a GPIO pin which is
configured to produce a system interrupt.

OK, you do have pps. Is the driver for that your own homegrown driver or is a
linux driver (like the pps-gpio module)?

Post by Stuart Maclean
I also have a cheap timer crystal, 32Khz, that serves as the default
'Linux system clock'. It is wildly inaccurate, and will slow
dramatically as my local water temperature changes (deeper water, lower
temperature). C is temperature compensated.

Yes, it would, although "wildly inaccurate is perhaps a bad overstatement. How
about giving actual figures? Ie I might expect the change in rate of the
crystal to be in the PPM range.

Post by Stuart Maclean
As you can imagine, I want to keep my Linux system time in line with,
i.e. disciplined from. my reference clock C.
Can chronyc do this? Do I have the appropriate set up for this to work?

Of course it can. You just need an appropriate driver to feed the time to a
shared memory segment (shm).

Post by Stuart Maclean
I must admit that all the talk of 'ref clocks' and 'locking' confuses
me no end. I have NO idea what my .conf file would look like.

Is this a commercial project? Ie, are you developing a device which you are
wanting to sell? Is that why you are as coy as you are?

Post by Stuart Maclean
Any help very gratefully appreciated. Apologies for the sparse details.

The sparser the details the worse the help will be.

Post by Stuart Maclean
Stuart
--
with "unsubscribe" in the subject.
with "help" in the subject.

--
"unsubscribe" in the subject.
subject.

[Miroslav Lichvar]

Post by Stuart Maclean
Currently my PPS driver is a Linux driver that I wrote. All I do when the
PPS interrupt fires is grab Linux system time and pass it back to a user
space program via a character device named /dev/csacpps.
My intent was that that program would also ready the serial line for the
CSAC's 'time counter since epoch', using a simple select+read+read main
loop, and place the two 'votes' for the correct current time (current time
meaning that instant when the CSAC's pps fired) in a SHM segment that
chronyc would read, and from there chrony would use adjtimex to manipulate
my system clock parameters so that, for a short time at least, the system
time would 'tick' at the same rate as the CSAC.

That could work. However, you will need to either combine the PPS
timestamp with the serial data, or provide two separate refclocks (one
PPS and one non-PPS) and let chronyd combine the data.

You would need to use the SOCK protocol for the later as SHM cannot
transport PPS-only samples. The chrony configuration would look like
this:

refclock SOCK /var/run/chrony.serial.sock refid CSAC noselect
refclock SOCK /var/run/chrony.pps.sock refid PPS lock CSAC

For development and debugging, it might help to have an additional
(NTP) source and mark both refclocks with noselect and disable the
lock to see if they work as expected.

In a pseudocode the program would do something like this:

fd1 = socket(AF_UNIX, SOCK_DGRAM, 0);
connect(fd1, {"/var/run/chrony.serial.sock"});
fd2 = socket(AF_UNIX, SOCK_DGRAM, 0);
connect(fd2, {"/var/run/chrony.pps.sock"});

gettimeofday(&sample.tv);
sample.offset = sample.tv - CSAC; // or negative value of that?
sample.pulse = 0;
sample.leap = 0;
sample.magic = SOCK_MAGIC;

send(fd1, &sample, sizeof sample, 0);

sample.tv_sec = pps_timestamp.tv_sec;
sample.tv_usec = pps_timestamp.tv_nsec / 1000;
sample.offset = pps_timestamp.tv_nsec / 1e9;
sample.pulse = 1;
sample.leap = 0;
sample.magic = SOCK_MAGIC;

send(fd2, &sample, sizeof sample, 0);

A working example for sending SOCK samples is here:
https://github.com/mlichvar/ntp-refclock/blob/master/sock.c

Does that help?

[Stuart Maclean]

Post by Miroslav Lichvar
That could work. However, you will need to either combine the PPS
timestamp with the serial data,

I thought that by setting BOTH the clockTimestampSec, from the Linux
system time at moment of PPS fire, AND the receiveTimestampSec, from the
CSAC's time value, that I WAS combining the PPS data with the serial
data ???

or provide two separate refclocks (one

Post by Miroslav Lichvar
PPS and one non-PPS) and let chronyd combine the data.

When you talk of a 'PPS refclock', does this mean that this 'refclock'
is fed samples of Linux system time, with those times corresponding to
PPS fire events from my CSAC?

Post by Miroslav Lichvar
You would need to use the SOCK protocol for the later as SHM cannot
transport PPS-only samples. The chrony configuration would look like
refclock SOCK /var/run/chrony.serial.sock refid CSAC noselect
refclock SOCK /var/run/chrony.pps.sock refid PPS lock CSAC
For development and debugging, it might help to have an additional
(NTP) source and mark both refclocks with noselect and disable the
lock to see if they work as expected.
fd1 = socket(AF_UNIX, SOCK_DGRAM, 0);
connect(fd1, {"/var/run/chrony.serial.sock"});
fd2 = socket(AF_UNIX, SOCK_DGRAM, 0);
connect(fd2, {"/var/run/chrony.pps.sock"});
gettimeofday(&sample.tv);
sample.offset = sample.tv - CSAC; // or negative value of that?
sample.pulse = 0;
sample.leap = 0;
sample.magic = SOCK_MAGIC;
send(fd1, &sample, sizeof sample, 0);
sample.tv_sec = pps_timestamp.tv_sec;
sample.tv_usec = pps_timestamp.tv_nsec / 1000;
sample.offset = pps_timestamp.tv_nsec / 1e9;
sample.pulse = 1;
sample.leap = 0;
sample.magic = SOCK_MAGIC;
send(fd2, &sample, sizeof sample, 0);
https://github.com/mlichvar/ntp-refclock/blob/master/sock.c
Does that help?

This is indeed VERY helpful. The above is code I can understand and use
going forwards. MUCH appreciated!

Cheers

Stuart

[Miroslav Lichvar]

Post by Stuart Maclean

Post by Miroslav Lichvar
That could work. However, you will need to either combine the PPS
timestamp with the serial data,

I thought that by setting BOTH the clockTimestampSec, from the Linux
system time at moment of PPS fire, AND the receiveTimestampSec, from the
CSAC's time value, that I WAS combining the PPS data with the serial
data ???

Yes, if the CSAC's timestamp always corresponds to the PPS timestamp.
If the message can be late, early, or missing completely, you would
need to be more careful with combining the data.

Have you tried this approach?

Post by Stuart Maclean
or provide two separate refclocks (one

Post by Miroslav Lichvar
PPS and one non-PPS) and let chronyd combine the data.

When you talk of a 'PPS refclock', does this mean that this 'refclock'
is fed samples of Linux system time, with those times corresponding to
PPS fire events from my CSAC?

The sample time is the system time when the PPS timestamp was captured
by the kernel and the offset is just a sub-second part of the
timestamp. The integer part of the offset is unknown.

[Stuart Maclean]

Hi again,

after reading your C code more thoroughly, I realized I am still not
understanding it all..

Post by Miroslav Lichvar
gettimeofday(&sample.tv);
sample.offset = sample.tv - CSAC; // or negative value of that?
sample.pulse = 0;
sample.leap = 0;
sample.magic = SOCK_MAGIC;

Your term 'CSAC' above, does that mean the 'seconds since epoch' string
that came over serial from the CSAC, converted to an int? If yes,
doesn't the exact time at which I do the gettimeofday then matter??

And I am wary of your comment. Would I want sample.tv - CSAC, or the
reverse? If you are confused by this, then I certainly am ;)

Post by Miroslav Lichvar
sample.tv_sec = pps_timestamp.tv_sec;
sample.tv_usec = pps_timestamp.tv_nsec / 1000;
sample.offset = pps_timestamp.tv_nsec / 1e9;
sample.pulse = 1;
sample.leap = 0;
sample.magic = SOCK_MAGIC;

Does 'pps_timestamp' above mean the Linux system time value I grabbed,
using the kernel api call do_gettimeofday(), in the interrupt handler
attached to the PPS event?

Finally, is there any requirement on how OFTEN I must get PPS events and
CSAC time strings? Will it all fail if I 'miss' or discard say a PPS?

Regards

Stuart

[Miroslav Lichvar]

Post by Stuart Maclean

Post by Miroslav Lichvar
gettimeofday(&sample.tv);
sample.offset = sample.tv - CSAC; // or negative value of that?
sample.pulse = 0;
sample.leap = 0;
sample.magic = SOCK_MAGIC;

Your term 'CSAC' above, does that mean the 'seconds since epoch' string
that came over serial from the CSAC, converted to an int?

Yes, it needs to be the number of seconds since 1970 as time_t.

Post by Stuart Maclean
If yes,
doesn't the exact time at which I do the gettimeofday then matter??

Only so much that chronyd will be able to assign the correct second to
the PPS timestamp. The sub-second offset between the PPS and non-PPS
samples needs to be smaller than 200 milliseconds.

Post by Stuart Maclean
And I am wary of your comment. Would I want sample.tv - CSAC, or the
reverse? If you are confused by this, then I certainly am ;)

I'm not sure :). You'll have to try. One will work, the other will
make the clock horribly unstable.

Post by Stuart Maclean

Post by Miroslav Lichvar
sample.tv_sec = pps_timestamp.tv_sec;
sample.tv_usec = pps_timestamp.tv_nsec / 1000;
sample.offset = pps_timestamp.tv_nsec / 1e9;
sample.pulse = 1;
sample.leap = 0;
sample.magic = SOCK_MAGIC;

Does 'pps_timestamp' above mean the Linux system time value I grabbed,
using the kernel api call do_gettimeofday(), in the interrupt handler
attached to the PPS event?

Yes.

Post by Stuart Maclean
Finally, is there any requirement on how OFTEN I must get PPS events and
CSAC time strings? Will it all fail if I 'miss' or discard say a PPS?

A missing sample is not a problem. I think the only requirement for
accepting PPS samples is that the last sample from the "locked"
refclock has to be newer than two seconds and this can be changed with
the maxlockage option.

Ideally, the number of samples per poll should not change much and
correspond to the number of samples set by the filter option on the
refclock line.

[Stuart Maclean]

Hi Miroslav, folks,

Post by Miroslav Lichvar
refclock SOCK /var/run/chrony.serial.sock refid CSAC noselect
refclock SOCK /var/run/chrony.pps.sock refid PPS lock CSAC

I started chronyd thus:

$ sudo ./chronyd -d

since I wanted to monitor any messages at the terminal.

2018-01-09T19:17:04Z chronyd version 2.3 starting (+CMDMON +NTP
+REFCLOCK -RTC -PRIVDROP -SCFILTER )

I then started, from a second terminal on my target system (an arm5
board), my own app which does the send() calls you had suggested.

Somewhat bizarrely, chronyd is complaining about the incoming data:

2018-01-09T19:17:44Z Could not read SOCK sample : Bad file descriptor

and this line repeats at a very high rate until I have to kill chronyd.

I can see in the sources that this is from routine read_sample in
refclock_sock.c. This is an I/O error, i.e. is occuring before the
contents of any data is even checked.

I am at a loss as to what exactly I did wrong.

Stuart

[Stuart Maclean]

An update to my earlier mail, which I now appreciate was low on details.
I added some debug, just printfs, to the chronyd sources...

If I start chronyd with the two 'refclock' lines in /etc/chrony.conf, I
see fds of 3 and 4 for the two sockets, which is fine. 3 is the
'serial' refclock socket and 4 is the 'pps' refclock socket.

Now, in my app, if I ONLY write to the pps socket, chronyd reads 32-byte
samples just fine. But as soon as I write to the serial socket, chronyd
now has a value for that fd not of 3 but of 1076014820. So somewhere
that fd is being corrupted.

I should also point out that if ONLY the serial refclock is defined in
/etc/chrony.conf, then reads from that socket DO work. It is the combo
of the TWO refclocks that is causing the serial refclock to become
corrupted, socket-wise.

I should point also that my target system is a legacy Linux 2.6.10. I
cross-compile for that board from an equally legacy arm-linux-gcc 3.4.0.
I did build chronyd with -Wall added to CFLAGS and didn't see any
warning that might suggest some pointer-to-struct issues.

Confused.

Stuart

Post by Stuart Maclean
Hi Miroslav, folks,

Post by Miroslav Lichvar
refclock SOCK /var/run/chrony.serial.sock refid CSAC noselect
refclock SOCK /var/run/chrony.pps.sock refid PPS lock CSAC

$ sudo ./chronyd -d
since I wanted to monitor any messages at the terminal.
2018-01-09T19:17:04Z chronyd version 2.3 starting (+CMDMON +NTP
+REFCLOCK -RTC -PRIVDROP -SCFILTER )
I then started, from a second terminal on my target system (an arm5
board), my own app which does the send() calls you had suggested.
2018-01-09T19:17:44Z Could not read SOCK sample : Bad file descriptor
and this line repeats at a very high rate until I have to kill chronyd.
I can see in the sources that this is from routine read_sample in
refclock_sock.c. This is an I/O error, i.e. is occuring before the
contents of any data is even checked.
I am at a loss as to what exactly I did wrong.
Stuart

[Miroslav Lichvar]

Post by Stuart Maclean

Post by Miroslav Lichvar
refclock SOCK /var/run/chrony.serial.sock refid CSAC noselect
refclock SOCK /var/run/chrony.pps.sock refid PPS lock CSAC

2018-01-09T19:17:04Z chronyd version 2.3 starting (+CMDMON +NTP
+REFCLOCK -RTC -PRIVDROP -SCFILTER )
2018-01-09T19:17:44Z Could not read SOCK sample : Bad file descriptor
and this line repeats at a very high rate until I have to kill chronyd.

This was a bug which broke the SOCK refclock when it was not specified
as the last refclock in the config. With two SOCK refclocks they both
cannot be the last refclock. The bug was fixed in chrony-2.4.

[Stuart Maclean]

Thanks to Miroslav's fantastic help, I think I have finally figured out
how to use chrony with my Chip Scale Atomic Clock on my embedded Linux
system.

I am just learning how to qualify how well I am keeping system time
aligned with my CSAC 'refclock' via chrony. I thought I would share my
preliminary results, so that experts could comment on the finer points
that I do not yet fully understand.

My /etc/chrony.conf is this

refclock SOCK /var/run/chrony.serial.sock refid CSAC noselect

refclock SOCK /var/run/chrony.pps.sock refid PPS lock CSAC


My results, after about 12 hours of chronyd running, are

$ ./chronyc sources
210 Number of sources = 2

MS Name/IP address Stratum Poll Reach LastRx Last sample

===============================================================================

#? CSAC 0 4 377 22 +344ns[ +326ns] +/-
30us
#* PPS 0 4 377 23 +16ns[ -2ns] +/-
30us

$ ./chronyc sourcestats
210 Number of sources = 2

Name/IP Address NP NR Span Frequency Freq Skew Offset
Std Dev
==============================================================================

CSAC 6 3 80 -0.009 0.009 -519ns
67ns
PPS 64 42 1009 +0.000 0.005 +2ns
3481ns

My own log file, which compares Linux system time at moment of my CSAC
PPS firing, is also showing me that my 'error' is within 30usec
consistently.

So far, my testing has been in a lab, with little or no temperature
fluctuation. My real system is an undersea instrument, so will have to
deal with substantial temperature changes, but I am hoping chrony is the
way to go.

I am hoping my experience might help others with similar local
refclocks. The actual code to feed chronyd with data over the SOCK
interface was quite straightforward, thanks to Miroslav's own example code.

Thanks all

Stuart

[Miroslav Lichvar]

Post by Stuart Maclean
My results, after about 12 hours of chronyd running, are
$ ./chronyc sourcestats
210 Number of sources = 2
Name/IP Address NP NR Span Frequency Freq Skew Offset
Std Dev
==============================================================================
CSAC 6 3 80 -0.009 0.009 -519ns
67ns
PPS 64 42 1009 +0.000 0.005 +2ns
3481ns

That looks good, but I'm wondering how is it possible that the CSAC
source is so stable and has such a small offset relative to the PPS.
Is your code combining the CSAC timestamp with the PPS timestamp? If
it was really that good, you could probably just the CSAC source
alone.

If it was a GPS NMEA source, you would see offset and jitter in
milliseconds.

[Stuart Maclean]

Hi Miroslav, all,

I'm including my code below to answer your question as why my CSAC data
source is apparently so good. To the best of my knowledge I am NOT
combining the CSAC data and PPS timestamps, but the code below should
answer that.

The CSAC data SOCK sample is composed thus:

char bufData[] = secs since epoch as a decimal string, read from the
CSAC over serial.

I should point out that the CSAC's time string ends with a \n, and that
I use the serial device tty in canonical mode, so my read is not
satisfied until ALL of the data is in the tty kernel layer. I normally
use canonical mode for line-oriented inputs as it simplifies user space
code, you just need one read, not many. Then:

int t = atoi( bufData );
struct sock_sample ss;
gettimeofday( &ss.tv, NULL );
ss.offset = -(ss.tv.tv_sec - t); // or negative value of that?
ss.pulse = 0;
ss.leap = 0;
ss._pad = 0;
ss.magic = SOCK_MAGIC;
send(fd1, &ss, sizeof ss, 0);



The 'Linux system time at CSAC PPS fire event' data SOCK sample is
composed thus:

char bufPPS[] = seconds and useconds of system time when PPS fired, as a
string in the form SSSS.UUUUUU, read from a char device.

Again, the string is ended by a \n, and again I use canonical mode and
hence need only a single read to get this string from kernel space back
to user space. Then:

int sysSecs, sysUsecs;
sscanf( bufPPS, "%u.%u", &sysSecs, &sysUsecs );
struct sock_sample ss;
ss.tv.tv_sec = sysSecs;
ss.tv.tv_usec = sysUsecs;
ss.offset = sysUsecs / 1e6;
ss.pulse = 1;
ss.leap = 0;
ss._pad = 0;
ss.magic = SOCK_MAGIC;
send(fd2, &ss, sizeof ss, 0);

Should I have relayed that time back to user space with nanosecond
resolution? I was just using microsecond resolution, and hence calling
do_gettimeofday() in the ISR in my device driver.

Given your comment about my CSAC data reflock being 'good enough on its
own', I may play with eliminating the PPS driver entirely.

Your comments welcomed.

Stuart

Post by Miroslav Lichvar

Post by Stuart Maclean
My results, after about 12 hours of chronyd running, are
$ ./chronyc sourcestats
210 Number of sources = 2
Name/IP Address NP NR Span Frequency Freq Skew Offset
Std Dev
==============================================================================
CSAC 6 3 80 -0.009 0.009 -519ns
67ns
PPS 64 42 1009 +0.000 0.005 +2ns
3481ns

That looks good, but I'm wondering how is it possible that the CSAC
source is so stable and has such a small offset relative to the PPS.
Is your code combining the CSAC timestamp with the PPS timestamp? If
it was really that good, you could probably just the CSAC source
alone.
If it was a GPS NMEA source, you would see offset and jitter in
milliseconds.

[Bill Unruh]

Post by Stuart Maclean
Hi Miroslav, all,
I'm including my code below to answer your question as why my CSAC data
source is apparently so good. To the best of my knowledge I am NOT
combining the CSAC data and PPS timestamps, but the code below should
answer that.
char bufData[] = secs since epoch as a decimal string, read from the
CSAC over serial.

That makes it even more obscure.
Does the above mean that the CSAC delivers only seconds, not milliseconds,
etc? If only seconds that could be fine to use in combination with pps, as it
would define the seconds for the pps. But serial is slow, and there is no way
you could get even ms out of a serial data line.

Post by Stuart Maclean
I should point out that the CSAC's time string ends with a \n, and that
I use the serial device tty in canonical mode, so my read is not
satisfied until ALL of the data is in the tty kernel layer. I normally
use canonical mode for line-oriented inputs as it simplifies user space
int t = atoi( bufData );
struct sock_sample ss;
gettimeofday( &ss.tv, NULL );
ss.offset = -(ss.tv.tv_sec - t); // or negative value of that?
ss.pulse = 0;
ss.leap = 0;
ss._pad = 0;
ss.magic = SOCK_MAGIC;
send(fd1, &ss, sizeof ss, 0);
The 'Linux system time at CSAC PPS fire event' data SOCK sample is
char bufPPS[] = seconds and useconds of system time when PPS fired, as a
string in the form SSSS.UUUUUU, read from a char device.

It is not clear what this is and where it comes from. The system time is a lot
more than 4 digits of seconds.

Post by Stuart Maclean
Again, the string is ended by a \n, and again I use canonical mode and
hence need only a single read to get this string from kernel space back
int sysSecs, sysUsecs;
sscanf( bufPPS, "%u.%u", &sysSecs, &sysUsecs );
struct sock_sample ss;
ss.tv.tv_sec = sysSecs;
ss.tv.tv_usec = sysUsecs;
ss.offset = sysUsecs / 1e6;
ss.pulse = 1;
ss.leap = 0;
ss._pad = 0;
ss.magic = SOCK_MAGIC;
send(fd2, &ss, sizeof ss, 0);
Should I have relayed that time back to user space with nanosecond
resolution? I was just using microsecond resolution, and hence calling
do_gettimeofday() in the ISR in my device driver.

nanoseconds is better and pps can deliver better than usec resolution.

Post by Stuart Maclean
Given your comment about my CSAC data reflock being 'good enough on its
own', I may play with eliminating the PPS driver entirely.
Your comments welcomed.
Stuart

Post by Miroslav Lichvar

Post by Stuart Maclean
My results, after about 12 hours of chronyd running, are
$ ./chronyc sourcestats
210 Number of sources = 2
Name/IP Address NP NR Span Frequency Freq Skew Offset
Std Dev
==============================================================================
CSAC 6 3 80 -0.009 0.009 -519ns
67ns
PPS 64 42 1009 +0.000 0.005 +2ns
3481ns

That looks good, but I'm wondering how is it possible that the CSAC
source is so stable and has such a small offset relative to the PPS.
Is your code combining the CSAC timestamp with the PPS timestamp? If
it was really that good, you could probably just the CSAC source
alone.
If it was a GPS NMEA source, you would see offset and jitter in
milliseconds.

--
with "unsubscribe" in the subject.
with "help" in the subject.

[Miroslav Lichvar]

Post by Stuart Maclean
Again, the string is ended by a \n, and again I use canonical mode and
hence need only a single read to get this string from kernel space back

The code looks good.

If the string has a constant length and you are effectivelly time
stamping the transmission of the \n character, I guess that could
explain the stability. I'm not sure about the small offset to the PPS
though. It's interesting.

If you can connect the board to the internet, I think it would be good
to add an NTP server to the config and verify that the PPS+CSAC
sources are in an agreement with that.

[Stuart Maclean]

Post by Miroslav Lichvar
The code looks good.
If the string has a constant length and you are effectivelly time
stamping the transmission of the \n character, I guess that could
explain the stability. I'm not sure about the small offset to the PPS
though. It's interesting.

I got intrigued by your observation that my read of the CSAC's 'seconds
since the epoch' string over a serial line was so stable. I realized I
had been doing my chrony testing with my system essential idle, which
may have been the reason for those serial line reads being so
'predictable'.

So I then got my embedded system to 'run' for real, which involves
reading from four other serial lines at between 1/5 and 1/2 Hz. This
gives the kernel more I/O channels to juggle. My chrony output is now

MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? CSAC 0 4 377 12 +969ns[ +693ns]
+/- 30us
#* PPS 0 4 377 10 -1055ns[-1334ns]
+/- 30us

210 Number of sources = 2
Name/IP Address NP NR Span Frequency Freq Skew Offset
Std Dev
==============================================================================
CSAC 6 3 80 -0.131 0.299 -2640ns
2307ns
PPS 18 12 274 -0.000 0.050 -1ns 4416ns

I am still just learning all these terms, but isn't 'Frequency' column
tracking the the variability in the 'offset' field of the sample SOCK
message that I send to chronyd when I get the CSAC string over serial?
If yes, it suggests that stressing my system with other serial reads
does indeed increase this frequency.

Is 'jitter' the same thing? i.e. the variability in the offset between
a refclock's time and local system time??

Stuart

[Bill Unruh]

William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Miroslav Lichvar
The code looks good.
If the string has a constant length and you are effectivelly time
stamping the transmission of the \n character, I guess that could
explain the stability. I'm not sure about the small offset to the PPS
though. It's interesting.

I got intrigued by your observation that my read of the CSAC's 'seconds since
the epoch' string over a serial line was so stable. I realized I had been
doing my chrony testing with my system essential idle, which may have been
the reason for those serial line reads being so 'predictable'.

I ssure would not expect to be stable, and would expect it to have a large
offset. It takes time to send a serial string. (at least number of digits x
9/baudrate) and if the number of digits changes, it will vary.

So I then got my embedded system to 'run' for real, which involves reading
from four other serial lines at between 1/5 and 1/2 Hz. This gives the kernel
more I/O channels to juggle. My chrony output is now
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? CSAC 0 4 377 12 +969ns[ +693ns] +/-
30us

I really have a hard time believing this above because of the above.

#* PPS 0 4 377 10 -1055ns[-1334ns] +/-
30us
210 Number of sources = 2
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
CSAC 6 3 80 -0.131 0.299 -2640ns 2307ns
PPS 18 12 274 -0.000 0.050 -1ns 4416ns
I am still just learning all these terms, but isn't 'Frequency' column
tracking the the variability in the 'offset' field of the sample SOCK message
that I send to chronyd when I get the CSAC string over serial?

Frequency is the offset of the system clock from the 1 sec/sec rate of the
UTC.

I am having trouble with all of the above. But maybe I just do not understand
what the CSAC is.

If yes, it suggests that stressing my system with other serial reads does
indeed increase this frequency.
Is 'jitter' the same thing? i.e. the variability in the offset between a
refclock's time and local system time??
Stuart
--
"unsubscribe" in the subject.
subject.

[Stephen Satchell]

Post by Stuart Maclean
As you can imagine, I want to keep my Linux system time in line with,
i.e. disciplined from. my reference clock C.
Can chronyc do this? Do I have the appropriate set up for this to work?
I must admit that all the talk of 'ref clocks' and 'locking' confuses
me no end. I have NO idea what my .conf file would look like.

I'm somewhat new to the chrony-users list, but let's look at your request.

1) "I also have a cheap timer crystal, 32Khz, that serves as the
default 'Linux system clock'. It is wildly inaccurate..."

There's a major part of your problem.

Chronyd, and ntpd for that matter, assume that the local clock has poor
absolute regulation, but good relative regulation -- that translates to
"the local clock is predictably bad." Yours has drift over temperature,
so any solution with chronyd or ntpd is bad news.

2) "Clock C outputs a 'seconds-since-the-epoch string', call it S,
if/when I send it a 'request for time'...C is temperature compensated."

So I come away with the impression that your Clock C can be depended on
for hours/days, far more so than your local clock.

Do I have that right, in a nutshell?

So the "correct" answer is to forget about using NTP protocol, and make
use of the seconds-since-epoch to correct your system clock. If you do
this frequently enough, you should avoid step issues. I would write my
own daemon that squats on the serial port. Assuming that the time is
transmitted once a second, you can then convert that string
appropriately, and use date(1) to set the system time. The last digit
of the time send should be useful as a "downbeat" for setting the local
clock. Python or Perl would be up to this task -- you don't have to
write it in C.

Does your embedded system have any applications that would be affected
by stepping time?