Hi PHP will provide better performance provided:
1) You have the custom hardware on both ends to run it 2) Everything in-between (switches / routers / firewalls …) is built to support it 3) It's all configured properly 4) Your OS fully supports it The point that you hit the wall in most setups is number 2 above. You need to log all the time delays for it to work. As soon as you get a significant congestion delay in a device (video streaming, OS update downloads …) things fall apart. When they fall apart you are right back to NTP performance. Bob On Sep 29, 2013, at 11: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. _______________________________________________ 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.
