On Tue, Nov 14, 2017 at 03:45:41PM -0500, Joe Smith wrote:
> I rebuilt chrony with --enable-debug and ran with -d -d Below is some
> output although I'm not 100% sure what it means. Tried looking at the
> source code to see if I could ascertain the cause but I was unable. I let
> it run for a bit
I have also not looked at the code recently but am suspicious. The time is
for example 1510691647.698064095 That is almost exactly half way between the
two seconds, and I think that the time needs to be within 1/4 sec of the top
of the second for chrony to think that there is a lock, and to start
I rebuilt chrony with --enable-debug and ran with -d -d Below is some
output although I'm not 100% sure what it means. Tried looking at the
source code to see if I could ascertain the cause but I was unable. I let
it run for a bit and here's some sample output. The pattern just seems to
repeat ove
On Tue, Nov 14, 2017 at 07:40:33AM -0500, Joe Smith wrote:
> Thank you for the quick response Bill... The PPS is coming in on /dev/pps1
> which is what I have in the refclock entry in my chrony.conf file. When run
> the cat command corresponding to that device I get:
>
> debian@beaglebone:~/ntp-gp
Thank you for the quick response Bill... The PPS is coming in on /dev/pps1
which is what I have in the refclock entry in my chrony.conf file. When run
the cat command corresponding to that device I get:
debian@beaglebone:~/ntp-gps-server/pps-overlay$ cat
/sys/devices/virtual/pps/pps1/assert
151066
