Quoting Miroslav Lichvar <mlich...@redhat.com>:
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-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Reply via email to