Re: [chrony-dev] Frequency synchronization without phase

[Dan Drown <dan-ntp@xxxxxxxxx>]

Quoting Miroslav Lichvar <mlichvar@xxxxxxxxxx>:
> > I setup a quick benchmark of heating the CPU and on-board crystal with a
> > bunch of cpu wasting processes.  CPU core went from 51C to 70C (as measured
> > by the on-CPU temperature sensor):
> >
> > https://dan.drown.org/odroid/run5.7/tempcomp-cpuheating.png
> > The test of cpu heating actually turned out pretty well.  The tempcomp moves
> > ~400ppb while the tracking moves less than 100ppb.  The offset stays within
> > +/- 25us during this time (with a poll of its stratum 1 at 64s).
>
> So this was with 16s tempcomp update interval? I think with a shorter
> interval it might be even better. If your system is anything like
> mine, 16s would be too long to deal with spikes in the frequency when
> the CPU is loaded for short intervals. In this plot the frequency
> changes by more than 300 ppb in 30 seconds and then it takes about 2
> minutes to cool down.
>
> http://i.imgur.com/7rZJslH.png

Yeah, this is with a 16s tempcomp update interval.  One of the
problems is my system's time granularity is 1us.  So to get decent
results, I'm doing a linear estimation of the past 128 samples (1PPS)
every 16s.  I could try running that estimation more often or
lowering the number of samples it uses.  It's possible I'm filtering  
too much by using such a long sample length.

Another direction I'm considering is measuring the host's frequency
using PWM output on the host (~1PPS) and measuring that with the
microcontroller's timer.  That should give me a more precise
measurement, and it isn't affected by interrupt latency.



--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.