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

[Anders Wallin]

On Mon, Sep 30, 2013 at 1:17 AM, Hal Murray <hmurray at megapathdsl.net> wrote:

>
> anders.e.e.wallin at gmail.com said:
> > 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);
> >  }
>
> Where did you get the 8 from?
> Each ntpd refclock has a 64 slot FIFO.  Every polling interval, ntpd
> processes the data in the buffer and turns it into a sample feed to the
> main
> algorithm.  That processing discards 1/3 of the samples as (potential)
> outliers and averages the rest.
> You had min/max poll set to 4 (16 seconds) so you are only giving ntpd 2
> samples to work with.
> So the first thing I would do is change the 8 to 1.  Then I'd fiddle with
> min/max poll to see what worked best.
>

Thanks! I did not know this and thought with "maxpoll 4" NTP will only read
the timestamps from memory every 16s, so updating them more often is not
useful. Apparently updating the timestamps with the SHM driver every second
(or even every 0.5 s?) is indeed useful. This is easy to change in my code.


> The next source of noise that I see is that time it takes to execute the
> time-reads may vary due to cache faults and may get interrupted.  Plan one
> would be:
>     gettimeofday(&tv0,NULL)
>     get_wr_time(&wr_tv);
>     gettimeofday(&tv1,NULL)
>     if (tv1-tv0 > xxx) try again
> You can get xxx from a calibration run.
>
> Plan two would be
>     gettimeofday(&tv,NULL)
>     get_wr_time(&wr_tv);
>     gettimeofday(&tv,NULL)
>     get_wr_time(&wr_tv);
> The first two will warm up the cache.  You will still get occasional
> interrupts, but ntp should filter them out.
>

again thanks for these tips. I guess NTP will not panic if I use the first
strategy and discard a few timestamp readings. There would then be a gap of
1 s or 2 s in the timestamp history. No new data is better than new noisy
data?



> --------
> Go back to the big picture.  What are you trying to do?  What sort of
> accuracy do you need?
> Is this a one-off project or do you need to run code on many systems using
> different hardware?
> Can you modify the code that needs accurate time to call get_wr_time rather
> than gettimeofday?  (Or patch the library so gettimeofday uses WR rather
> than
> calling the system?)
>

We are experimenting with using WR for time-distribution. WR is designed
for max 10km fiber-links but we are experimenting with a 1000km link :)
WR requires dedicated (open-source!) hardware and software and switches, as
well as a dedicated fiber or light-path in a CWDM or DWDM fiber network.
Infrastructure for NTP on the otherhand is 'everywhere'. Since a lot of
users don't need the precision (100ps) or accuracy (1ns) of WR, the
refclock driver is just a simple way to bridge WR<->NTP. It allows
GPS-independent NTP-servers to run wherever we have WR-network. I don't
have any particular accuracy spec for the NTP-server as a goal, I am just
experimenting - apprently getting within 50us of the refclock is already
quite good for NTP.

PTP over copper ethernet is another lower accuracy option for
re-distributing WR-time. But as mentioned it requires dedicated
network-cards and switches. We could bring WR-time into a switch that takes
10MHz and 1PPS inputs. Or Meinberg and the other PTP-hardware makers might
start to support WR directly.

Anders