20140926 – Playing with time again

So…

I havn’t really been playing with time-nuttery for a long time, other things happened in my life and my company, but I still have some pretty rad NTP servers I keep an eye on and so on.

Then in the middle of the debilitating heat-wave I got a call sort of out of the blue, if I wanted to spend some of the Linux Foundations money on NTP.org, with a unvoiced indication that this was a “post-HeartBleed” effort to make sure NTP wasn’t the next disaster. (It wasn’t, BASH was).

After some back and forth, the result is that LF, bless their deep pockets, throw USD 3000 at me every month, and I spend the time thus bought to make ntp.org’s software bettter.

I’m going to sorta-blog about this work here on my home page , and you can expect updates around weekends, since I do most of this work fri-sun.

Some kind of plan

I spent a couple of months going through a lot of the source code, and there is a lot of it: 100 KLOC, looking for bad news, and fortunately I only found a few minor nits, worrying, but not advisory material.

100.000 lines of code is insane for a program which basically steers your clock to some remote server, it can be done in 1000 lines if you really squeeze it.

At the end of my review, I concluded that trying to slim down the current monster would be a lot more work and effort than simply starting from scratch.

So that’s what I’m doing now.

I’ve set up a machine and written a little prototype where I can play around with things.

Here is the startup behaviour of a mock-up PLL, kicking a 8msec/50PPM clock into submission in 20 seconds and having the frequency figured out after a minute, using 8 second polls, to a local NTP server:

../../_images/20140926_fig1.png

After the first minute, I switch to 64 second poll rate:

../../_images/20140926_fig2.png

Here’s a zoom on one of the non-lucky packets:

../../_images/20140926_fig3.png

The current NTP filtering algorithm throws a fair bit of information away, for instance in this case, the packet only got delayed in on direction (red), the other direction ran as usuaul. But since we attempt to align the midpoints between the two local and two remote timestamps (blue), we end up with a input to the PLL which takes a hit from the delayed packet.

With a filter which considers the two directions separately, we could filter out-sided jitter like this.

I’m going to play with that…

phk