[time-nuts] refclock -> NTP server settings/tuning?

[Anders Wallin]

Thanks for all replies,

I can try changing maxpoll to a larger value and see if the trace is
smoother.

The refclock driver is a userspace C-program (daemon) that essentially does:
while(1) {
    gettimeofday(&tv,NULL) // system time, for NTP  receiveTimeStamp
    get_wr_time(&wr_tv); // WR time, for NTP clockTimeStamp
    // write tv and wr_tv to shared memory where NTP expects to see them
    sleep(8);
}

This may be the cause of a constant negative offset I see, since one
time-stamp is always read before the other. Perhaps this could be improved
by reading system time both before and after get_wr_time() and reporting
the average of the two readings as receiveTimeStamp? Or measure the offset
and put it as a "time1" offset-value in ntp.conf
If the driver was written as a kernel module, would that run with higher
priority and less variable delay?

I use the same piece of code to log how well system time tracks WR-time.
Here I sometimes see sudden spikes of 100s of microseconds. Could this be
caused by the OS context switching in the middle of my program between the
two timestamp-reading functions? Again, would this improve if the
time-logger was written as a kernel module, or is there some other way of
coding it that avoids context switches and keeps the two time-stamp reading
functions "atomic"?

Standard Ubuntu nowadays has a pre-packaged "lowlatency" kernel which I
think is RT-Preempt with some modifications. But I assume both the
refclock-driver and the logger would need a re-write to take advantage of
the RT-kernel. Does anyone have experienced with that?

thanks,
Anders