: [time-nuts] refclock - NTP server settings/tuning?
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
On Mon, Sep 30, 2013 at 1:17 AM, Hal Murray hmur...@megapathdsl.net wrote:
anders.e.e.wal...@gmail.com said:
The refclock driver is a userspace C-program (daemon) that essentially
does:
while(1) {
gettimeofday(tv,NULL) // system time, for NTP receiveTimeStamp
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,
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.wal...@gmail.comwrote:
Thanks for all replies,
I can try changing maxpoll
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
I think this is the root cause of the problem. The way you read the times
are noisy
Have you seen how the PPS driver works? Use that as the model. The PPS
reference clock seems to be about two orders of magnitude better even using
a PPS that is worse then your WR signal. PPS uses a hardawar
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
anders.e.e.wal...@gmail.com said:
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
Each ntpd refclock has a 64 slot FIFO. Every polling interval, ntpd
processes the data in the buffer and turns it into a sample feed to the main
algorithm. That processing discards 1/3 of the samples as (potential)
outliers and averages the rest.
Rats. I left out a critical step.
Every
There is no choose. When you write an NTP reference clock if MUST be in
user space and in C. These are dynamically linked with ntpd.
However some of these NTP drives use devices that are implemented by kernal
level drivers. the PPS is a good example. The keral level device is
general purpose
From what I've seen on the NTP groups, others' sites, and my own systems,
refclocks must be polled frequently (maxpoll 4).
You will get a more jittery trace but much lower offset and jitter.
The current stable NTP GPS NMEA driver has added user mode PPS support for
systems where a kernel PPS
[1] http://en.wikipedia.org/wiki/White_Rabbit
Sorry the correct link is
http://en.wikipedia.org/wiki/The_White_Rabbit_Project
:)
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
anders.e.e.wal...@gmail.com said:
and I get the following graph. The error is system time compared to WR-time,
where we can assume that WR-time is very accurate.
http://www.anderswallin.net/wp-content/uploads/2013/09/ntp_graph.png
That's probably as good as you are going to get with NTP.
I guess a LOT would depend on your driver and the interrupt latency in the
system.
The pulse per second system can work much better then you are getting even
when the PPS has far less accuracy then WR. I think because must of the
work for PPS happens inside a low latency handler that only runs
14 matches
Mail list logo
