[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