On 05/25/2016 02:44 AM, Stuart Maclean wrote:
> Hi Pearly, thanks so much for your reply, the first one both seems to
> understand what I am trying to do AND that I can understand your points.
>
> I am guessing that 'clockTimestamp*' are the fields from the reference
> clock. Since my ref clock outputs whole seconds only, yes I set
> clockTimestampUsec and clockTimestampNsec to both zero. I have also
> just asserted that ntpd's shm code never writes to those values, so I am
> safe writing to them just once.
>
> When my daemon gets system time at time of ref clock PPS, my device
> driver supplies secs and usecs back to it(essentially the data that the
> device driver obtains with a do_gettimeofday right in the ISR attached
> to PPS event). I am not a fan of how ntp uses the term 'driver', since
> I am using device driver here also, to mean 'code in the Linux kernel'.
(Just nomenclatura. Cups has printer drivers, but the 'real' driver is
obviously an USB or parallel port or even serial line driver. It's a
matter of perspective... but when one is dealing with both levels, it
gets confusing very fast. I have no good solution for that...)
>
> So anyway, my daemon gets secs + usecs back from the PPS event. and I
> simply set them into the shmTime.receiveTimestampSec and
> shmTime.receiveTimestanpUSec respectively. I clamp my
> shmTime.receiveTimestampNsec to 0 throughout.
>
> So in fact I am only setting 3 of the 6 timestamp fields as non-zero:
> the clockTimestampSec, the receiveTimestampSec and the receiveTimestampUSec.
>
Makes perfect sense to me.
> I have precision = -20, leap = 0, samples = 3, though am not sure what
> each is supposedly doing.
>
> Performance is odd. I can see ntpd working 'slowly' to align system
> time to the reference, on the order of minutes, and that's fine. It
> just never gets any closer than ~26ms. Here's a snippet of my daemon's
> log, each time it grabs refclock time and PPS timestamps. You can see
> the ~26000 usec offset over time. By the way, my Linux system tick is
> 10ms, and my Linux clock crystal runs at 32Khz, so my linux system time
> resolution is about 30us as I understand it.
(So basically your precision is -16, not that it matters when we're away
from that by a factor of 10**3...)
>
> In my log, the 'Data' value is the reference clock. The PPS values
> (secs + usecs) are Linux system time at time of ref clock PPS, For this
> run, I had reduced my daemon main loop from 10 secs to 5 secs:
>
> 20160525004117982 Data: 1464136878, PPS 1464136877 973992
> 20160525004122987 Data: 1464136883, PPS 1464136882 973906
> 20160525004127982 Data: 1464136888, PPS 1464136887 973962
> 20160525004132986 Data: 1464136893, PPS 1464136892 974045
> 20160525004137980 Data: 1464136898, PPS 1464136897 973929
> 20160525004142985 Data: 1464136903, PPS 1464136902 973940
> 20160525004147979 Data: 1464136908, PPS 1464136907 974029
>
> Of course what i WANT ntpd to do is nudge that 974000 up to towards
> 000000, so that when the ref clock's PPS goes off, my system clock reads
> same time as next ref clock data output.
>
That does look pretty stable to me, and yes, the offset should go away.
Since you have your daemon feeding the SHM segment: What's the output of
NTPQ? (the general 'ntpq -pn' as well one where you can see the clock
and peer variables. That's 'ntpq -c "cv xxxx"' and 'ntpq -c "rv xxxx"',
where you can get the 'xxxx' from a 'ntpq -cas' and matching the lines
with the output ofg 'ntpq -crv')
The jitter and offset for your SHM segment provided by 'ntpq -pn' should
match the one you observe from your daemon's debug output. If there's a
discrepancy... I cannot start to suspect where this dead fish is rotting
away, but then it's basically between your acquisition daemon (and/or
it's output / debug output) and ntpq.
If the offset in 'ntpq -crv' is also 26ms, then I assume a different
kind of fish is decaying somewhere inside ntpd. While both aspects are
not exactly wonderful, you may pardon me for hoping it's not NTPD ;)
I'll be AFK and out-of-reach for some time to come, but I think that
trying to correlate the output of NTPQ with the output of your
acquisition daemon will provide further insight. Just don't feel shunted
when I'm unresponsive for some time ;)
Cheers,
Pearly
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
