[ntp:questions] Idea to improve ntpd accuracy
wsdl at osengr.org
Mon Feb 29 02:55:56 UTC 2016
I have some test results now with the interleaved symmetric mode in my
embedded NTP servers. Wow, what an improvement!
I used two independent embedded NTP servers (hardstamps on everything
done within the embedded boxes). These were connected to a network hub
along with an old 32-bit Pentium class PC running the current Fedora
release. There was initially nothing else on the hub, no external
network connection. The Linux box was configured as a symmetric peer to
the two embedded NTP boxes (interleave mode).
By hardstamps above, I mean that the interrupt signal from the NIC is
used to latch the time in a counter with 100ns resolution. The biggest
unknown is just exactly where in the UDP packet transmission/reception
process the interrupt is being generated. The NIC is a Wiznet W5500 and
they don't specify that anywhere in the docs I could find. I'm going to
see if they'll answer that question.
Here are the highlights:
Delay measurements made to the two embedded boxes by the Linux machine
are extremely stable, and sensitivity to network loading is practically
nil. The sensitivity numbers below are the changes that occur when an
internet connection is added to the originally isolated network hub.
NTP Mode Delay std dev Delay sensitivity Offset
Interleaved Symmetric 1us 3us <2us
I am able to move one of the NTP boxes onto another attached network hub
(one extra hop) and there is no discernible change in offset measured by
the Linux machine. I'm sure this would fall apart out on the real
internet but with just two local network hubs it is very robust.
The residuals now are so small that in tracking them down, I think one
would need to consider a lot of details in PC hardware, Linux kernel
code and the NIC used in the embedded NTP boxes. This is beyond the
level of accuracy that I care to achieve.
On 2/27/2016 9:11 PM, Leon McCalla wrote:
> I've been monitoring this thread for a while and i have a few comments.
> 1) I think on average the TX queue delay inside an ethernet card is going to be way smaller than the delay observed on the general internet. NTPd's primary algorithms compensate really well for jitter and delay already so the last order of magnitude expected to be gained by doubling the packets may not really materialize. A lot more could be gained by implementing QOS and making NTP packets the #1 priority.
> 2) Temp changes definitely affect the CPU clock speed and consequently NTP's accuracy. You can implement algorithms that compensate for ambient temperature but what about localized temperature such as load related temperature changes. Is the temp sensor really that close to the oscillator for consistent results? again this could vary from motherboard to motherboard.
My view of feed-foward on temperature (if you were going to do it) is
not to exactly and totally remove all temperature sensitivity. It is
instead to help the PLL out because it doesn't do well tracking
frequency ramps and feed-forward simply removes some of the ramp. I
don't think you would need to sense temperature exactly on the
frequency-determining, temperature-sensitive device (e.g. crystal), just
get close. The goal would be to remove a high percentage of the effect
(70-90% would be a reasonable goal I think) and let the PLL deal with
the left-overs. I also realize that this only becomes an issue with
temperature changes above a certain rate and that is totally dependent
on the environment. Useful in some situations and not in others.
There is another option which I purposely avoided earlier. I'll throw it
out just for giggles: Increase the order of the PLL -- conceptually by
adding another integrator in the feedback path -- and it will
theoretically be able to track frequency ramps w/o error. I would guess
that's a real big non-starter because so much work has gone into the
existing design and it would be a lot of work to change it and it would
be for questionable benefit. I'm not sure what sort of stability issues
would rear their ugly heads, and they might be formidable. So, I'm not
seriously suggesting this as a real option, it's just for fun. It also
illustrates the beauty of feed-forward -- it does not require changes to
the PLL design.
> I think the best way to really improve NTP's accuracy would be to focus on the development of an oven controlled oscillator combined with a 64bit latchable counter on a usb stick. A simple USB device, when mass produced, would bring any PC to nanosecond accuracy for a few dollars. Knowing that the demand is there, Maxim or Texas Instruments or one of those other large IC manufacturers may be willing to produce such a device based on an email from this group
Are there any latency issues with USB? I'm far from knowledgeable on
How about a motherboard with connector for a 10MHz frequency reference
from which the CPU clock would be derived? Connect that to a
GPS-disciplined clock and you're good to go.
> questions mailing list
> questions at lists.ntp.org
More information about the questions