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

[Chris Albertson]

I think this is the root cause of the problem.   The way you read the times
are "noisy"

Have you seen how the PPS driver works?  Use that as the model.  The PPS
reference clock seems to be about two orders of magnitude better even using
a PPS that is worse then your WR signal.  PPS uses a hardawar interrupt to
read the time from a CPU register.  THere is not system call to get the
time inside the handler, that would as you found add huge amounts (by TN
standards, huge being hundreds of uS) of uncertainty.

I think you need to time tag the the incoming data inside an interrupt
handler.  Place the ID of the packet and the captured nanosecond counter in
a memory based queue.  Then your user space driver reads from this queue.
 Your problem is time betenn the data and your call to get the time is
unknown and even could be interrupted.  THe hander for PPS is like this too
but the uncertainty is only about 2 uS.


On Sun, Sep 29, 2013 at 5:11 AM, Anders Wallin
<anders.e.e.wallin at gmail.com>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.
>



-- 

Chris Albertson
Redondo Beach, California