[ntp:questions] Re: Basic MSF clock setup

Jonathan Buzzard jonathan at uk.me.buzzard
Wed Nov 12 22:57:59 UTC 2003


In article <SAsf5UDVffs$Ew31 at nospam.oak-wood.co.uk>,
	Chris Hastie <chris at nospam.oak-wood.co.uk> writes:
> In message <dbiqob.b78.ln at 192.168.42.254>, Jonathan Buzzard
> <jonathan at uk.me.buzzard> writes


[SNIP]

>>
>>The best bet is to do some time pulse clock averaging in the SHM driver.
>>It improves jitter by an order of magnitude. Consider it a poor
>>man's PPS.
> 
> I'm not clear what this means. I presume its something that should be
> done in radioclkd*, or is it a configuration option for the SHM
> reference clock in ntp?

Take a look at the source for the latest radioclkd from my website.

What it means is if we have a good minutes worth of pulses, we take
the difference between the start of each second pulse and when the
computer clock thinks that second took place. Provided that they
are all reasonably close, we then take the arithmetic mean of the
closest thirty of them. Finally we take the received time and
add this averaged time difference of the pulse arrival times
over the last minute and pass this into the SHM segment as the
time we think the computer measured the start of the minute.

It is like a poor mans PPS ntpd driver. It should if working
properly give you an order of magnitude improvement in jitter
times over using just the time of the pulse at the the start of
the minute. Your jitter times should be much less than 1ms, in
the order of 0.1ms to 0.2ms If you have the equipment to tune
the antenna more precisely to 60kHz things also improve a bit
more.

> As far as I can make out, radioclkd2, which I'm using as I failed to get
> radioclkd to compile on FreeBSD yet, includes such averaging. Never the
> less, using the PPS driver as well does seem to improve clock stability,
> at least it reduces the mean offset and jitter relative to the SHM
> clock. I'm giving it a day or so in various configurations to try to
> work out which is best - though it would probably help if I properly
> understood all these numbers :) Are there features of radioclkd not
> present in radioclkd2 that mean I should be trying harder to figure out
> how to get it to compile on FreeBSD?

It does because it was Jon Atkins idea in the first place, though
the implementation in radioclkd was a fresh implementation. If
you ask me 200us accuracy for £30 is pretty dam good.

> 
> Many thanks for putting the details up.
> 

The strange thing is I did it on a whim really. Someone was
asking on uk.comp.os.linux about the posibility of using the
antenna, receiver and microprocessor from Maplin as a cheap
clock. I postulated that the microprocessor was a waste of
time, and a  "winclock" would be more than sufficient. I then
just though what the heck and order the bits up from Maplin,
fiddled around a bit with the design for a few weeks and then
about five months developing the software. I have not
done much with it since them and nothing really since
January this year because it basically works.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195



More information about the questions mailing list