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 <[email protected]> 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 > <[email protected]>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 -- [email protected] > > To unsubscribe, go to > > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- [email protected] > 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 -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
