[ntp:questions] A practical implementation for tracking the drift of a GPS clock relative to a non steered clock (& the associated results)

ryad.bek at gmail.com ryad.bek at gmail.com
Mon Jan 26 22:15:15 UTC 2009


On Jan 21, 3:39 pm, ryad.... at gmail.com wrote:
> Hello everybody,
>
> Following my previous post "Tracking the drift of a GPS clock relative
> to a HW clock"
> and the various comments I received,
>
> I've written an algorithm that converts a series of GPS timestamps in
> usec (obtained with a GPS Garmin 18 LVC steering the clock) to the
> equivalent unsychronized timestamps in usec (the timestamps that would
> have obtained w/o GPS on the same PC for the same experience).
>
> Seehttp://www-phare.lip6.fr/~kezadri/temp/tstamp_conv.html
>
> The algo implements Terje Mathisen's recommandation:
>
> "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".
>
> The algo is implemented in AWK. It runs on Linux and it is very easy.
>
> What I want to know (at the practical level) is:
>
> 1) Do you agree with this algo?
> From the curves I plot with gnuplot (see
> Seehttp://www-phare.lip6.fr/~kezadri/temp/tstamp_conv.html
> ), I can see a 1800ms skew for a half day experience
> which means ~42PPM. Does it proove that the algo is correct?
>
> 2)I'm choosing for the origin of time, the time when the experience
> begins
> (first record of the loopstats.pid file).
> But perhaps I've to wait a little before that the couple (ntp/GPS)
> enters in steady state.
>
> In this case, how many time have I have to wait (roughtly) to be sure
> that I've entered steady state: 10mn, 1hour, 1 day?
>
> 3)I've also read on the ntp.drift manpage that
> the very first time ntp is started, we must wait 2 days
> to have a corret drift file.
>
> In my personal case, I run the GPS only the day (because I must have
> my window opened for the GPS to see the sky).
> During the night, ntp only uses an external ntp startum-2 server to
> sychronize my PC clock.
> So my PC clock is successevly steered with a
> GPS(day), external ntp sever(night), GPS(day), external ntp server
> (night),... so and so on
> Is this a problem?
> In other words, do I have to let my window open and run my GPS all day
> & night long when my PC is running, even if we are in winter
> and it is very cold?
>
> The graphs results & the gnuplot instructions to graph the plots are
> available athttp://www-phare.lip6.fr/~kezadri/temp/tstamp_conv.html
> for who want to have a look.
>
> Regards
> Ryad
>
> ///////////////////ALGO///////////////////////
> (seehttp://www-phare.lip6.fr/~kezadri/temp/skew.awk)
>
>  #!/bin/sh
>
> #Plot the timestamps obtained when the clock is steerd by a GPS
> against the timestamps that would have been obtained w/o GPS
>
> #Input : the npd loopstats file generated when a GPS is steering the
> clock (example of configuration a PC+Garmin 18 LVC GPS/shmpps driver/
> ntpd)
> #Output: a series of records (T-steering, T-no steering). The name of
> the output file is the name of the loopstats file + suffix .skew
>
> #T-steering: timestamp (usec) obtained with GPS steering during an
> experience
> #T-nosteering: the theorical timestamp (usec) that would have been
> obtained for the same experience if the GPS was not there
>
> awk 'BEGIN{
>              daystart=0;
>              secstart=0;
>              t_prev = -1; freq_offest_prev = -1;
>              t_now  = -1; freq_offest_now  = -1;
>              nb_loop_records=0;
>              skew=0;
>           }
>           {
>              nb_loop_records++;
>              #the time origin is the instant when ntpd writes the
> first record of the loopstats file
>              if (nb_loop_records==1) {
>                 daystart = $1
>                 secstart = $2
>              }
>
>              #extract time and frequency offset
>              t_now = ($1 - daystart)* 86400.0 + ($2 - secstart);
>              freq_offest_now = $4 ;
>
>              if (nb_loop_records>1) {
>                 #integration (as I learn in primary school)
>                 skew=skew+(t_now - t_prev)*(freq_offest_now +
> freq_offset_prev)/2;//skew in usec
>              }
>
>              freq_offset_prev = freq_offset_now;
>              t_prev = t_now;
>
>              #generate a new record T-steering,T-nosteering
>              #I have added a third field (the timestamp
> difference=theorical skew in ms) if one wants to plot it
>              print t_now * 1000000 , t_now * 1000000 + skew , skew /
> 1000
>
>          }' $1 > $1.skew

The algo complies with David Mills's receipe:
http://support.ntp.org/bin/view/Support/HowToCalibrateSystemClockUsingNTP




More information about the questions mailing list