albertson.chris@gmail.com said:

This is time nuts.  It's always fair game to discuss how good things are
and/or how to make them better.  :)

The reference NTP package goes to a lot of work to figure out how far off the
clock is and tell the kernel so it can keep (much) better time.  In many
systems, that's a pretty good thermometer.

Another thing the reference package tries to do is stretch out the polling
interval to minimize load on the network and servers.  It's trying to find
the bottom of the ADEV curve.  The default range is 64-1024 seconds.  It
keeps track of it on disk to PPB.

That doesn't work very well if the temperature/frequency isn't stable.  The
temperature swing with load change has probably gotten worse with newer
machines.

It would be interesting to see what ntpd would do on a system with a very
good clock and/or what you could do to the code/heuristics to take advantage
of a stable clock.

Are you sure?  Or what's the current practice?

A while ago (several/many years?) it was common for Intel boxes to have a
clock generator chip.  They ran off the standard 14.xxx MHz crystal and
generated clocks for the CPU, PCI, USB, ...  It usually included the spread
spectrum hack.

The ARM SOC chips I've worked with had similar stuff on chip.  You connect up
a crystal.  It has an amplifier to make an oscillator and PLLs to make
whatever clocks are needed.

--
These are my opinions.  I hate spam.

On Thu, Dec 27, 2012 at 1:36 AM, Hal Murray hmurray@megapathdsl.net wrote:

I've read reports of people who have un-soldered the crystal from a
motherboard and replaced it with a connection to somethig much more
stable.  The result is a more stable clock adjustment but not a more
accurate NTP server.  The bottleneck is not the oscillator.  It is
the uncertiantly in the interrupt latency on the PPS.

If you want a much improved NTP server you need to build an external
nanosecond counter and then modify NTP and the OS to read this counter
rather than the internal one.    So this could not work on Windows or
any closed source OS.  Then you use a hardware latch to shapshot the
external counter when the PPS happens.    The current system does the
snapshot inside the interrupt handler, then sets a bit to indicate a
new sample is available, the captured count is read by the background
process.

Building a counter that runs at 1GHz is not to hard but connecting it
so the computer's OS can read it with very low latency is harder.
Maybe the counter is built on a PCI card?  It couldn't go on a USB
port

One idea that I like is to first get a large FPGA.  Then you load in a
"soft CPU" and then you run an OS and NTP on the soft CPU.  Inside
the softCPU the counter is implemented like it is in a real CPU but
you can add the ability for a PPS to "latch" it.  Basicaly you move
the interrupt handler to hardware.    The trick is if you can get
good enough performance out of the soft CPU?    There is some
intelectual property problems with some soft CPS but I'm pretty sure
there are free SPARC CPS you can use and SPARC is ideal for this as it
can run BSD Unix.

Chris Albertson
Redondo Beach, California

Hi

Much easier to simply use a cheap chip set (as in sub $3) that supports 1588 packet time stamping. It's doing everything you would need to do as far as packet time of arrival. The heavy lifting would all be in the area of porting that data into the NTP server.

Bob

On Dec 28, 2012, at 12:34 PM, Chris Albertson albertson.chris@gmail.com wrote:

On 12/28/12 9:34 AM, Chris Albertson wrote:

The LEON core for the SPARC V8 is free and available from gaisler.com.
The free version doesn't come with testbenches or support, but all the
source and documentation is there.  There's a fairly active mailing list
for support with participation by the guys who implemented the core.

It's a fairly easy "drop in" to either Xilinx or Actel FPGAs, and it's
configurable (e.g. if you don't want floating point you don't compile it
in).

There is are several prebuilt versions of *nix as well as RTEMS for the
core on the gaisler website as well.  There's a IPv4 stack for RTEMS,
derived from the BSD stack.

On 12/28/2012 12:34 PM, Chris Albertson wrote:

Most microcontrollers that I have seen (PIC, ARM, presumably AVR as
well) already have a peripheral called "input capture" that does exactly
this, and that's what my project is using. Since it's part of the timer
peripheral it usually runs at (up to) the same speed as the CPU which in
my case is 72MHz, plenty for a decent lock. It simply grabs the current
value of the counter when a pulse arrives and saves it until the CPU can
get around to retrieving it. To get another order of magnitude the next
step would be an analog TDC or a FPGA running a vernier TDC, but you can
get quite satisfactory results with just an off-the-shelf microcontroller.

Free CPU cores for FPGAs are not a problem, I have investigated a little
and come up with a few candidates. Right now my favorite would be a
microblaze clone called aemb, but there is also light8080 (tiny but
8-bit is a headache) and OpenRISC (fat but full-featured). There is a
free vernier TDC core as well that is made available by CERN. They are
using it in their White Rabbit system which does some rather neat things
with custom Ethernet transceivers and switches that can distribute time
across significant lengths of fiber to very good precision. I have not
yet dedicated enough time to finish wiring the TDC to a CPU but I have
made some progress; it synthesizes but is not yet operating correctly. I
will be the first to admit I am not very experienced with FPGAs but
given enough time and interest it can be made to work.

-- m. tharp

Hi

The only problem you may run into with an input capture is that the 72 MHz may be from an internal VCO that's locked to the external clock source or crystal. Often these micro's don't have VCO's that are as good a one might hope. You will indeed have less than 1 UI jitter, you may not have a whole lot less…

Bob

On Dec 31, 2012, at 10:56 PM, Michael Tharp gxti@partiallystapled.com wrote:

On Tue, 1 Jan 2013 11:23:57 -0500
Bob Camp lists@rtty.us wrote:

What about those uC that use a VCO that runs up at several 100MHz (i've
seen up to 800MHz) and devide it down to what they actually need.
Shouldnt this improve jitter quite considerably?

		Attila Kinali

--
There is no secret ingredient
-- Po, Kung Fu Panda

On 01/01/13 17:34, Attila Kinali wrote:

Many CMOS PLL solutions work like that. For instance, one chip I recall
has a ~2.4 GHz oscillator, divides that down on the output side and then
have input and feedback dividers as well. The benefit is that the tuning
range of the core VCO can be fairly low, and you get decent jitter that way.

For higher rates N-phase oscillators is used, typically 4-phase. Playing
tricks which how those phases are used can keep divider noises down when
doing fractional division rates.

Cheers,
Magnus

Hi

Most of the small micro's don't get very fancy on the clock chain. You are lucky if the VCO is running at twice the CPU clock. In some cases the input capture(s) (and PWM's)  are running directly on the VCO (at say 72 MHz) and the CPU is running at half  or a quarter of that.

Bob

On Jan 1, 2013, at 11:34 AM, Attila Kinali attila@kinali.ch wrote:

Hoi Bob,

On Tue, 1 Jan 2013 12:03:49 -0500
Bob Camp lists@rtty.us wrote:

That's why i was specifically asking about those uC which use a higher
frequency VCO for their clock generation. Ie not the tiny 8bit stuff,
but those in the ARM7/Cortex-M3 class.

		Attila Kinali

--
There is no secret ingredient
-- Po, Kung Fu Panda