Back in January of this year, I posted my ntp scenario to this list: http://lists.ntp.org/pipermail/questions/2016-January/040609.html
I never got a reply I could understand. I am now revisiting the issue of using ntp to read from a shm segment, using driver 28. I populate that shm segment using a daemon of my own, call it D, thus: every 10 secs, my daemon D reads 'whole secs since the epoch' from a special hardware clock, call it HC. My daemon also reads PPS events from that same clock (imagine it being like a GPS device, it can output a PPS and a NMEA-like string containing a timestamp). I wrote a kernel device driver which sees the PPS as an interrupt on a GPIO pin and grabs system time and returns that as the read result of the PPS 'device' to daemon D. So my daemon gets a time value from the hardware clock AND a local Linux system time. I use these two to populate the fields of a single SHM struct which I write and NTP then reads. My ntp.conf is thus: server 127.127.28.2 minpoll 4 fudge 127.127.28.2 refid HC Things are kind-of working. I know without use of ntp, my system clock would drift from the HC time value. It would tick slow, and the drift is significant, seconds per hour. ntpd is getting my Linux system clock to stay within 25 ms of the HC reference time, but never any nearer. ntpq -p reports an offset of 25-26. My daemon D also reports the time grabs it gets from HC and system time at time of PPS, and it too reports a discrepancy of 25ms. I do not understand this 25ms 'barrier'? Anyone enlighten me? I suspect I am not using ntp correctly, with respect to how it expects to use a PPS signal. As I alluded to in my earlier email, our system is a legacy Linux 2.6.* kernel pre-dating linuxpps support. Any help appreciated. Stu _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
