[ntp:questions] Idea to improve ntpd accuracy

[Weber]

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 
sensitivity
====================================================================
Client/Server                    6us                
50us                    25us
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 
that topic.

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.

> Leon
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>