[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-hackers
Subject:    Re: [ntp:hackers] hackers] Intel's Galileo as NTP server?
From:       Dennis Ferguson <dennis.c.ferguson () gmail ! com>
Date:       2013-10-07 22:07:06
Message-ID: C89E636B-6C43-4426-9801-99E8EB4CCAED () gmail ! com
[Download RAW message or body]


On 6 Oct, 2013, at 02:49 , Hal Murray <hmurray@megapathdsl.net> wrote:
> david-taylor@blueyonder.co.uk said:
>> Using "normal" PCs I'm not convinced that you would see any difference
>> between the slightly more accurate 6T and other GPS modules.  We are looking
>> at the microsecond level in PCs (perhaps even greater in ARM boards), but
>> the differences are in the one-tenth microsecond level.  Having said that,
>> no I haven't played with the other boxes you mention. 
> 
> I think the PPS an ARM based system could be more accurate than a PC.
> 
> The trick is that most ARM SOCs have counter/timers that can be used to 
> capture the time without the delays of the interrupt processing.  The delay 
> itself isn't a problem.  It's the noise/jitter in the delay.  The counter 
> avoids that.
> 
> I don't know if any code does it that way.  If not, it would be an 
> interesting experiment.

I'm part way done supporting one like this with a Beaglebone Black
running a NetBSD kernel.  That SoC has a pulse-triggered timestamp capture
peripheral which samples from a 50 MHz clock, for a precision of +/- 10 ns,
and also has IEEE 1588 support sampling a 100 MHz clock which I would like
to use both on its own and to calibrate NTP.  I have some Trimble Resolution T
boards which cost less than $20 when I purchased them that I'd like to
use to construct an exceptionally accurate <$80 NTP server.

The problem which requires solution to do this well (or at all) relates
to the fact that while the peripherals provide quite precise timestamps
the clocks they acquire the timestamps from often aren't the clocks that
you would like to use as your system clock.  You can hence synchronize
the pulse capture peripheral's clock very closely to the device producing
the pulses, or the Ethernet interface's clock to the thing sending packets,
but this is of no use unless you can also transfer the time, with similar
precision, from those clocks to the system clock for use by applications.
There needs to be a way to deal with the adjustment of multiple, independent
clocks in a system and to make accurate measurements of one clock's time
against another's for the purpose of steering one towards the other.  Note
that on the BBB this isn't as hard as it might be because while all the
clocks run at different frequencies (I've been using the processor cycle
counter as the system clock) they are all derived from the same crystal,
but I didn't want to write code relying on that always being true since
the general case also includes things like PCI-attached ethernet MAC chips
or PCI pulse capture boards (I have one of those, too) which have entirely
independent clock sources.

The kernel PLL/FLL code is clearly not well suited to doing any of this, and it
wasn't clear how to make it so or whether it would even be worth while trying
to do that.  This resulted in consideration of how to not have the PLL code
in the kernel, instead providing an alternative mechanism for kernel clock
adjustment which would allow the PLL code to operate in user space as
effectively as it does in the kernel while simultaneously exposing multiple
clocks, only one of which is the system clock, for adjustment.  This is an
attempt to have one's cake while simultaneously eating it.  The working plan
is based on this

    http://www.mistimed.com/home/Clock.pdf

a rather over-long thing which was written based on stuff figured out
the last time I tried this.  It does try to tease adjustment mechanism
cleanly apart from adjustment policy (the PLL is policy, I think), and deals
with multiple clocks when that is what you've got.

Dennis Ferguson
_______________________________________________
hackers mailing list
hackers@lists.ntp.org
http://lists.ntp.org/listinfo/hackers
[prev in list] [next in list] [prev in thread] [next in thread]