Re: how to analyze clock drift

[Dennis Lee Bieber <wlfraed@ix.netcom.com>]

On Thu, 20 Nov 2014 02:10:53 +0100, Emanuel Berg <embe8573@student.uu.se>
declaimed the following:

>I have written a program [1] to get the data items
>that have been mentioned in different posts in this
>thread and in mails.
>
	Well -- it's not Ada...

>Does it make sense? If so, what do those digits tell
>you?
>

	Nothing without knowledge of the collection method.

	If you aren't using a separate, regulated, clock signal to trigger the
data collection you won't be able to determine clock drift.

	That is, something in the form of (pseudo-code) ...

	t0 = time.now() + msec * 2
	t1 = msec
	loop
		delay until t0 + t1
		ticks = clock()
		write(ticks)
		t1 = t1 + msec
	end loop

... is using the same clock for timing as you are trying to analyze...
Doesn't matter how much it drifts -- it is counting based upon some ticks
per second value. The only thing the collected numbers can give you is the
overhead, in clock ticks, from when the delay until "wakes up" to when the
clock() reads the actual clock. That delay can include OS overhead, process
scheduling (just because the delay expired doesn't mean this task
immediately gets CPU time -- there may be other higher priority tasks that
run before it; delay until only promises not to wake up BEFORE the
specified time).

	To determine clock /drift/ you need an external stable signal at some
known frequency, and either a CPU intensive busy-wait (and kick up your
priority so the OS doesn't get in the way <G>); or a relatively high
priority interrupt attached...

	loop
		// wait for external clock to go high
		while xclk.pin() = LOW loop null end loop
		// capture system clock
		ticks = clock()
		write(ticks)
		// wait for external clock to go back low
		while xclk.pin() = HIGH loop null end loop
	end loop
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/