There is no choose. When you write an NTP reference clock if MUST be in
user space and in C. These are dynamically linked with ntpd.
However some of these NTP drives use devices that are implemented by kernal
level drivers. the PPS is a good example. The keral level device is
general purpose and can be used by any program, not just NTP. It is like
the kernals serial device driver, that can be used by NTP or "whatever"
I think in this case you need to use the same model, do the low level
tagging in the kernel driver. Read the PPS kernel driver. It is very
short and easy to understand
On Sun, Sep 29, 2013 at 3:17 PM, Hal Murray <hmur...@megapathdsl.net> wrote:
>
> anders.e.e.wal...@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.
>
> 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.
>
>
> > If the driver was written as a kernel module, would that run with higher
> > priority and less variable delay?
>
> Depends upon how it's written.
>
> > 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?
>
> My guess is that an interrupt is more likely than a user level context
> switch.
>
> --------
>
> 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?)
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
