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

Bob Camp lists at rtty.us
Sun Sep 29 15:27:23 UTC 2013


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 <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.




More information about the Time-nuts_lists.febo.com mailing list