[ntp:questions] Tracking the drift of a GPS clock relative to a HW clock

Unruh unruh-spam at physics.ubc.ca
Tue Jan 20 01:00:49 UTC 2009


ryad.bek at gmail.com writes:

>On Jan 19, 6:54=A0pm, Unruh <unruh-s... at physics.ubc.ca> wrote:

>> "your" gps clock does not drift. Your HW clock may drift.
>> The time sent out by GPS is accurate to a few nanoseconds. Your hardware
>> clock is not.

>Of course. I agree.

>> >hw clock (the clock that I would have obtained without GPS).
>> >My final goal is to convert a series of gps timestamps to the
>> >equivalent hw timestamps (with microsec precision).
>>
>> No idea what it is that you are trying to do.

>I want to compare the outputs of an application when this app is fed
>with GPS input & when it is fed with HW input
>HW input=3Dseries of ("HW timestamp" + event)
>GPS input=3Dseries of ("GPS timestamps" + event)

So feed it with time stamp inputs and see what it does. Why does it care if
they came from HW or GPS or were some random numbers you concocted?


>I want the same list of event. Only the timestamp can differ in the
>inputs.
>So I have to run the exeperience only once (i don't want to run an
>experience with GPS and an experience whithout GPS)

>The only way to do that is to invent a way to convert GPS timestamps
>to HW timestamps
>(i.e. the timestamps that would have been generated if the GPS was
>disabled)

???? Make them up.



>>
>> >1)My first idea was to recreate (off line) the hw timestamps by
>> >-inverting the NTP kernel clock discipline algorithm
>> >-feeding it with the loopstats statistics and my gps time series
>>
>> ??? It is a dissipative system. going backwards is highly unstable.

>It's just a conversion function F that I was thininking about: F: GPS
>timestamp -> HW timestamp.
>After conversion, the HW timestamps=3DF(GPS timestamps) should grows
>monotonically as the GPS ones.

It is monotonic. It is in general a very complicated function in detail.


>However after having read, an old post (on this mailing list) about
>the ntp disipline,
>I came to the conclusion that is too difficult to found out F.

>(So let's forget that).

>> >3)Is there a simple way to do that? It seems very simple but I'm not
>> >from the domain.
>> >Has a hw clock driver clock already been implemented to do such an
>> >operation?
>>
>> What operation?

>The operation to read the HW clock and to print its stats (especially
>offset!) in
>the peerstats file.
>From all these written offsets, i will have the drift and the job is
>done!

>However, it is not as simple as one can think,
>because it seems that ntp sync the hardware clock each 11 minutes:(
>This sync must be disabled.

>Is there a way to do that?
Sorry, you are confused. The computer when it is running does not use the
battery controlled real time clock at all. It uses a clock based on the
timer interrupts and the frequency of the CPU ( or the on board HPET
frequency standard) The RTC is completely and utterly ignored. It is that
which is "reset" every 11 min. That is different from the clock which the
computer actually uses while it runs. 

 So which one do you want. 

Ie, there is 
GPS time which is the true time defined for the world.
System time which the computer uses for all its operation and based on the
timer interrupt of the motherboard, and the cpu program clock. 
Real Time Clock which is a battery controlled clock which is used only to
set the system clock when the computer boots up and thereafter is
completely ignored. 







More information about the questions mailing list