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

[Brian Inglis]

 From what I've seen on the NTP groups, others' sites, and my own systems, 
refclocks must be polled frequently (maxpoll 4).
You will get a more jittery trace but much lower offset and jitter.

The current stable NTP GPS NMEA driver has added user mode PPS support for 
systems where a kernel PPS driver is unsupported, and how it does so may be 
worth a look, to get similar results from your PTP packets.

Help is available by subscribing to questions at lists.ntp.org.

You may also want to see whether you can use what the Linux PTP project offers.

On 2013-09-29 06:11, Anders Wallin wrote:
> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>