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

ryad.bek at gmail.com ryad.bek at gmail.com
Tue Jan 20 19:43:15 UTC 2009


> >As a conclusion I can use them to estimate the skew (as you suggest
> >"by integrating ....and so on") over the last period (the period
> >between the last kernel update and now)
>
> I still have absolutely no idea what you are trying to do.
>

Here is what I want to do (I have reformulated my initial mail with
the corrections you brought):

I'm trying to track the drift of my GPS clock RELATIVE to
the clock that I would have obtained without GPS (and vice versa).

My final goal is to convert a series of gps timestamps to the
equivalent unsychronized timestamps.

As a result I would be able to test a new merging algorithm for
tcpdump traces.
This algorithm is robust because it is based on
special techniques (it uses common packets in the traces to provide
synchronisation).

So my algo works even if the PCs of the network are not synchronized.

Because this is a research work, I need to compare the solution of my
algo for an unsychronized network (no GPS installed)
with the results that I would have been obtained with a synchronized
network (in this case the PCs use GPS).

I want to do the timestamp conversion offline (ie, at the end of the
experience) and I want microsec precision
because the packet timestamps in the tcpdump trace are written in
microsecond.

I m sure a solution exists (as the one suggested by
"Terje Mathisen" & Unruh) :

1) Terje proposes two solutions a) and b):

a)Just enable logging of the loop frequency (i.e. the freq offset),
and
integrate that value over time. This gives you the offset at any given
time.

b)Alternatively it is in fact possible to run NTP with the corrections
disabled (or using the local clock as the reference) and then fundge
the
GPS to something like stratum 14 or 15. In this case the clockstats
file will probably log every single GPS
sample with the current offset between GPS and system clock.

2) In any cases, I can mathematically model  the drift as a constant
value (the concocted solution of Unruh?).
In this case, I won't use the real timestamps generated on my PCs but
it could be a possible solution if 1a) and 1b) don't work










More information about the questions mailing list