| Re: [chrony-users] Newbie Help Needed |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Thu, 11 Jan 2018, Stuart Maclean wrote:
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.
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.
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.
It is not clear what this is and where it comes from. The system time is a lot
more than 4 digits of seconds.
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.
nanoseconds is better and pps can deliver better than usec resolution.
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
On 01/11/2018 04:34 AM, Miroslav Lichvar wrote:
On Wed, Jan 10, 2018 at 12:06:00PM -0800, Stuart Maclean wrote:
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.
--
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.