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

Chris Albertson albertson.chris at gmail.com
Sun Sep 29 12:00:53 EDT 2013


PTP generally is better if all your computers are on the same network.  But
as soon as you get into routing (using routers) you are going to be using
NTP.  But within an area under your control you can implement PTP and get
uS level timing.

NTP is really meant to distribute tim over a long/medium haul network that
means campus wide to world wide.  If you need to sync two computers in you
own lab PTP does well or your can moderatly abuse NTP by sending a PPS to
every computer via some back channel cable system.  If you can distribute
PPS then NTP can keep computers sysnc'd to the "few uS level" but if you
only have Ethernet connections NTP runs at the "few mS" level.

It all depends on what you need what is your source of time.  NTP's best
use is to sync time over a very wide area (up to word wide) using ZERO
special hardware.  PTP is for a much smaller local area (hundreds of meters
maybe?)

Again the grey, or overlap area is where you give each computer access to a
precision PPS and use NTP.  But I call this "mild abuse" because you are no
longer syncing two computers over a network, you are syncing both to GPS
while using the network as a backup and sanity check.


On Sun, Sep 29, 2013 at 8:07 AM, Eric Williams <wd6cmu at gmail.com> wrote:

> I've been hearing about PTP in a few places.  Does anyone here have
> experience with it to know if it would provide better performance in a
> situation like this?
>
>
> 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.
> >
> _______________________________________________
> 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


More information about the time-nuts mailing list