Hi

We are using Linux ntpd with GPS/PPS reference clock to discipline the time
on our systems.

Our application requires good time accuracy (better than 5ms) but it also
needs to get there quickly (as quickly as possible, but ideally taking no
more than about 15 minutes).
(The Linux/ntpd is running on a remote embedded device that is frequently
restarted - possibly once a day or so - so we cant wait hours for
convergence).

Currently ntpd can take hours to achieve the desired acuracy.

So, the question is simple - is there any way to significantly speedup the
convergence of ntpd (using GPS/PPS reference clock)?

We would be prepared to compromise somewhat on accuracy and jitter.
(Currently accuracy and jitter values are excellent with jitter as low as 1
microsecond and accuracy better than 10 uS but it can take a day or two to
get there).

It does not seem unreasonable to expect that the ntpd could achieve the
required accuracy within 15 minutes or so - but nothing we have tried seems
to work.
Have tried modifying some of the tinker values, but we dont really
understand what they all do - and have not really had any success.

So to summarise:

1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
clock)?
2) If so, how - and what are the tradeoffs?

Any help appreciated
David

David McConnell wrote:
> Hi
> 
> We are using Linux ntpd with GPS/PPS reference clock to discipline the time
> on our systems.
> 
> Our application requires good time accuracy (better than 5ms) but it also
> needs to get there quickly (as quickly as possible, but ideally taking no
> more than about 15 minutes).
> (The Linux/ntpd is running on a remote embedded device that is frequently
> restarted - possibly once a day or so - so we cant wait hours for
> convergence).
> 
> Currently ntpd can take hours to achieve the desired acuracy.
> 
> So, the question is simple - is there any way to significantly speedup the
> convergence of ntpd (using GPS/PPS reference clock)?

If you are using a recent version of ntpd, start it with the "-g" 
switch.  That will cause it to set the clock to the correct time once 
only!  If you have a good drift file, you should be synchronized in 
thirty seconds or so and be within ten milliseconds, or less, of the 
correct time.

Try not to reboot unless absolutely necessary.  I realize that some 
versions of Windows need fairly frequent reboots but there are are 
versions that should run for many days or weeks between reboots.  My 
desktop system is W/XP SP2 and has been up for at least a couple of 
months and may stay up for another couple of months.

<snip>

Richard B. Gilbert wrote:

> 
> If you are using a recent version of ntpd, start it with the "-g" 
> switch.  That will cause it to set the clock to the correct time once 
> only!  If you have a good drift file, you should be synchronized in 
> thirty seconds or so and be within ten milliseconds, or less, of the 
> correct time.

My understanding was that -g turns off the 1000 second check for the 
first step, but still leaves the time within +/- 128ms, which will still 
take an unacceptable time to converge to +/- 5ms.  Certainly the 4.2.4p4 
documentation makes no claims for it beyond once only disabling the 1000 
second check.

> 
> Try not to reboot unless absolutely necessary.  I realize that some 
> versions of Windows need fairly frequent reboots but there are are 

I imagine this is some sort of embedded system, which he can't control, 
but might be switched off outside office hours, in part because that is 
the socially responsible thing to do.

[demime 1.01d removed an attachment of type multipart/signed]

Kevin Oberman wrote:
> [demime 1.01d removed an attachment of type multipart/signed]

This has failed to reach the newsgroup.

David Woolley wrote:
> Richard B. Gilbert wrote:
> 
>>
>> If you are using a recent version of ntpd, start it with the "-g" 
>> switch.  That will cause it to set the clock to the correct time once 
>> only!  If you have a good drift file, you should be synchronized in 
>> thirty seconds or so and be within ten milliseconds, or less, of the 
>> correct time.
> 
> My understanding was that -g turns off the 1000 second check for the 
> first step, but still leaves the time within +/- 128ms, which will still 
> take an unacceptable time to converge to +/- 5ms.  Certainly the 4.2.4p4 
> documentation makes no claims for it beyond once only disabling the 1000 
> second check.

I don't recall that +/- 128ms is specified anywhere.  If ntpd gets it's 
initial time from a hardware reference clock, the time SHOULD be very 
close.  This will, off course, depend on the latencies in the reference 
clock's response and the resolution of the time supplied.
<snip>

davidm@pipstechnology.co.uk (David McConnell) writes:

>Hi

>We are using Linux ntpd with GPS/PPS reference clock to discipline the time
>on our systems.

>Our application requires good time accuracy (better than 5ms) but it also
>needs to get there quickly (as quickly as possible, but ideally taking no
>more than about 15 minutes).
>(The Linux/ntpd is running on a remote embedded device that is frequently
>restarted - possibly once a day or so - so we cant wait hours for
>convergence).

>Currently ntpd can take hours to achieve the desired acuracy.

Are you using the -g option? What is the poll interval for your gps clock?
(Use 4 whcih I think is the default for gps clocks.)

ntp is NOT designed for rapid convergence, but on a gps clock with poll
interval 4 and -g it sure should be better than hours.


>So, the question is simple - is there any way to significantly speedup the
>convergence of ntpd (using GPS/PPS reference clock)?

>We would be prepared to compromise somewhat on accuracy and jitter.
>(Currently accuracy and jitter values are excellent with jitter as low as 1
>microsecond and accuracy better than 10 uS but it can take a day or two to
>get there).

>It does not seem unreasonable to expect that the ntpd could achieve the
>required accuracy within 15 minutes or so - but nothing we have tried seems
>to work.
>Have tried modifying some of the tinker values, but we dont really
>understand what they all do - and have not really had any success.

>So to summarise:

>1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
>clock)?
>2) If so, how - and what are the tradeoffs?

>Any help appreciated
>David

Richard B. Gilbert wrote:

> 
> I don't recall that +/- 128ms is specified anywhere.  If ntpd gets it's 
> initial time from a hardware reference clock, the time SHOULD be very 
> close.  This will, off course, depend on the latencies in the reference 
> clock's response and the resolution of the time supplied.
> <snip>


This is where it is documented in the source code for 4.2.4p4 
(ntpd/loopfilter.c):

  *      State   < step          > step          Comments
  *      ====================================================
  *      NSET    FREQ            step, FREQ      no ntp.drift
  *
  *      FSET    SYNC            step, SYNC      ntp.drift
  *

NSET is the initial state for a cold start.  FSET is the initial state 
for a warm start (ntp.drift) present.  For a fast start you don't want 
NSET.  Note that FSET goes to fully synchronised on one reading, but 
only steps the time if the offset is greater than the step limit, which 
normally 128ms.

Furthermore, in the branch that is conditioned thus:

         if (fabs(fp_offset) > clock_max && clock_max > 0) {

there is this comment:

                  * In S_FSET state the initial frequency has been set
                  * from the frequency file. Since the time is outside
                  * the step threshold, the clock is stepped immediately,
                  * rather than after the stepout interval. Guys get
                  * nervous if it takes 17 minutes to set the clock for
                  * the first time.
                  *

immediately followed by:

                         step_systime(fp_offset);

There is no step_systime in the else branch.  clock_max is the tinkered 
value of the parameter that defaults to 128ms.

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:

>Richard B. Gilbert wrote:

>> 
>> If you are using a recent version of ntpd, start it with the "-g" 
>> switch.  That will cause it to set the clock to the correct time once 
>> only!  If you have a good drift file, you should be synchronized in 
>> thirty seconds or so and be within ten milliseconds, or less, of the 
>> correct time.

>My understanding was that -g turns off the 1000 second check for the 
>first step, but still leaves the time within +/- 128ms, which will still 
>take an unacceptable time to converge to +/- 5ms.  Certainly the 4.2.4p4 
>documentation makes no claims for it beyond once only disabling the 1000 
>second check.

128ms at 500PPM is 250sec or 4 min. It will take longer than that since the
rate will not peg out, but it should not be hours.
Maybe it is best to set the clock initiallly so that it is out by by more
than 128ms (Eg advance it by 10 sec) and then use -g.



>> 
>> Try not to reboot unless absolutely necessary.  I realize that some 
>> versions of Windows need fairly frequent reboots but there are are 

>I imagine this is some sort of embedded system, which he can't control, 
>but might be switched off outside office hours, in part because that is 
>the socially responsible thing to do.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>David Woolley wrote:
>> Richard B. Gilbert wrote:
>> 
>>>
>>> If you are using a recent version of ntpd, start it with the "-g" 
>>> switch.  That will cause it to set the clock to the correct time once 
>>> only!  If you have a good drift file, you should be synchronized in 
>>> thirty seconds or so and be within ten milliseconds, or less, of the 
>>> correct time.
>> 
>> My understanding was that -g turns off the 1000 second check for the 
>> first step, but still leaves the time within +/- 128ms, which will still 
>> take an unacceptable time to converge to +/- 5ms.  Certainly the 4.2.4p4 
>> documentation makes no claims for it beyond once only disabling the 1000 
>> second check.

>I don't recall that +/- 128ms is specified anywhere.  If ntpd gets it's 
>initial time from a hardware reference clock, the time SHOULD be very 
>close.  This will, off course, depend on the latencies in the reference 
>clock's response and the resolution of the time supplied.
><snip>

ntp steps if the time is out by more than 128ms. If it is out by more than
1000 seconds it aborts. -g stops that abort once, presumably at intial
startup. Thus if at initial startup th etime is out by >128ms, it will step
the time ( to the correct time) and if the drift file is right, will then
run with that correct drift and the correct time. If it is out by <128ms it
will adjust the frequency to try to reduce that offset via the feedback
loop. Since the max rate is 500PPM if it is out by 128ms it will take min 4
min to adjust, but likely much longer. The max adjust depends on the poll
interval. Now for the refclocks I know, that is 4 (16s) so the time
constants in that feedback loop are about 4 min. if I recall correctly.
 (It is such that it is longer than the max time between data which is 
via the filter algorithm is one data point per 8 poll intervals. 
That is the time to reduce the error by about 1/e so it will take about 5
of those intervals or 20min. (Yes, I know it is not a simple exponential
falloff).
This is a design decision. And David will defend this "slow convergence"
"to the death". chrony is much faster, but does not do refclocks at all so
that is a useless option here. 

Unruh wrote:

> 
> 128ms at 500PPM is 250sec or 4 min. It will take longer than that since the
> rate will not peg out, but it should not be hours.

It will follow the normal transient response, which has a first zero 
crossing which I believe is at about 39 minutes for phase (RFC 1305) and 
rather longer for frequency).  I'm not sure, but it may well overshoot 
by more than 5ms, in which it could take rather longer to be acceptable 
to the OP.

It should get nowhere near being slew rate limited, so the 500ppm limit 
is academic.


> Maybe it is best to set the clock initiallly so that it is out by by more
> than 128ms (Eg advance it by 10 sec) and then use -g.

That would be my best trick, but if you have to use -g, you probably 
don't know the time well enough to be sure that adding 10 seconds won't 
actually put it in the 128ms band!

David Woolley wrote:

> 
> It will follow the normal transient response, which has a first zero 
> crossing which I believe is at about 39 minutes for phase (RFC 1305) and 
> rather longer for frequency).  I'm not sure, but it may well overshoot 

I think those figures are based on minpoll = 6.  If the reference clock 
accepts a shorter minpoll, the times may be correspondingly shorter.

Unruh wrote:
[]
> This is a design decision. And David will defend this "slow
> convergence" "to the death". chrony is much faster, but does not do
> refclocks at all so that is a useless option here.

chrony is also useless on Windows.

David 

Thanks for the responses.

We have tried -g and minpoll/maxpoll are by default 4 for the GPS reference
clock.
We even recompiled ntpd with source modified to allow poll at 2sec intervals
(minpoll=1) but this did not seem to make much difference.

We have also tried fiddling some of the "tinker" settings (step and stepout)
but this just seems to lead to instability.

Also, even if we set the time pretty much perfect (within 5ms offset), ntpd
appears to first *increase* the offset to well out of our spec, then correct
through zero offset - overshooting the other way (again well out of our
spec) and then typically crawls back in after which it is stable - and
ultimately wonderfully accurate and stable.

I was hoping that some of the other tinker parameters ("allan" or
"dispersion" for e.g.) might have an effect - but what are sensible values
to use?
I realise that this will compromise ntpd's performance in other ways, but,
we could tolerate worse final accuracey and jitter in exchange for getting
to within 5ms "quickly".

The driftfile also sometimes seems to do more harm than good - especially
after a reboot.

> -----Original Message-----
> From: questions-bounces+davidm=pipstechnology.co.uk@lists.ntp.org
> [mailto:questions-bounces+davidm=pipstechnology.co.uk@lists.ntp.org]On
> Behalf Of David McConnell
> Sent: 30 September 2008 14:04
> To: questions@lists.ntp.org; linuxpps@ml.enneenne.com
> Subject: [ntp:questions] Slow convergence of NTP with GPS/PPS
>
>
> Hi
>
> We are using Linux ntpd with GPS/PPS reference clock to
> discipline the time
> on our systems.
>
> Our application requires good time accuracy (better than 5ms)
> but it also
> needs to get there quickly (as quickly as possible, but
> ideally taking no
> more than about 15 minutes).
> (The Linux/ntpd is running on a remote embedded device that
> is frequently
> restarted - possibly once a day or so - so we cant wait hours for
> convergence).
>
> Currently ntpd can take hours to achieve the desired acuracy.
>
> So, the question is simple - is there any way to
> significantly speedup the
> convergence of ntpd (using GPS/PPS reference clock)?
>
> We would be prepared to compromise somewhat on accuracy and jitter.
> (Currently accuracy and jitter values are excellent with
> jitter as low as 1
> microsecond and accuracy better than 10 uS but it can take a
> day or two to
> get there).
>
> It does not seem unreasonable to expect that the ntpd could
> achieve the
> required accuracy within 15 minutes or so - but nothing we
> have tried seems
> to work.
> Have tried modifying some of the tinker values, but we dont really
> understand what they all do - and have not really had any success.
>
> So to summarise:
>
> 1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
> clock)?
> 2) If so, how - and what are the tradeoffs?
>
> Any help appreciated
> David
>
>
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
>

Would the following work with a reference clock?

Step 1. Force an initial step adjustment by running ntpd in "one-shot"
mode with -gq options and "tinker step 0.001" in the config file to
get below the 128ms step threshold.

Step 2. Restart ntpd in "normal mode" (without -gq and without "tinker
step 0.001" in the config file).

Unruh wrote:
> David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
>> My understanding was that -g turns off the 1000 second check for the 
>> first step, but still leaves the time within +/- 128ms, which will still 
>> take an unacceptable time to converge to +/- 5ms.  Certainly the 4.2.4p4 
>> documentation makes no claims for it beyond once only disabling the 1000 
>> second check.
> 
> 128ms at 500PPM is 250sec or 4 min. It will take longer than that since the
> rate will not peg out, but it should not be hours.
> Maybe it is best to set the clock initiallly so that it is out by by more
> than 128ms (Eg advance it by 10 sec) and then use -g.

Afair the 128 ms is also a 'tinker' configuration parameter, i.e. it 
should be possible to reduce it to 10 or 15 ms, at the cost of getting a 
few more steps during runtime.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Unruh wrote:
> davidm@pipstechnology.co.uk (David McConnell) writes:
> 
>> Hi
> 
>> We are using Linux ntpd with GPS/PPS reference clock to discipline the time
>> on our systems.
> 
>> Our application requires good time accuracy (better than 5ms) but it also
>> needs to get there quickly (as quickly as possible, but ideally taking no
>> more than about 15 minutes).
>> (The Linux/ntpd is running on a remote embedded device that is frequently
>> restarted - possibly once a day or so - so we cant wait hours for
>> convergence).
> 
>> Currently ntpd can take hours to achieve the desired acuracy.
> 
> Are you using the -g option? What is the poll interval for your gps clock?
> (Use 4 whcih I think is the default for gps clocks.)
> 
> ntp is NOT designed for rapid convergence, but on a gps clock with poll
> interval 4 and -g it sure should be better than hours.
> 
> 
>> So, the question is simple - is there any way to significantly speedup the
>> convergence of ntpd (using GPS/PPS reference clock)?
> 
>> We would be prepared to compromise somewhat on accuracy and jitter.
>> (Currently accuracy and jitter values are excellent with jitter as low as 1
>> microsecond and accuracy better than 10 uS but it can take a day or two to
>> get there).
> 
>> It does not seem unreasonable to expect that the ntpd could achieve the
>> required accuracy within 15 minutes or so - but nothing we have tried seems
>> to work.
>> Have tried modifying some of the tinker values, but we dont really
>> understand what they all do - and have not really had any success.
> 
>> So to summarise:
> 
>> 1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
>> clock)?
>> 2) If so, how - and what are the tradeoffs?
> 
>> Any help appreciated
>> David

On a COLD START, I would expect to have to wait for something like 
thirty minutes to get really TIGHT synchronization (5 milliseconds or 
less).  Once you have it, you should be able to hold it until you have a 
power failure or a hardware failure.

If you can't wait for synchronization, get a good UPS, a generator to 
back it up and NEVER shut down or reboot!

David Woolley wrote:
> Richard B. Gilbert wrote:
> 
>>
>> I don't recall that +/- 128ms is specified anywhere.  If ntpd gets 
>> it's initial time from a hardware reference clock, the time SHOULD be 
>> very close.  This will, off course, depend on the latencies in the 
>> reference clock's response and the resolution of the time supplied.
>> <snip>
> 
> 
> This is where it is documented in the source code for 4.2.4p4 
> (ntpd/loopfilter.c):
> 
>  *      State   < step          > step          Comments
>  *      ====================================================
>  *      NSET    FREQ            step, FREQ      no ntp.drift
>  *
>  *      FSET    SYNC            step, SYNC      ntp.drift
>  *
> 
> NSET is the initial state for a cold start.  FSET is the initial state 
> for a warm start (ntp.drift) present.  For a fast start you don't want 
> NSET.  Note that FSET goes to fully synchronised on one reading, but 
> only steps the time if the offset is greater than the step limit, which 
> normally 128ms.
> 
> Furthermore, in the branch that is conditioned thus:
> 
>         if (fabs(fp_offset) > clock_max && clock_max > 0) {
> 
> there is this comment:
> 
>                  * In S_FSET state the initial frequency has been set
>                  * from the frequency file. Since the time is outside
>                  * the step threshold, the clock is stepped immediately,
>                  * rather than after the stepout interval. Guys get
>                  * nervous if it takes 17 minutes to set the clock for
>                  * the first time.
>                  *
> 
> immediately followed by:
> 
>                         step_systime(fp_offset);
> 
> There is no step_systime in the else branch.  clock_max is the tinkered 
> value of the parameter that defaults to 128ms.

The above may mean something to YOU!  Sorry but I don't see it!

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:

>Unruh wrote:

>> 
>> 128ms at 500PPM is 250sec or 4 min. It will take longer than that since the
>> rate will not peg out, but it should not be hours.

>It will follow the normal transient response, which has a first zero 
>crossing which I believe is at about 39 minutes for phase (RFC 1305) and 
>rather longer for frequency).  I'm not sure, but it may well overshoot 
>by more than 5ms, in which it could take rather longer to be acceptable 
>to the OP.

>It should get nowhere near being slew rate limited, so the 500ppm limit 
>is academic.


>> Maybe it is best to set the clock initiallly so that it is out by by more
>> than 128ms (Eg advance it by 10 sec) and then use -g.

>That would be my best trick, but if you have to use -g, you probably 
>don't know the time well enough to be sure that adding 10 seconds won't 
>actually put it in the 128ms band!

It could but the chances are small if he has an rtc which is not completely
broken. If 10 sec is no good, use 10 years. That will make the chance of
being within 128ms of 10 years vanishngly small.

"David J Taylor" <david-taylor@blueyonder.neither-this-part.nor-this-bit.co.uk> writes:

>Unruh wrote:
>[]
>> This is a design decision. And David will defend this "slow
>> convergence" "to the death". chrony is much faster, but does not do
>> refclocks at all so that is a useless option here.

>chrony is also useless on Windows.

>David 

Agreed. It is AFAIK only useful on Linux.
It is an example however of a system which has faster response than ntp,
and has better clock control than ntp, without, afaik sacrificing
stability or anything else.

Terje Mathisen wrote:
> than 128ms (Eg advance it by 10 sec) and then use -g.
> 
> Afair the 128 ms is also a 'tinker' configuration parameter, i.e. it 
> should be possible to reduce it to 10 or 15 ms, at the cost of getting a 
> few more steps during runtime.

Yes it is, and you can tinker it down (but not up) without disabling 
other features (according to the documentation).  You would probably 
want to put it out at several standard deviations, to avoid bogus steps.

eugenemil@sbcglobal.net wrote:
> Would the following work with a reference clock?
> 
> Step 1. Force an initial step adjustment by running ntpd in "one-shot"
> mode with -gq options and "tinker step 0.001" in the config file to
> get below the 128ms step threshold.
> 
> Step 2. Restart ntpd in "normal mode" (without -gq and without "tinker
> step 0.001" in the config file).

I suspect this would work.

>The driftfile also sometimes seems to do more harm than good - especially
>after a reboot.

How stable is your temperature?  Are you rebooting a happy system?
(If so why?)  Or are you powering up a system that has been off
for the night?

If your drift file is off, I would expect things like this:
>  Also, even if we set the time pretty much perfect (within 5ms offset), ntpd
> appears to first *increase* the offset to well out of our spec, then correct
> through zero offset - overshooting the other way (again well out of our
> spec) and then typically crawls back in after which it is stable - and
> ultimately wonderfully accurate and stable.

If your temperature is unstable, I think you are going to have troubles
getting started cleanly.  (Note that CPU activity may influence your
temperature.)


Since you seem willing to hack the sources, I would suggest finding
the code where it does the once-only big step and making that do
small steps too, even if it wouldn't normally do a step.

That may not work, but it's what I would try first.


--
These are my opinions, not necessarily my employer's.  I hate spam.

David,

Your mission is seriously in jeopardy.

The NTP discipline loop has hard constraints on maximum sample rate 
(minimum poll interval) and loop dynamics. If you force the sample rate 
greater than one in 8 s, you violate the loop delay requirement and the 
loop WILL become unstable. There is no magic tinker that does what you 
want. The allan intercept tinker depends on the individual oscillator 
characteristics, not what you want it to do. See the briefings on the 
NPT project page.

You can redesign the loop for faster convergence, but that requires 
changing the seconds timer, which is a major overhaul of the timer 
facility. The loop constants in ntp_loopfilter.c would have to scale in 
the proper mathematical ratio. The equations are in my book. You will 
find the exponential term in the impulse responce equation will be your 
worst enemy.

Your "pretty much perfect" makes sense only if you have the same initial 
conditions, especially the frequency. If you just change the offset, the 
loop dynamics will induce a transient as you observed. The only true 
test is to let the daemon settle, then stop are restart it. It should be 
well within 5 ms for most modern systems.

It appears what you need to conform to a specifcation within a given 
offset within a given time. The NTP discipline can do that just fine as 
long as the initial conditions for the feedback loop are precisely 
known. If you change the offset outside the loop, you must recompute the 
frequency. However, when started for the first time or after a long 
period of absence, the loop has to relearn these conditions and that 
takes time. You can reduce this time be redesigning the loop, but then 
the loop becomes increasingly vulnerable to frequency instability.

 From your description I seriously doubt NTP in its present form is 
appropriate for your application.

Dave

David McConnell wrote:
> Thanks for the responses.
> 
> We have tried -g and minpoll/maxpoll are by default 4 for the GPS reference
> clock.
> We even recompiled ntpd with source modified to allow poll at 2sec intervals
> (minpoll=1) but this did not seem to make much difference.
> 
> We have also tried fiddling some of the "tinker" settings (step and stepout)
> but this just seems to lead to instability.
> 
> Also, even if we set the time pretty much perfect (within 5ms offset), ntpd
> appears to first *increase* the offset to well out of our spec, then correct
> through zero offset - overshooting the other way (again well out of our
> spec) and then typically crawls back in after which it is stable - and
> ultimately wonderfully accurate and stable.
> 
> I was hoping that some of the other tinker parameters ("allan" or
> "dispersion" for e.g.) might have an effect - but what are sensible values
> to use?
> I realise that this will compromise ntpd's performance in other ways, but,
> we could tolerate worse final accuracey and jitter in exchange for getting
> to within 5ms "quickly".
> 
> The driftfile also sometimes seems to do more harm than good - especially
> after a reboot.
> 
> 
>>-----Original Message-----
>>From: questions-bounces+davidm=pipstechnology.co.uk@lists.ntp.org
>>[mailto:questions-bounces+davidm=pipstechnology.co.uk@lists.ntp.org]On
>>Behalf Of David McConnell
>>Sent: 30 September 2008 14:04
>>To: questions@lists.ntp.org; linuxpps@ml.enneenne.com
>>Subject: [ntp:questions] Slow convergence of NTP with GPS/PPS
>>
>>
>>Hi
>>
>>We are using Linux ntpd with GPS/PPS reference clock to
>>discipline the time
>>on our systems.
>>
>>Our application requires good time accuracy (better than 5ms)
>>but it also
>>needs to get there quickly (as quickly as possible, but
>>ideally taking no
>>more than about 15 minutes).
>>(The Linux/ntpd is running on a remote embedded device that
>>is frequently
>>restarted - possibly once a day or so - so we cant wait hours for
>>convergence).
>>
>>Currently ntpd can take hours to achieve the desired acuracy.
>>
>>So, the question is simple - is there any way to
>>significantly speedup the
>>convergence of ntpd (using GPS/PPS reference clock)?
>>
>>We would be prepared to compromise somewhat on accuracy and jitter.
>>(Currently accuracy and jitter values are excellent with
>>jitter as low as 1
>>microsecond and accuracy better than 10 uS but it can take a
>>day or two to
>>get there).
>>
>>It does not seem unreasonable to expect that the ntpd could
>>achieve the
>>required accuracy within 15 minutes or so - but nothing we
>>have tried seems
>>to work.
>>Have tried modifying some of the tinker values, but we dont really
>>understand what they all do - and have not really had any success.
>>
>>So to summarise:
>>
>>1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
>>clock)?
>>2) If so, how - and what are the tradeoffs?
>>
>>Any help appreciated
>>David
>>
>>
>>_______________________________________________
>>questions mailing list
>>questions@lists.ntp.org
>>https://lists.ntp.org/mailman/listinfo/questions
>>

davidm@pipstechnology.co.uk (David McConnell) writes:

>Thanks for the responses.

>We have tried -g and minpoll/maxpoll are by default 4 for the GPS reference
>clock.
>We even recompiled ntpd with source modified to allow poll at 2sec intervals
>(minpoll=1) but this did not seem to make much difference.

>We have also tried fiddling some of the "tinker" settings (step and stepout)
>but this just seems to lead to instability.

>Also, even if we set the time pretty much perfect (within 5ms offset), ntpd
>appears to first *increase* the offset to well out of our spec, then correct
>through zero offset - overshooting the other way (again well out of our
>spec) and then typically crawls back in after which it is stable - and
>ultimately wonderfully accurate and stable.

That sounds like your drift rate in /etc/drift is way out, or that you do
not have such a file.



>I was hoping that some of the other tinker parameters ("allan" or
>"dispersion" for e.g.) might have an effect - but what are sensible values
>to use?
>I realise that this will compromise ntpd's performance in other ways, but,
>we could tolerate worse final accuracey and jitter in exchange for getting
>to within 5ms "quickly".



>The driftfile also sometimes seems to do more harm than good - especially
>after a reboot.

Yup it could do. This seems to be a problem.


>> -----Original Message-----
>> From: questions-bounces+davidm=pipstechnology.co.uk@lists.ntp.org
>> [mailto:questions-bounces+davidm=pipstechnology.co.uk@lists.ntp.org]On
>> Behalf Of David McConnell
>> Sent: 30 September 2008 14:04
>> To: questions@lists.ntp.org; linuxpps@ml.enneenne.com
>> Subject: [ntp:questions] Slow convergence of NTP with GPS/PPS
>>
>>
>> Hi
>>
>> We are using Linux ntpd with GPS/PPS reference clock to
>> discipline the time
>> on our systems.
>>
>> Our application requires good time accuracy (better than 5ms)
>> but it also
>> needs to get there quickly (as quickly as possible, but
>> ideally taking no
>> more than about 15 minutes).
>> (The Linux/ntpd is running on a remote embedded device that
>> is frequently
>> restarted - possibly once a day or so - so we cant wait hours for
>> convergence).
>>
>> Currently ntpd can take hours to achieve the desired acuracy.
>>
>> So, the question is simple - is there any way to
>> significantly speedup the
>> convergence of ntpd (using GPS/PPS reference clock)?
>>
>> We would be prepared to compromise somewhat on accuracy and jitter.
>> (Currently accuracy and jitter values are excellent with
>> jitter as low as 1
>> microsecond and accuracy better than 10 uS but it can take a
>> day or two to
>> get there).
>>
>> It does not seem unreasonable to expect that the ntpd could
>> achieve the
>> required accuracy within 15 minutes or so - but nothing we
>> have tried seems
>> to work.
>> Have tried modifying some of the tinker values, but we dont really
>> understand what they all do - and have not really had any success.
>>
>> So to summarise:
>>
>> 1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
>> clock)?
>> 2) If so, how - and what are the tradeoffs?
>>
>> Any help appreciated
>> David
>>
>>
>> _______________________________________________
>> questions mailing list
>> questions@lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/questions
>>

Hi,

just found this thread, after having not studied the list for quite a 
while. I have the exact same problem (have to be ready within minutes) 
and I also have an accurate (and meanwhile excellently working) PPS signal.

I understand that ntp is not designed for wild and fast changes, but to 
my understanding these are not always necessary, given pretty well 
defined startup-conditions like a reboot. Well, when I reboot my VIA 
epia 12000EG I experience right the phenomenon David described: ntpd 
sets the time pretty fast initially using the -g switch but then 
increases the offset a lot, turns around, shoots over 0 again and after 
a long time finally reaches a very high precision. This happens with and 
without a driftfile.

My plan was (well, IS - I just ordered it today..) to get a Soekris net 
4501 and maybe even an ovenized oscilator on an external board, since we 
have some tasks that simply depend on very precise time.

The option to just use an application that simply reads NMEA and PPS is 
of no use for me anymore (I had that plan in the very beginning), since 
we have to sync several devices to the GPS/PPS equipped unit.

So my question actually is: Is this initial variance part of the plan or 
do I have a chance to get around it with the Soekris board?

Best regards,
../nico berndt

nb@komeda-berlin.de (Nicola Berndt) writes:

>Hi,

>just found this thread, after having not studied the list for quite a 
>while. I have the exact same problem (have to be ready within minutes) 
>and I also have an accurate (and meanwhile excellently working) PPS signal.



>I understand that ntp is not designed for wild and fast changes, but to 
>my understanding these are not always necessary, given pretty well 
>defined startup-conditions like a reboot. Well, when I reboot my VIA 
>epia 12000EG I experience right the phenomenon David described: ntpd 
>sets the time pretty fast initially using the -g switch but then 
>increases the offset a lot, turns around, shoots over 0 again and after 
>a long time finally reaches a very high precision. This happens with and 
>without a driftfile.

Your frequency is off. But for a PPS signal you should set the poll
interval to the lowest possible 4. 
The convergence time is related to the poll interval. 
Anyway, what your behaviour indicates is that your system is starting with
the wrong notion of what the correct frequency is, and is hunting around to
find it. This is the fault of the ntp memoryless algorithm, since the first
three readings of the clock should give it a pretty good notion of what the
clock rate is. But ntp does not use that information in an efficient manner
at all. 



>My plan was (well, IS - I just ordered it today..) to get a Soekris net 
>4501 and maybe even an ovenized oscilator on an external board, since we 
>have some tasks that simply depend on very precise time.

??? This just means that that system is on all the time. Just leave your
pps attached computer on all the time and it will deliver times with an
accuracy of a few microseconds. Why you would want to pay for that
expensive device I do not know, unless you really need sub-microsecond
resolution. But then any of the clients will not get that anyway. Network
delays give you 10's of usec fluctuations. 


>The option to just use an application that simply reads NMEA and PPS is 
>of no use for me anymore (I had that plan in the very beginning), since 
>we have to sync several devices to the GPS/PPS equipped unit.

Why not? Just sync several devices to that GPS/PPS equipped unit. Go ahead.


>So my question actually is: Is this initial variance part of the plan or 
>do I have a chance to get around it with the Soekris board?

That board will do you absolutely no good at all if you then use it as the
time source for your server, unless you need ns long term resolution. NTP's
design, which David Mills strenuously sticks to,  has the design feature
that it is slow to converge. It is not necessary, but it was his design
decision. Chrony made a different design decision and converges far far
faster. Unfortunately, it works only on Linux and does not have any ability
to read atomic clocks (like PPS). But it is certainly proof of concept that
fast convergence is possible while disciplining the  computer clock to a
higher degree of accuracy than does ntp.


 



>Best regards,
>./nico berndt

Unruh schrieb:
>> I understand that ntp is not designed for wild and fast changes, but to 
>> my understanding these are not always necessary, given pretty well 
>> defined startup-conditions like a reboot. Well, when I reboot my VIA 
>> epia 12000EG I experience right the phenomenon David described: ntpd 
>> sets the time pretty fast initially using the -g switch but then 
>> increases the offset a lot, turns around, shoots over 0 again and after 
>> a long time finally reaches a very high precision. This happens with and 
>> without a driftfile.
>>     
>
> Your frequency is off. But for a PPS signal you should set the poll
> interval to the lowest possible 4. 
> The convergence time is related to the poll interval. 
> Anyway, what your behaviour indicates is that your system is starting with
> the wrong notion of what the correct frequency is, and is hunting around to
> find it. This is the fault of the ntp memoryless algorithm, since the first
> three readings of the clock should give it a pretty good notion of what the
> clock rate is. But ntp does not use that information in an efficient manner
> at all. 
>
>   
I see, that's too bad then.. :( I am already using minpoll 4 maxpoll 4
>   
>> My plan was (well, IS - I just ordered it today..) to get a Soekris net 
>> 4501 and maybe even an ovenized oscilator on an external board, since we 
>> have some tasks that simply depend on very precise time.
>>     
>
> ??? This just means that that system is on all the time. Just leave your
> pps attached computer on all the time and it will deliver times with an
> accuracy of a few microseconds. Why you would want to pay for that
> expensive device I do not know, unless you really need sub-microsecond
> resolution. But then any of the clients will not get that anyway. Network
> delays give you 10's of usec fluctuations. 
>
>
>   
No, the Soekris will run linux an d ntpd and the oscillator will just be 
on an external little board. The computer is residing in an airport 
hangar for MONTH sometimes with no powersource at all! There is 
absolutely no way to leavi it on, especially since it is a part of the 
airplane, wich has to be cut of even it's battery when unattended for a 
longer period.
>> The option to just use an application that simply reads NMEA and PPS is 
>> of no use for me anymore (I had that plan in the very beginning), since 
>> we have to sync several devices to the GPS/PPS equipped unit.
>>     
>
> Why not? Just sync several devices to that GPS/PPS equipped unit. Go ahead.
>
>
>   
Yes, one could do that, right. I must think about it. It takes away 
quite some freedom, though, meaning a bunch more cables that have to be 
attached to every unit OR writing something like gps that can sync to 
another computer. I am no programmer so I guess I will try hard not to 
do that.
>> So my question actually is: Is this initial variance part of the plan or 
>> do I have a chance to get around it with the Soekris board?
>>     
>
> That board will do you absolutely no good at all if you then use it as the
> time source for your server, unless you need ns long term resolution. NTP's
> design, which David Mills strenuously sticks to,  has the design feature
> that it is slow to converge. It is not necessary, but it was his design
> decision. Chrony made a different design decision and converges far far
> faster. Unfortunately, it works only on Linux and does not have any ability
> to read atomic clocks (like PPS). But it is certainly proof of concept that
> fast convergence is possible while disciplining the  computer clock to a
> higher degree of accuracy than does ntp.
>
>
>   
Well, all in all rather bad news for me. I must sit down and think of a 
good way out...

Thx for the hints and regards,
.../nico

nb@komeda-berlin.de (Nicola Berndt) writes:

>Unruh schrieb:
>>> I understand that ntp is not designed for wild and fast changes, but to 
>>> my understanding these are not always necessary, given pretty well 
>>> defined startup-conditions like a reboot. Well, when I reboot my VIA 
>>> epia 12000EG I experience right the phenomenon David described: ntpd 
>>> sets the time pretty fast initially using the -g switch but then 
>>> increases the offset a lot, turns around, shoots over 0 again and after 
>>> a long time finally reaches a very high precision. This happens with and 
>>> without a driftfile.
>>>     
>>
>> Your frequency is off. But for a PPS signal you should set the poll
>> interval to the lowest possible 4. 
>> The convergence time is related to the poll interval. 
>> Anyway, what your behaviour indicates is that your system is starting with
>> the wrong notion of what the correct frequency is, and is hunting around to
>> find it. This is the fault of the ntp memoryless algorithm, since the first
>> three readings of the clock should give it a pretty good notion of what the
>> clock rate is. But ntp does not use that information in an efficient manner
>> at all. 
>>
>>   
>I see, that's too bad then.. :( I am already using minpoll 4 maxpoll 4

OK, But that should have a convergence of minutes not hours. Mind you NTPs
habit of throwing away 7 out of 8 queries of the clock does not help.
(clock filter). Especially for a pps that is pretty extreme.

>>   
>>> My plan was (well, IS - I just ordered it today..) to get a Soekris net 
>>> 4501 and maybe even an ovenized oscilator on an external board, since we 
>>> have some tasks that simply depend on very precise time.
>>>     
>>
>> ??? This just means that that system is on all the time. Just leave your
>> pps attached computer on all the time and it will deliver times with an
>> accuracy of a few microseconds. Why you would want to pay for that
>> expensive device I do not know, unless you really need sub-microsecond
>> resolution. But then any of the clients will not get that anyway. Network
>> delays give you 10's of usec fluctuations. 
>>
>>
>>   
>No, the Soekris will run linux an d ntpd and the oscillator will just be 
>on an external little board. The computer is residing in an airport 
>hangar for MONTH sometimes with no powersource at all! There is 

Hard for it to be on all the time then. Or for it to have anthing like an
accurate time. And that ovenized oscillator will also be pretty useless (
much worse than the GPS) since it will have no power either and the crystal
will not be oscillating nor the oven keeping the temp constant. 


>absolutely no way to leavi it on, especially since it is a part of the 
>airplane, wich has to be cut of even it's battery when unattended for a 
>longer period.
>>> The option to just use an application that simply reads NMEA and PPS is 
>>> of no use for me anymore (I had that plan in the very beginning), since 
>>> we have to sync several devices to the GPS/PPS equipped unit.
>>>     
>>
>> Why not? Just sync several devices to that GPS/PPS equipped unit. Go ahead.
>>
>>
>>   
>Yes, one could do that, right. I must think about it. It takes away 
>quite some freedom, though, meaning a bunch more cables that have to be 
>attached to every unit OR writing something like gps that can sync to 
>another computer. I am no programmer so I guess I will try hard not to 
>do that.


>>> So my question actually is: Is this initial variance part of the plan or 
>>> do I have a chance to get around it with the Soekris board?
>>>     
>>
>> That board will do you absolutely no good at all if you then use it as the
>> time source for your server, unless you need ns long term resolution. NTP's
>> design, which David Mills strenuously sticks to,  has the design feature
>> that it is slow to converge. It is not necessary, but it was his design
>> decision. Chrony made a different design decision and converges far far
>> faster. Unfortunately, it works only on Linux and does not have any ability
>> to read atomic clocks (like PPS). But it is certainly proof of concept that
>> fast convergence is possible while disciplining the  computer clock to a
>> higher degree of accuracy than does ntp.
>>
>>
>>   
>Well, all in all rather bad news for me. I must sit down and think of a 
>good way out...

So, what you have is a free standing computer which must come out of a cold
shutdown (ie the oscillator frequency on startup will be way off its
frequency in steady state because it is cold) so will be far from
equilibrium. What is your time error requirement? Seconds, milliseconds,
microseconds? In such a situation ntp would probably give you a few
milliseconds. But it certainly is NOT designed to give you good accuracy in
such a situation during startup.  What are you finding?

Unruh schrieb:

>>>
>>>   
>> I see, that's too bad then.. :( I am already using minpoll 4 maxpoll 4
> 
> OK, But that should have a convergence of minutes not hours. Mind you NTPs
> habit of throwing away 7 out of 8 queries of the clock does not help.
> (clock filter). Especially for a pps that is pretty extreme.

Today I moved the computer to a different location to work there and I 
found it to set its clock right after start and keep it within ms-range! 
I didn't change anything, just shut down, drove there and turned it on, 
so I am really confused about that. Both locations are normal rooms with 
normal room-temerature. Well, I duplicated the system (that was why I 
was there..) and came back home with mine and tomorrow I will see if it 
behaves different again. Very very weird! It looks as if all of a sudden 
the driftfile was used and before not! This is also very strange, since 
the driftfile was (re)written yesterday, so ntp knew about it yesterday. 
My ntp.conf also includes the driftfile location.

>> No, the Soekris will run linux an d ntpd and the oscillator will just be 
>> on an external little board. The computer is residing in an airport 
>> hangar for MONTH sometimes with no powersource at all! There is 
> 
> Hard for it to be on all the time then. Or for it to have anthing like an
> accurate time. And that ovenized oscillator will also be pretty useless (
> much worse than the GPS) since it will have no power either and the crystal
> will not be oscillating nor the oven keeping the temp constant. 

Oh, so I got the word ovenized wrong: I understood it to be very immune 
against varying temperature. Ok, so if it needs an heater and all, it's 
useless in my case.

> 
> So, what you have is a free standing computer which must come out of a cold
> shutdown (ie the oscillator frequency on startup will be way off its
> frequency in steady state because it is cold) so will be far from
> equilibrium. What is your time error requirement? Seconds, milliseconds,
> microseconds? In such a situation ntp would probably give you a few
> milliseconds. But it certainly is NOT designed to give you good accuracy in
> such a situation during startup.  What are you finding?

Well, one thing I can of course always do is to boot hte machine, let it 
run for a flittle while and reboot it, so it boots with a warmed up 
oscillator. This would give trouble with the driftfile, though..

We target for millisecond accuracy. As I understand, the oscillators on 
standard PCs are mostly cheapest crap and there are way better 
oscillators I could use to replace the original. Is that correct?

What I saw today was pretty much, what I was looking for: No running 
away and stable within minutes. We also took a fan and heated up the 
oscillator. We could watch a slow drift with ntpq -p, but nothing too 
bad. It went away for a few ms and came back within minutes again.

I'll look into that tomorrow..

Regards,
.../nico

nb@komeda-berlin.de (Nicola Berndt) writes:

>Unruh schrieb:

>>>>
>>>>   
>>> I see, that's too bad then.. :( I am already using minpoll 4 maxpoll 4
>> 
>> OK, But that should have a convergence of minutes not hours. Mind you NTPs
>> habit of throwing away 7 out of 8 queries of the clock does not help.
>> (clock filter). Especially for a pps that is pretty extreme.

>Today I moved the computer to a different location to work there and I 
>found it to set its clock right after start and keep it within ms-range! 
>I didn't change anything, just shut down, drove there and turned it on, 
>so I am really confused about that. Both locations are normal rooms with 
>normal room-temerature. Well, I duplicated the system (that was why I 
>was there..) and came back home with mine and tomorrow I will see if it 
>behaves different again. Very very weird! It looks as if all of a sudden 
>the driftfile was used and before not! This is also very strange, since 
>the driftfile was (re)written yesterday, so ntp knew about it yesterday. 
>My ntp.conf also includes the driftfile location.

Sounds like the drift file was closer to being accurate. 


>>> No, the Soekris will run linux an d ntpd and the oscillator will just be 
>>> on an external little board. The computer is residing in an airport 
>>> hangar for MONTH sometimes with no powersource at all! There is 
>> 
>> Hard for it to be on all the time then. Or for it to have anthing like an
>> accurate time. And that ovenized oscillator will also be pretty useless (
>> much worse than the GPS) since it will have no power either and the crystal
>> will not be oscillating nor the oven keeping the temp constant. 

>Oh, so I got the word ovenized wrong: I understood it to be very immune 
>against varying temperature. Ok, so if it needs an heater and all, it's 
>useless in my case.

>> 
>> So, what you have is a free standing computer which must come out of a cold
>> shutdown (ie the oscillator frequency on startup will be way off its
>> frequency in steady state because it is cold) so will be far from
>> equilibrium. What is your time error requirement? Seconds, milliseconds,
>> microseconds? In such a situation ntp would probably give you a few
>> milliseconds. But it certainly is NOT designed to give you good accuracy in
>> such a situation during startup.  What are you finding?

>Well, one thing I can of course always do is to boot hte machine, let it 
>run for a flittle while and reboot it, so it boots with a warmed up 
>oscillator. This would give trouble with the driftfile, though..

>We target for millisecond accuracy. As I understand, the oscillators on 
>standard PCs are mostly cheapest crap and there are way better 
>oscillators I could use to replace the original. Is that correct?

But those cheap oscillators are actually pretty good. They have drifts of
the order of 10s of PPM (or paerhps up to 100PPM) and those are temp
sensitive. That is their main problem AFAIK. The temp sensitivity is
usually less than 1PPM/degree C.
The "way better oscillators" I think is primarily oscillators which are
temp controlled (yes heaters) and selected/adjusted.


>What I saw today was pretty much, what I was looking for: No running 
>away and stable within minutes. We also took a fan and heated up the 
>oscillator. We could watch a slow drift with ntpq -p, but nothing too 
>bad. It went away for a few ms and came back within minutes again.

>I'll look into that tomorrow..

>Regards,
>../nico

>We target for millisecond accuracy. As I understand, the oscillators on 
>standard PCs are mostly cheapest crap and there are way better 
>oscillators I could use to replace the original. Is that correct?

There are two parts to that "crap".

One is that the actual frequency doesn't match the number printed
on the can.  That's not a problem because the drift file corrects
for that type of error.

The other is that it may be highly temperature sensitive while
a more expensive crystal may be less so.  You can probably measure
that be heating up the box, perhaps by just running soem compute
intensive task rather than letting it sit mostly idle.

The suggestion for an external ovenized (OCXO) crystal/oscillator
was a way to avoid  the temperature shifts.  The basic idea
is that you run the crystal in an oven and have a mechanism to
keep it at a constant temperature.  (Warmer than normal is
easier to implement than keeping it at room temperature.  All
you need is a heater, no refrigerator.)

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Unruh wrote:

> The "way better oscillators" I think is primarily oscillators which are
> temp controlled (yes heaters) and selected/adjusted.
> 
Nowadays they are as likely to be TCXO's, temperature compensated 
crystal oscillators, in which the temperature is measured and used to 
drive a varicap diode, across the crystal, to compensate.  I think 
portable GPS receivers tend to use that approach.

In principle, you can also apply that compensation in software; you just 
need access to a thermistor that is thermally bonded to the crystal.

On Wed, 1 Oct 2008 10:24:22 GMT, David McConnell wrote:
>
> The driftfile also sometimes seems to do more harm than good - especially
> after a reboot.
Some kernels do a calibration of clock against RTC clock. This will make
driftfile misleading.
/hjj

>> The driftfile also sometimes seems to do more harm than good - especially
>> after a reboot.
>Some kernels do a calibration of clock against RTC clock. This will make
>driftfile misleading.

There is a bug in the Linux calibration routine for the TSC mode
clock.  It doesn't get a consistent answer.  I hacked the code
to loop and print the answer.  It was a splatter.  None were far
off unless you are a time keeping geek.  It's easy to see the
different drift results and startup transients are "interesting".

clocksource=acpi_pm on the boot command line might help.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


>>> The driftfile also sometimes seems to do more harm than good - especially
>>> after a reboot.
>>Some kernels do a calibration of clock against RTC clock. This will make
>>driftfile misleading.

>There is a bug in the Linux calibration routine for the TSC mode
>clock.  It doesn't get a consistent answer.  I hacked the code
>to loop and print the answer.  It was a splatter.  None were far
>off unless you are a time keeping geek.  It's easy to see the
>different drift results and startup transients are "interesting".

>clocksource=acpi_pm on the boot command line might help.

The recent kernels, especially if you have HPET enabled-- not used, just
enabled, are a complete disaster as far as the rtc is concerned. They poll
the rtc with something like a 16ms poll interval, since the second
transition interrupt is then grabbed by the HPET bios routing and not
delivered anywhere. This does not affect the system clock, but does affect
the rtc reading and setting. In fact at present, the rtc on a linux system
is essentially useless for any kind of time keeping or time setting. 


>-- 
>These are my opinions, not necessarily my employer's.  I hate spam.

Nicola Berndt wrote:
> Unruh schrieb:
> 
>>>>   
>>> I see, that's too bad then.. :( I am already using minpoll 4 maxpoll 4
>> OK, But that should have a convergence of minutes not hours. Mind you NTPs
>> habit of throwing away 7 out of 8 queries of the clock does not help.
>> (clock filter). Especially for a pps that is pretty extreme.
> 
> Today I moved the computer to a different location to work there and I 
> found it to set its clock right after start and keep it within ms-range! 
> I didn't change anything, just shut down, drove there and turned it on, 
> so I am really confused about that. Both locations are normal rooms with 
> normal room-temerature. Well, I duplicated the system (that was why I 
> was there..) and came back home with mine and tomorrow I will see if it 
> behaves different again. Very very weird! It looks as if all of a sudden 
> the driftfile was used and before not! This is also very strange, since 
> the driftfile was (re)written yesterday, so ntp knew about it yesterday. 
> My ntp.conf also includes the driftfile location.
> 
>>> No, the Soekris will run linux an d ntpd and the oscillator will just be 
>>> on an external little board. The computer is residing in an airport 
>>> hangar for MONTH sometimes with no powersource at all! There is 
>> Hard for it to be on all the time then. Or for it to have anthing like an
>> accurate time. And that ovenized oscillator will also be pretty useless (
>> much worse than the GPS) since it will have no power either and the crystal
>> will not be oscillating nor the oven keeping the temp constant. 
> 
> Oh, so I got the word ovenized wrong: I understood it to be very immune 
> against varying temperature. Ok, so if it needs an heater and all, it's 
> useless in my case.
> 
>> So, what you have is a free standing computer which must come out of a cold
>> shutdown (ie the oscillator frequency on startup will be way off its
>> frequency in steady state because it is cold) so will be far from
>> equilibrium. What is your time error requirement? Seconds, milliseconds,
>> microseconds? In such a situation ntp would probably give you a few
>> milliseconds. But it certainly is NOT designed to give you good accuracy in
>> such a situation during startup.  What are you finding?
> 
> Well, one thing I can of course always do is to boot hte machine, let it 
> run for a flittle while and reboot it, so it boots with a warmed up 
> oscillator. This would give trouble with the driftfile, though..
> 
> We target for millisecond accuracy. As I understand, the oscillators on 
> standard PCs are mostly cheapest crap and there are way better 
> oscillators I could use to replace the original. Is that correct?
> 

The clock in a PC is basically the guts of a cheap "Quartz" watch.  It 
wouldn't surprise me if the manufacturers bought the crystals rejected 
by the watch makers.  I suspect that the clock exists MOSTLY so the 
machine will have the correct date for things like letters and checks.

Replacing ANYTHING on the PC mother board will void your warranty.  It 
may also cause your PC to cease functioning!!

If you need a real clock in your PC, you can buy a board that plugs into 
the PCI bus and is equipped with an OCXO (Oven Controlled Xtal (Crystal) 
Oscillator).  Some will take a signal from GPS satellites and fine tune 
the crystal.  Such boards are available from Meinberg Funkurhen and
Symmetricom (BC635PCI/637PCI) for a great deal of money ($1200 to $2400 
US) the last time I looked.  If you have lots of money and need a REALLY 
accurate clock, even without full time access to GPS, you might want to 
look at these products.

I don't recall the model of the Meinberg board but I'm sure that their 
representative, who hangs out here, can supply it.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>Nicola Berndt wrote:
>> Unruh schrieb:
>> 
>>>>>   
>>>> I see, that's too bad then.. :( I am already using minpoll 4 maxpoll 4
>>> OK, But that should have a convergence of minutes not hours. Mind you NTPs
>>> habit of throwing away 7 out of 8 queries of the clock does not help.
>>> (clock filter). Especially for a pps that is pretty extreme.
>> 
>> Today I moved the computer to a different location to work there and I 
>> found it to set its clock right after start and keep it within ms-range! 
>> I didn't change anything, just shut down, drove there and turned it on, 
>> so I am really confused about that. Both locations are normal rooms with 
>> normal room-temerature. Well, I duplicated the system (that was why I 
>> was there..) and came back home with mine and tomorrow I will see if it 
>> behaves different again. Very very weird! It looks as if all of a sudden 
>> the driftfile was used and before not! This is also very strange, since 
>> the driftfile was (re)written yesterday, so ntp knew about it yesterday. 
>> My ntp.conf also includes the driftfile location.
>> 
>>>> No, the Soekris will run linux an d ntpd and the oscillator will just be 
>>>> on an external little board. The computer is residing in an airport 
>>>> hangar for MONTH sometimes with no powersource at all! There is 
>>> Hard for it to be on all the time then. Or for it to have anthing like an
>>> accurate time. And that ovenized oscillator will also be pretty useless (
>>> much worse than the GPS) since it will have no power either and the crystal
>>> will not be oscillating nor the oven keeping the temp constant. 
>> 
>> Oh, so I got the word ovenized wrong: I understood it to be very immune 
>> against varying temperature. Ok, so if it needs an heater and all, it's 
>> useless in my case.
>> 
>>> So, what you have is a free standing computer which must come out of a cold
>>> shutdown (ie the oscillator frequency on startup will be way off its
>>> frequency in steady state because it is cold) so will be far from
>>> equilibrium. What is your time error requirement? Seconds, milliseconds,
>>> microseconds? In such a situation ntp would probably give you a few
>>> milliseconds. But it certainly is NOT designed to give you good accuracy in
>>> such a situation during startup.  What are you finding?
>> 
>> Well, one thing I can of course always do is to boot hte machine, let it 
>> run for a flittle while and reboot it, so it boots with a warmed up 
>> oscillator. This would give trouble with the driftfile, though..
>> 
>> We target for millisecond accuracy. As I understand, the oscillators on 
>> standard PCs are mostly cheapest crap and there are way better 
>> oscillators I could use to replace the original. Is that correct?
>> 

>The clock in a PC is basically the guts of a cheap "Quartz" watch.  It 
>wouldn't surprise me if the manufacturers bought the crystals rejected 
>by the watch makers.  I suspect that the clock exists MOSTLY so the 
>machine will have the correct date for things like letters and checks.

>Replacing ANYTHING on the PC mother board will void your warranty.  It 
>may also cause your PC to cease functioning!!

>If you need a real clock in your PC, you can buy a board that plugs into 
>the PCI bus and is equipped with an OCXO (Oven Controlled Xtal (Crystal) 
>Oscillator).  Some will take a signal from GPS satellites and fine tune 
>the crystal.  Such boards are available from Meinberg Funkurhen and
>Symmetricom (BC635PCI/637PCI) for a great deal of money ($1200 to $2400 
>US) the last time I looked.  If you have lots of money and need a REALLY 
>accurate clock, even without full time access to GPS, you might want to 
>look at these products.

That was what he suggested. Unfortunately his computer must be switched
off, in hostile environments (eg winter) with no power at all for sometimes
months. Ie, the oven controlled crystal is pretty useless to bring up the
clock with accurate frequency and offset withing 10 of seconds to minutes of switchon.. 
I suspect an oven will take many minutes to hours to stabilize.
A termistor on the crystal on the other hand might be useful to compensate
the temperature ( there is an alteration of ntp which also calculates the
temp compensation of the crystal and uses that to calculate the required
drift rate.-- unfortunately I do not remember its name of location on the
web)

Unfortunately with ntp itself, even if he had gps, the fact thatt the drift
rate changes relatively rapidly on startup would still result in a offset
and overshoot by ntp. Since you could do a minpoll=maxpoll=4 it would be
relatively quick to settle in, but of course since ntp only uses 1/8 of the
measurements, that would be of the order of 5 min to settle down.






>I don't recall the model of the Meinberg board but I'm sure that their 
>representative, who hangs out here, can supply it.

>A termistor on the crystal on the other hand might be useful to compensate
>the temperature ( there is an alteration of ntp which also calculates the
>temp compensation of the crystal and uses that to calculate the required
>drift rate.-- unfortunately I do not remember its name of location on the
>web)

  NTP temperature compensation
  Mark Martinec, 2001-01-08
  http://www.ijs.si/time/temp-compensation/

A wonderful read.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Richard B. Gilbert wrote:

> The clock in a PC is basically the guts of a cheap "Quartz" watch.  It 
> wouldn't surprise me if the manufacturers bought the crystals rejected 
> by the watch makers.  I suspect that the clock exists MOSTLY so the 
> machine will have the correct date for things like letters and checks.

That describes the RTC, and may not even be valid for HPET systems.  The 
clock that ntpd disciplines is not based on a 32kHz watch crystal, but 
on a much higher frequency crystal.  Historically, the primary purpose 
of the latter crystal is to provide a logic clock for the processor and 
memory, not for time keeping.

Richard B. Gilbert wrote:
> I don't recall the model of the Meinberg board but I'm sure that their
> representative, who hangs out here, can supply it.

There are in fact several models, for PCI or PCI Express bus, and for
different time sources. See "Slot cards":
http://www.meinberg.de/english/products/formfactor.htm#slot_card

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Hal Murray schrieb:
> 
>> A termistor on the crystal on the other hand might be useful to compensate
>> the temperature ( there is an alteration of ntp which also calculates the
>> temp compensation of the crystal and uses that to calculate the required
>> drift rate.-- unfortunately I do not remember its name of location on the
>> web)
> 
>   NTP temperature compensation
>   Mark Martinec, 2001-01-08
>   http://www.ijs.si/time/temp-compensation/
> 
> A wonderful read.
> 
Really nice one, thx for the link!

Also thx to everyone thinking about a solution.

A good idea might be to find someone who would program GPS/PPS support 
for chrony. Many people would benefit from it. We also have a good 
programmer working with us and he is already looking into things..

I also have to further investigate the sudden change of behaviour I 
experienced and if I found the reason I will have to try to start the 
machine in a very cold room, on the heating and so on.. If it would 
settle down within 15 Minutes, we could live with it...

Regards,
.../nico

Unruh wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
>> Nicola Berndt wrote:
>>> Unruh schrieb:
>>>
>>>>>>   
>>>>> I see, that's too bad then.. :( I am already using minpoll 4 maxpoll 4
>>>> OK, But that should have a convergence of minutes not hours. Mind you NTPs
>>>> habit of throwing away 7 out of 8 queries of the clock does not help.
>>>> (clock filter). Especially for a pps that is pretty extreme.
>>> Today I moved the computer to a different location to work there and I 
>>> found it to set its clock right after start and keep it within ms-range! 
>>> I didn't change anything, just shut down, drove there and turned it on, 
>>> so I am really confused about that. Both locations are normal rooms with 
>>> normal room-temerature. Well, I duplicated the system (that was why I 
>>> was there..) and came back home with mine and tomorrow I will see if it 
>>> behaves different again. Very very weird! It looks as if all of a sudden 
>>> the driftfile was used and before not! This is also very strange, since 
>>> the driftfile was (re)written yesterday, so ntp knew about it yesterday. 
>>> My ntp.conf also includes the driftfile location.
>>>
>>>>> No, the Soekris will run linux an d ntpd and the oscillator will just be 
>>>>> on an external little board. The computer is residing in an airport 
>>>>> hangar for MONTH sometimes with no powersource at all! There is 
>>>> Hard for it to be on all the time then. Or for it to have anthing like an
>>>> accurate time. And that ovenized oscillator will also be pretty useless (
>>>> much worse than the GPS) since it will have no power either and the crystal
>>>> will not be oscillating nor the oven keeping the temp constant. 
>>> Oh, so I got the word ovenized wrong: I understood it to be very immune 
>>> against varying temperature. Ok, so if it needs an heater and all, it's 
>>> useless in my case.
>>>
>>>> So, what you have is a free standing computer which must come out of a cold
>>>> shutdown (ie the oscillator frequency on startup will be way off its
>>>> frequency in steady state because it is cold) so will be far from
>>>> equilibrium. What is your time error requirement? Seconds, milliseconds,
>>>> microseconds? In such a situation ntp would probably give you a few
>>>> milliseconds. But it certainly is NOT designed to give you good accuracy in
>>>> such a situation during startup.  What are you finding?
>>> Well, one thing I can of course always do is to boot hte machine, let it 
>>> run for a flittle while and reboot it, so it boots with a warmed up 
>>> oscillator. This would give trouble with the driftfile, though..
>>>
>>> We target for millisecond accuracy. As I understand, the oscillators on 
>>> standard PCs are mostly cheapest crap and there are way better 
>>> oscillators I could use to replace the original. Is that correct?
>>>
> 
>> The clock in a PC is basically the guts of a cheap "Quartz" watch.  It 
>> wouldn't surprise me if the manufacturers bought the crystals rejected 
>> by the watch makers.  I suspect that the clock exists MOSTLY so the 
>> machine will have the correct date for things like letters and checks.
> 
>> Replacing ANYTHING on the PC mother board will void your warranty.  It 
>> may also cause your PC to cease functioning!!
> 
>> If you need a real clock in your PC, you can buy a board that plugs into 
>> the PCI bus and is equipped with an OCXO (Oven Controlled Xtal (Crystal) 
>> Oscillator).  Some will take a signal from GPS satellites and fine tune 
>> the crystal.  Such boards are available from Meinberg Funkurhen and
>> Symmetricom (BC635PCI/637PCI) for a great deal of money ($1200 to $2400 
>> US) the last time I looked.  If you have lots of money and need a REALLY 
>> accurate clock, even without full time access to GPS, you might want to 
>> look at these products.
> 
> That was what he suggested. Unfortunately his computer must be switched
> off, in hostile environments (eg winter) with no power at all for sometimes
> months. Ie, the oven controlled crystal is pretty useless to bring up the
> clock with accurate frequency and offset withing 10 of seconds to minutes of switchon.. 
> I suspect an oven will take many minutes to hours to stabilize.
> A termistor on the crystal on the other hand might be useful to compensate
> the temperature ( there is an alteration of ntp which also calculates the
> temp compensation of the crystal and uses that to calculate the required
> drift rate.-- unfortunately I do not remember its name of location on the
> web)
> 
> Unfortunately with ntp itself, even if he had gps, the fact thatt the drift
> rate changes relatively rapidly on startup would still result in a offset
> and overshoot by ntp. Since you could do a minpoll=maxpoll=4 it would be
> relatively quick to settle in, but of course since ntp only uses 1/8 of the
> measurements, that would be of the order of 5 min to settle down.

Is it just my imagination or is he asking for something pretty 
unrealistic?  NTP will not do it.   Chrony might but I'm not familiar 
with it and can't say for sure.  Serious timekeeping equipment is 
generally operated 24x365 in a controlled environment.

To turn your equipment on after months of downtime and expect it to lock 
on to the correct time with millisecond accuracy within seconds is 
asking for a hell of a lot.

My best suggestion is to turn the thing on two or three days before he 
needs it!  Alternatively he could spend $50,000 US and up on an atomic 
clock of his very own. . . .

David Woolley wrote:
> Richard B. Gilbert wrote:
> 
>> The clock in a PC is basically the guts of a cheap "Quartz" watch.  It 
>> wouldn't surprise me if the manufacturers bought the crystals rejected 
>> by the watch makers.  I suspect that the clock exists MOSTLY so the 
>> machine will have the correct date for things like letters and checks.
> 
> That describes the RTC, and may not even be valid for HPET systems.  The 
> clock that ntpd disciplines is not based on a 32kHz watch crystal, but 
> on a much higher frequency crystal.  Historically, the primary purpose 
> of the latter crystal is to provide a logic clock for the processor and 
> memory, not for time keeping.

And it probably varies in frequency with temperature and age.  And 
probably no one cares if the frequency is off by a percent or two, 
especially if it's off on the high side.  Who is going to complain if 
his 2.4 GHz processor is actually operating at 2.45 GHZ??

>And it probably varies in frequency with temperature and age.  And 
>probably no one cares if the frequency is off by a percent or two, 
>especially if it's off on the high side.  Who is going to complain if 
>his 2.4 GHz processor is actually operating at 2.45 GHZ??

Actually, it's probably low.

If it was fast, you would be overclocking, maybe not by much, but
there is no longer any guarantee that your CPU will work.
[If it would work reliabily at x% faster, all the manufacturers
would bump things up a bit.]

Another reason it's probably slow is that almost everybody uses
spread sprectum clocking to reduce EMI, or rather to get past
the FCC regulation.  It doesn't reduce it, just spreads it around.
That's typically in the 1/2 % range, and it's slower to make sure
they don't break things by going faster.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
> Actually, it's probably low.

> If it was fast, you would be overclocking, maybe not by much, but
> there is no longer any guarantee that your CPU will work.  [If it
> would work reliabily at x% faster, all the manufacturers would bump
> things up a bit.]

Maybe... if they could also bump-up the price a bit. :) And then there
is binning...

rick jones
-- 
denial, anger, bargaining, depression, acceptance, rebirth...
                                     where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com  but NOT BOTH...

nb@komeda-berlin.de (Nicola Berndt) writes:

>Hal Murray schrieb:
>> 
>>> A termistor on the crystal on the other hand might be useful to compensate
>>> the temperature ( there is an alteration of ntp which also calculates the
>>> temp compensation of the crystal and uses that to calculate the required
>>> drift rate.-- unfortunately I do not remember its name of location on the
>>> web)
>> 
>>   NTP temperature compensation
>>   Mark Martinec, 2001-01-08
>>   http://www.ijs.si/time/temp-compensation/
>> 
>> A wonderful read.
>> 
>Really nice one, thx for the link!

>Also thx to everyone thinking about a solution.

>A good idea might be to find someone who would program GPS/PPS support 
>for chrony. Many people would benefit from it. We also have a good 
>programmer working with us and he is already looking into things..

I keep thinking about it, but I am not a good programmer, and first one has
to understand chrony well enough to start hacking it. What would be really
nice is to install a glue layer so one could simply take the ntp refclock
files and compile them into chrony. Unfortunately the ntp people did not
isolate the refclock behaviour terribly well, but it should be relatively
easy for a good programmer to write such glue ( chrony also has a
reasonably well issolated glue to the server querying stuff)



>I also have to further investigate the sudden change of behaviour I 
>experienced and if I found the reason I will have to try to start the 
>machine in a very cold room, on the heating and so on.. If it would 
>settle down within 15 Minutes, we could live with it...

>Regards,
>../nico

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>Unruh wrote:
>> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> 
>>> Nicola Berndt wrote:
>>>> Unruh schrieb:
>>>>
>>>>>>>   
>>>>>> I see, that's too bad then.. :( I am already using minpoll 4 maxpoll 4
>>>>> OK, But that should have a convergence of minutes not hours. Mind you NTPs
>>>>> habit of throwing away 7 out of 8 queries of the clock does not help.
>>>>> (clock filter). Especially for a pps that is pretty extreme.
>>>> Today I moved the computer to a different location to work there and I 
>>>> found it to set its clock right after start and keep it within ms-range! 
>>>> I didn't change anything, just shut down, drove there and turned it on, 
>>>> so I am really confused about that. Both locations are normal rooms with 
>>>> normal room-temerature. Well, I duplicated the system (that was why I 
>>>> was there..) and came back home with mine and tomorrow I will see if it 
>>>> behaves different again. Very very weird! It looks as if all of a sudden 
>>>> the driftfile was used and before not! This is also very strange, since 
>>>> the driftfile was (re)written yesterday, so ntp knew about it yesterday. 
>>>> My ntp.conf also includes the driftfile location.
>>>>
>>>>>> No, the Soekris will run linux an d ntpd and the oscillator will just be 
>>>>>> on an external little board. The computer is residing in an airport 
>>>>>> hangar for MONTH sometimes with no powersource at all! There is 
>>>>> Hard for it to be on all the time then. Or for it to have anthing like an
>>>>> accurate time. And that ovenized oscillator will also be pretty useless (
>>>>> much worse than the GPS) since it will have no power either and the crystal
>>>>> will not be oscillating nor the oven keeping the temp constant. 
>>>> Oh, so I got the word ovenized wrong: I understood it to be very immune 
>>>> against varying temperature. Ok, so if it needs an heater and all, it's 
>>>> useless in my case.
>>>>
>>>>> So, what you have is a free standing computer which must come out of a cold
>>>>> shutdown (ie the oscillator frequency on startup will be way off its
>>>>> frequency in steady state because it is cold) so will be far from
>>>>> equilibrium. What is your time error requirement? Seconds, milliseconds,
>>>>> microseconds? In such a situation ntp would probably give you a few
>>>>> milliseconds. But it certainly is NOT designed to give you good accuracy in
>>>>> such a situation during startup.  What are you finding?
>>>> Well, one thing I can of course always do is to boot hte machine, let it 
>>>> run for a flittle while and reboot it, so it boots with a warmed up 
>>>> oscillator. This would give trouble with the driftfile, though..
>>>>
>>>> We target for millisecond accuracy. As I understand, the oscillators on 
>>>> standard PCs are mostly cheapest crap and there are way better 
>>>> oscillators I could use to replace the original. Is that correct?
>>>>
>> 
>>> The clock in a PC is basically the guts of a cheap "Quartz" watch.  It 
>>> wouldn't surprise me if the manufacturers bought the crystals rejected 
>>> by the watch makers.  I suspect that the clock exists MOSTLY so the 
>>> machine will have the correct date for things like letters and checks.
>> 
>>> Replacing ANYTHING on the PC mother board will void your warranty.  It 
>>> may also cause your PC to cease functioning!!
>> 
>>> If you need a real clock in your PC, you can buy a board that plugs into 
>>> the PCI bus and is equipped with an OCXO (Oven Controlled Xtal (Crystal) 
>>> Oscillator).  Some will take a signal from GPS satellites and fine tune 
>>> the crystal.  Such boards are available from Meinberg Funkurhen and
>>> Symmetricom (BC635PCI/637PCI) for a great deal of money ($1200 to $2400 
>>> US) the last time I looked.  If you have lots of money and need a REALLY 
>>> accurate clock, even without full time access to GPS, you might want to 
>>> look at these products.
>> 
>> That was what he suggested. Unfortunately his computer must be switched
>> off, in hostile environments (eg winter) with no power at all for sometimes
>> months. Ie, the oven controlled crystal is pretty useless to bring up the
>> clock with accurate frequency and offset withing 10 of seconds to minutes of switchon.. 
>> I suspect an oven will take many minutes to hours to stabilize.
>> A termistor on the crystal on the other hand might be useful to compensate
>> the temperature ( there is an alteration of ntp which also calculates the
>> temp compensation of the crystal and uses that to calculate the required
>> drift rate.-- unfortunately I do not remember its name of location on the
>> web)
>> 
>> Unfortunately with ntp itself, even if he had gps, the fact thatt the drift
>> rate changes relatively rapidly on startup would still result in a offset
>> and overshoot by ntp. Since you could do a minpoll=maxpoll=4 it would be
>> relatively quick to settle in, but of course since ntp only uses 1/8 of the
>> measurements, that would be of the order of 5 min to settle down.

>Is it just my imagination or is he asking for something pretty 
>unrealistic?  NTP will not do it.   Chrony might but I'm not familiar 
>with it and can't say for sure.  Serious timekeeping equipment is 
>generally operated 24x365 in a controlled environment.

No I do not believe it is unrealistic. ntp certainly cannot do it, because
of its design, but certainly if y ou think about it, it should not take
more than a minute to a) determine what the remote correct time is via ntp
packet exchange, and b) estimate the drift rate of your own clock to at
least a few 10s of PPM, then over the next few minutes you could refine
that estimate. Ie, one should be able to get the clock phase correct in
seconds to better than ms ( the ntp exchange protocol on a good network
will do that easily) and the drift rate withing minutes ( to 1PPM type
level). If I handed you 5 packets exhanged with a host over a minute, you
could use that to estimate both the offest and the drift rate to that kind
of accuracy ( assuming that the network noise is at the 100us type level). 

If you can do that by hand, the computer should be able to automate it. 



>To turn your equipment on after months of downtime and expect it to lock 
>on to the correct time with millisecond accuracy within seconds is 
>asking for a hell of a lot.

Assuming the network noise is the 100us level, (which it is for example
between me and Regina 3000km away) you should get the accuracy easily to
1ms in 1 sec. if all you want is the phase error. One packet exchange will
give it to you. 



>My best suggestion is to turn the thing on two or three days before he 
>needs it!  Alternatively he could spend $50,000 US and up on an atomic 
>clock of his very own. . . .

That would not help if he had to turn it off for months at a time. 
That 50000 atomic clock would take a long time to get into phase. A GPS
receiver would be better, especially if it know its location. Then within
seconds it would know the time to nanoseconds. If it has to diiscover its
location it could take a lot longer.  A cheap GPS is $60. and is go to
better than usec. Ie, his demands are now adays basically trivial. The
problem is not with the problem but with trying to use ntp as the solution.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>David Woolley wrote:
>> Richard B. Gilbert wrote:
>> 
>>> The clock in a PC is basically the guts of a cheap "Quartz" watch.  It 
>>> wouldn't surprise me if the manufacturers bought the crystals rejected 
>>> by the watch makers.  I suspect that the clock exists MOSTLY so the 
>>> machine will have the correct date for things like letters and checks.
>> 
>> That describes the RTC, and may not even be valid for HPET systems.  The 
>> clock that ntpd disciplines is not based on a 32kHz watch crystal, but 
>> on a much higher frequency crystal.  Historically, the primary purpose 
>> of the latter crystal is to provide a logic clock for the processor and 
>> memory, not for time keeping.

>And it probably varies in frequency with temperature and age.  And 
>probably no one cares if the frequency is off by a percent or two, 
>especially if it's off on the high side.  Who is going to complain if 
>his 2.4 GHz processor is actually operating at 2.45 GHZ??

And from experiment it is actually off by less than .01%.(100PPM) Most
commercial computers are that good. In fact if they are off by .05% ntp is
useless and will refuse to even try to discipline it. 

Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:

>   NTP temperature compensation
>   Mark Martinec, 2001-01-08
>   http://www.ijs.si/time/temp-compensation/

> A wonderful read.

I wonder how closely Mark's results could be replicated using some
(set of) temperature readings from components already in the system
rather than adding another temp probe?  Stuff like CPU temps and other
intra-system components.  I'm not sure they have nearly the same
accuracy and resolution though :(

rick jones
-- 
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision.  - Jobert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Unruh <unruh-spam@physics.ubc.ca> wrote:
> ( assuming that the network noise is at the 100us type level).

That feels like a rather large assumption given the target environment
does not seem to allow the system to be synced to be up long-term.

rick jones
-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Rick Jones <rick.jones2@hp.com> writes:

>Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:

>>   NTP temperature compensation
>>   Mark Martinec, 2001-01-08
>>   http://www.ijs.si/time/temp-compensation/

>> A wonderful read.

>I wonder how closely Mark's results could be replicated using some
>(set of) temperature readings from components already in the system
>rather than adding another temp probe?  Stuff like CPU temps and other
>intra-system components.  I'm not sure they have nearly the same
>accuracy and resolution though :(


The problem is not accuracy and resolution, the problem is time delay. If
the cpu heats up, it will take a while for the clock crystal to heat up and
will not heat up as much. Ie, the cpu could jump to 70C briefly while some
calculation was being done, while the clock crystal heated up almost
nothing. It is probably better than nothing but if the computer has a very
variable useage, so the temp fluctuates a lot, this will be much noisier
than directly measuring the temp of the crystal. If the computer is pretty
stable, it should be fine to use other proxies. 

>I wonder how closely Mark's results could be replicated using some
>(set of) temperature readings from components already in the system
>rather than adding another temp probe?  Stuff like CPU temps and other
>intra-system components.  I'm not sure they have nearly the same
>accuracy and resolution though :(

One system I have reads temperature in quanta of 1C.
(There might be ways to get better.  I haven't pushed all that hard.)
That's not very good on this scale.

I played around in this area a while ago.  I didn't get good results
until I glued the temperature probe to the xtal.  That one reads
to 0.1F,

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Rick Jones <rick.jones2@hp.com> writes:

>Unruh <unruh-spam@physics.ubc.ca> wrote:
>> ( assuming that the network noise is at the 100us type level).

>That feels like a rather large assumption given the target environment
>does not seem to allow the system to be synced to be up long-term.

Of course it might be. However he also talks about atomic clocks and gps
and wanting quick ms accuracy, which would only be possible on a fast
network connection, etc. Since we have absolutely no idea what his setup
is, I make my assumptions explicit. It may be that he has Mills's "slow
network to Malasia" where any network packet takes an hour to traverse the
net, but in that case even he might recognize that what he wants is
impossible. 

>>A good idea might be to find someone who would program GPS/PPS support 
>>for chrony. Many people would benefit from it. We also have a good 
>>programmer working with us and he is already looking into things..
>
>I keep thinking about it, but I am not a good programmer, and first one has
>to understand chrony well enough to start hacking it. What would be really
>nice is to install a glue layer so one could simply take the ntp refclock
>files and compile them into chrony. Unfortunately the ntp people did not
>isolate the refclock behaviour terribly well, but it should be relatively
>easy for a good programmer to write such glue ( chrony also has a
>reasonably well issolated glue to the server querying stuff)

Look at the shared memory stuff.

gpsd supports many GPS devices.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:

> >I wonder how closely Mark's results could be replicated using some
> >(set of) temperature readings from components already in the system
> >rather than adding another temp probe?  Stuff like CPU temps and other
> >intra-system components.  I'm not sure they have nearly the same
> >accuracy and resolution though :(

> One system I have reads temperature in quanta of 1C.
> (There might be ways to get better.  I haven't pushed all that hard.)
> That's not very good on this scale.

> I played around in this area a while ago.  I didn't get good results
> until I glued the temperature probe to the xtal.  That one reads
> to 0.1F,

Sigh.  I was hoping there might be a middle ground using stuff already
present in the system.

rick jones
-- 
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose." 
                                                    - Rick Jones
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Richard B. Gilbert wrote:

> To turn your equipment on after months of downtime and expect it to lock 
> on to the correct time with millisecond accuracy within seconds is 
> asking for a hell of a lot.

Not really.  He's starting a GPS receiver at the same time and that has 
to lock to 50ns.

Doing it on a general purpose computer is more difficult, but not 
particularly impossible.

Unfortunately, the GPS receiver I have only has one channel, so I'm not 
sure how fast a parallel receiver can lock when it no longer has valid 
ephemeris data.

Unruh wrote:

> 
> Assuming the network noise is the 100us level, (which it is for example
> between me and Regina 3000km away) you should get the accuracy easily to
> 1ms in 1 sec. if all you want is the phase error. One packet exchange will
> give it to you. 

You have an unused network.  For about 20km between work and ISP it is 
more like 100ms peak to peak.  (2Mb/s 1:1)


> receiver would be better, especially if it know its location. Then within
> seconds it would know the time to nanoseconds. If it has to diiscover its

It's going to take at least 30 seconds to do that, as it will need the 
detailed emphemeris data and that takes 30 seconds to transmit (it might 
well pick the strongest signal and try to read the coarse ephemeris data 
first; I'm not sure if that fits in the 30 seconds.

Unruh wrote:

> Of course it might be. However he also talks about atomic clocks and gps

The marketing hype is such in this area that most people who use the 
term mean a radio clock (including GPS), rather than a true, physically 
local, atomic clock.  It's particularly used for VLF clocks, using the 1 
baud slow time code (e.g. MSF, without the fine time signal).  Such VLF 
clocks are not normally even corrected for light travel time.

NTP users are more likely to mean GPS based devices.

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:

>Unruh wrote:

>> 
>> Assuming the network noise is the 100us level, (which it is for example
>> between me and Regina 3000km away) you should get the accuracy easily to
>> 1ms in 1 sec. if all you want is the phase error. One packet exchange will
>> give it to you. 

>You have an unused network.  For about 20km between work and ISP it is 
>more like 100ms peak to peak.  (2Mb/s 1:1)

It is more like 20m. And even for 2000km (Vancouver to Regina) on the
public CanadaNet network it is only 40ms.



>> receiver would be better, especially if it know its location. Then within
>> seconds it would know the time to nanoseconds. If it has to diiscover its

>It's going to take at least 30 seconds to do that, as it will need the 
>detailed emphemeris data and that takes 30 seconds to transmit (it might 
>well pick the strongest signal and try to read the coarse ephemeris data 
>first; I'm not sure if that fits in the 30 seconds.

David Woolley wrote:
> Richard B. Gilbert wrote:
> 
>> To turn your equipment on after months of downtime and expect it to 
>> lock on to the correct time with millisecond accuracy within seconds 
>> is asking for a hell of a lot.
> 
> Not really.  He's starting a GPS receiver at the same time and that has 
> to lock to 50ns.
> 
> Doing it on a general purpose computer is more difficult, but not 
> particularly impossible.

Even with GPS and a full four satellite fix, ten seconds to synchronize 
is extremely ambitious!!  You can set the time to within whatever 
precision the hardware and software support but that is only half the 
problem.  You also need to set the correct clock frequency.  On a cold 
start, the clock frequency is a moving target as the hardware warms up.

I would expect to wait at least thirty minutes for the system to 
stabilize with both the correct phase (time) and frequency.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>David Woolley wrote:
>> Richard B. Gilbert wrote:
>> 
>>> To turn your equipment on after months of downtime and expect it to 
>>> lock on to the correct time with millisecond accuracy within seconds 
>>> is asking for a hell of a lot.
>> 
>> Not really.  He's starting a GPS receiver at the same time and that has 
>> to lock to 50ns.
>> 
>> Doing it on a general purpose computer is more difficult, but not 
>> particularly impossible.

>Even with GPS and a full four satellite fix, ten seconds to synchronize 
>is extremely ambitious!!  You can set the time to within whatever 
>precision the hardware and software support but that is only half the 
>problem.  You also need to set the correct clock frequency.  On a cold 
>start, the clock frequency is a moving target as the hardware warms up.

With a minpoll of 4, just setting the phase correctly with zero drift
compensation would at worst be out by 1ms by the next reading. And you can
get a pretty good estimate of the drift, even if it is changing. The temp
coefficient is not 10PPM/degree C. More like 1 or less. That means the
first few measurements gives a pretty good estimate of the drift ( ie to a
few PPM) and then the finer corrections can come while things settle down. 




>I would expect to wait at least thirty minutes for the system to 
>stabilize with both the correct phase (time) and frequency.

Unruh wrote:
[]
> With a minpoll of 4, just setting the phase correctly with zero drift
> compensation would at worst be out by 1ms by the next reading. And
> you can get a pretty good estimate of the drift, even if it is
> changing. The temp coefficient is not 10PPM/degree C. More like 1 or
> less. That means the first few measurements gives a pretty good
> estimate of the drift ( ie to a few PPM) and then the finer
> corrections can come while things settle down.

It isn't NTP which is the limit, but the GPS receiver acquiring lock from 
scratch after an indeterminate period of being switched off.  The GPS 
could take minutes to lock and declare that it has valid time.

David 

Richard B. Gilbert wrote:
> David Woolley wrote:
>> Richard B. Gilbert wrote:
>>
>>> To turn your equipment on after months of downtime and expect it to 
>>> lock on to the correct time with millisecond accuracy within seconds 
>>> is asking for a hell of a lot.
>>
>> Not really.  He's starting a GPS receiver at the same time and that 
>> has to lock to 50ns.
>>
>> Doing it on a general purpose computer is more difficult, but not 
>> particularly impossible.
> 
> Even with GPS and a full four satellite fix, ten seconds to synchronize 
> is extremely ambitious!!  You can set the time to within whatever 

As I noted elsewhere, 10 seconds isn't possible for a GPS cold start, 
but most of the excess time is spent in obtaining the ephemeris.  He's 
probably counting GPS startup from initial power up, but NTP start up 
from when it first gets run.

> precision the hardware and software support but that is only half the 
> problem.  You also need to set the correct clock frequency.  On a cold 
> start, the clock frequency is a moving target as the hardware warms up.

By polling sufficiently fast you can get good time accuracy, even if 
frequency takes a bit longer.

> 
> I would expect to wait at least thirty minutes for the system to 
> stabilize with both the correct phase (time) and frequency.

>It is more like 20m. And even for 2000km (Vancouver to Regina) on the
>public CanadaNet network it is only 40ms.

The time-of-flight (speed of light) delay doesn't matter (much).
It's mostly a constant.  (Routing shifts on long paths introduce
shifts.)

The problem is queueing delays.  They aren't stable.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Richard B. Gilbert schrieb:
> David Woolley wrote:
>> Richard B. Gilbert wrote:
>>
>>> To turn your equipment on after months of downtime and expect it to 
>>> lock on to the correct time with millisecond accuracy within seconds 
>>> is asking for a hell of a lot.
>> Not really.  He's starting a GPS receiver at the same time and that has 
>> to lock to 50ns.
>>
>> Doing it on a general purpose computer is more difficult, but not 
>> particularly impossible.
> 
> Even with GPS and a full four satellite fix, ten seconds to synchronize 
> is extremely ambitious!!  You can set the time to within whatever 
> precision the hardware and software support but that is only half the 
> problem.  You also need to set the correct clock frequency.  On a cold 
> start, the clock frequency is a moving target as the hardware warms up.
> 
> I would expect to wait at least thirty minutes for the system to 
> stabilize with both the correct phase (time) and frequency.

To transfer the full almanac of GPS it takes roughly 12 minutes from a 
cold start. Then the receiver knows everything there is for it to know. 
Some receivers (like mine) you can tell it's location, wich gets you in 
the 10 s range for precise time. Then again, who claimed, it has to be 
10 s? I would be very happy with these 12 mins..

>It isn't NTP which is the limit, but the GPS receiver acquiring lock from 
>scratch after an indeterminate period of being switched off.  The GPS 
>could take minutes to lock and declare that it has valid time.

From the spec sheet for the Garmin GPS 18x:

  Reacquisition: Less than 2 seconds
  Hot:           Approx. 1 second (all data known)
  Warm:          Approx. 38 seconds (initial position, time, and
              almanac known; ephemeris unknown)
  Cold:          Approx. 45 seconds

I believe that's typical of modern GPS receivers.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Unruh schrieb:
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
>> David Woolley wrote:
>>> Richard B. Gilbert wrote:
>>>
>>>> To turn your equipment on after months of downtime and expect it to 
>>>> lock on to the correct time with millisecond accuracy within seconds 
>>>> is asking for a hell of a lot.
>>> Not really.  He's starting a GPS receiver at the same time and that has 
>>> to lock to 50ns.
>>>
>>> Doing it on a general purpose computer is more difficult, but not 
>>> particularly impossible.
> 
>> Even with GPS and a full four satellite fix, ten seconds to synchronize 
>> is extremely ambitious!!  You can set the time to within whatever 
>> precision the hardware and software support but that is only half the 
>> problem.  You also need to set the correct clock frequency.  On a cold 
>> start, the clock frequency is a moving target as the hardware warms up.
> 
> With a minpoll of 4, just setting the phase correctly with zero drift
> compensation would at worst be out by 1ms by the next reading. And you can
> get a pretty good estimate of the drift, even if it is changing. The temp
> coefficient is not 10PPM/degree C. More like 1 or less. That means the
> first few measurements gives a pretty good estimate of the drift ( ie to a
> few PPM) and then the finer corrections can come while things settle down. 
> 
> 
> 
> 
>> I would expect to wait at least thirty minutes for the system to 
>> stabilize with both the correct phase (time) and frequency.

So i could do some more tests: I could not reproduce the strange running 
off for 200 ms and more once it was gone! The thread-starter had right 
the same issue and gave up on ntp after all.. Any ideas on this, anyone?

So now things look somewhat better, if I boot the machine without a 
driftfile, (300 and something in there! ...) it runs away for a little 
while, but not very far, some ten ms i recall. If let run then and given 
the chance to write that driftfile, I can reboot and it sets time with 
an offset of around 20-30 ms and from there on slowly tears it to zero. 
So the good news is, the heavy drifting is in control! What looks 
unneccesary is the initial offset..

Btw, I have minpoll 4 maxpoll 4 in my ntp.conf and ntpq -p says: "poll 
16". Is it the poll of ntpq -p or of ntpd?

Best regards,
.../nico

Hal Murray wrote:
>> It isn't NTP which is the limit, but the GPS receiver acquiring lock
>> from scratch after an indeterminate period of being switched off.
>> The GPS could take minutes to lock and declare that it has valid
>> time.
>
> From the spec sheet for the Garmin GPS 18x:
>
>  Reacquisition: Less than 2 seconds
>  Hot:           Approx. 1 second (all data known)
>  Warm:          Approx. 38 seconds (initial position, time, and
>              almanac known; ephemeris unknown)
>  Cold:          Approx. 45 seconds
>
> I believe that's typical of modern GPS receivers.

Hal, thanks for those figures.

My own experience suggests that, at least with a hand-held GPS, it can be 
a lot longer than 45 seconds.  That figure may only apply if the GPS has a 
180-degree clear view of the sky.  But the GPS18 LVC does usually recover 
quickly enough (mine has a less than 180-degree sky FoV).

If we accept 45s, is that shorter than the typical system boot time from 
cold?  Could the system boot be delayed enough so that the GPS was 
guaranteed to be ready by the time it was needed?

Cheers,
David 

Nicola Berndt wrote:
> Btw, I have minpoll 4 maxpoll 4 in my ntp.conf and ntpq -p says:
> "poll 16". Is it the poll of ntpq -p or of ntpd? 
> 
> Best regards,
> ../nico

Hello,
ntpq -p shows the time in seconds between two polls (i.e. 16). In the
configuration file the poll interval is noted in 2^x . This means your
entry of minpoll 4 maxpoll 4 means 2^4 seconds minpoll 2^4 seconds
maxpoll . So the display of 16 seconds as result of ntpq -p is correct.
Hope this helped,
Stefan Nottorf

David J Taylor wrote:
> Unruh wrote:
> []
>> With a minpoll of 4, just setting the phase correctly with zero drift
>> compensation would at worst be out by 1ms by the next reading. And
>> you can get a pretty good estimate of the drift, even if it is
>> changing. The temp coefficient is not 10PPM/degree C. More like 1 or
>> less. That means the first few measurements gives a pretty good
>> estimate of the drift ( ie to a few PPM) and then the finer
>> corrections can come while things settle down.
> 
> It isn't NTP which is the limit, but the GPS receiver acquiring lock from 
> scratch after an indeterminate period of being switched off.  The GPS 
> could take minutes to lock and declare that it has valid time.
> 
> David 
> 
> 

And ntpd could take many minutes to bludgeon the local clock into 
submission!  It's easy to determine and set the correct time.  It's less 
easy to determine and set the correct frequency and thus KEEP the 
correct time.

Nicola Berndt wrote:
> Unruh schrieb:
>> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>>
>>> David Woolley wrote:
>>>> Richard B. Gilbert wrote:
>>>>
>>>>> To turn your equipment on after months of downtime and expect it to 
>>>>> lock on to the correct time with millisecond accuracy within seconds 
>>>>> is asking for a hell of a lot.
>>>> Not really.  He's starting a GPS receiver at the same time and that has 
<snip>
> Btw, I have minpoll 4 maxpoll 4 in my ntp.conf and ntpq -p says: "poll 
> 16". Is it the poll of ntpq -p or of ntpd?
> 

It's the poll interval of ntpd.  Ntpq does not poll!  The poll interval 
varies between 2^MINPOLL and 2^MAXPOLL.  You have set MINPOLL=MAXPOLL=4 
giving a poll interval of 2^4 or 16 seconds.  This is usually the 
correct choice for a GPS receiver.  For getting time over the internet 
it would, under most circumstances, be a horrible choice!

Richard B. Gilbert wrote:
[]
> And ntpd could take many minutes to bludgeon the local clock into
> submission!  It's easy to determine and set the correct time.  It's
> less easy to determine and set the correct frequency and thus KEEP the
> correct time.

Wasn't the OP looking for about 0.5s accuracy?  Ah, no, that was someone 
else.  Here we're aiming for:

  "Our application requires good time accuracy (better than 5ms) but it 
also needs to get there quickly (as quickly as possible, but ideally 
taking no more than about 15 minutes)."

I would have thought that a GPS and NTP would have been able to achieve 
that, at least with a current drift file.

Cheers,
David 

David J Taylor wrote:
> Richard B. Gilbert wrote:
> []
>> And ntpd could take many minutes to bludgeon the local clock into
>> submission!  It's easy to determine and set the correct time.  It's
>> less easy to determine and set the correct frequency and thus KEEP the
>> correct time.
> 
> Wasn't the OP looking for about 0.5s accuracy?  Ah, no, that was someone 
> else.  Here we're aiming for:
> 
>   "Our application requires good time accuracy (better than 5ms) but it 
> also needs to get there quickly (as quickly as possible, but ideally 
> taking no more than about 15 minutes)."
> 
> I would have thought that a GPS and NTP would have been able to achieve 
> that, at least with a current drift file.
> 
> Cheers,
> David 
> 
> 

Try it some time!  Ntpd makes a mad dash for zero offset, overshoots, 
and then "rings" for a while.  Eventually it gets that tight synch that 
we like to see but it does take about thirty minutes.

I think I mentioned this here at the time I observed it.  I believe that 
I also remarked that I could have done it a lot faster by hand if I had 
the "control knobs".

Richard B. Gilbert wrote:
[]
> Try it some time!  Ntpd makes a mad dash for zero offset, overshoots,
> and then "rings" for a while.  Eventually it gets that tight synch
> that we like to see but it does take about thirty minutes.
>
> I think I mentioned this here at the time I observed it.  I believe
> that I also remarked that I could have done it a lot faster by hand
> if I had the "control knobs".

Looking at the behaviour of client PCs synching to a GPS-stratum-1 server, 
what you say surprises me somewhat.  The initial transient seems to die 
out very rapidly, judged on a "50ms" scale.  That's with a Windows client 
as well.  As the stratum-1 server has a much better reference, and as the 
poll is fixed at 64s, I would have thought that 5ms was no problem at all. 
Just feed the PPS signal to all the clients.

Oh, well.

Thanks,
David 

hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


>>It is more like 20m. And even for 2000km (Vancouver to Regina) on the
>>public CanadaNet network it is only 40ms.

>The time-of-flight (speed of light) delay doesn't matter (much).
>It's mostly a constant.  (Routing shifts on long paths introduce
>shifts.)

>The problem is queueing delays.  They aren't stable.

Agreed. Which is also why I find it amazing that on my gps controlled
server, with a Regina level 1 backup, the regina offset is less than 1ms
even though the round trip time is 40-50 ms. Ie, assymmetric router delays
do NOT appear to be a problem.
Just one data point however.. 

nb@komeda-berlin.de (Nicola Berndt) writes:

>Richard B. Gilbert schrieb:
>> David Woolley wrote:
>>> Richard B. Gilbert wrote:
>>>
>>>> To turn your equipment on after months of downtime and expect it to 
>>>> lock on to the correct time with millisecond accuracy within seconds 
>>>> is asking for a hell of a lot.
>>> Not really.  He's starting a GPS receiver at the same time and that has 
>>> to lock to 50ns.
>>>
>>> Doing it on a general purpose computer is more difficult, but not 
>>> particularly impossible.
>> 
>> Even with GPS and a full four satellite fix, ten seconds to synchronize 
>> is extremely ambitious!!  You can set the time to within whatever 
>> precision the hardware and software support but that is only half the 
>> problem.  You also need to set the correct clock frequency.  On a cold 
>> start, the clock frequency is a moving target as the hardware warms up.
>> 
>> I would expect to wait at least thirty minutes for the system to 
>> stabilize with both the correct phase (time) and frequency.

>To transfer the full almanac of GPS it takes roughly 12 minutes from a 
>cold start. Then the receiver knows everything there is for it to know. 
>Some receivers (like mine) you can tell it's location, wich gets you in 
>the 10 s range for precise time. Then again, who claimed, it has to be 
>10 s? I would be very happy with these 12 mins..

For some receivers if they know their position, they can get the time
virutally instantly from "cold start". All you need is one sattelite. If the receiver has no idea where it is, it can take much longer. 
 Whether or not the receiver the OP has has that
capability I do not know. 

>Btw, I have minpoll 4 maxpoll 4 in my ntp.conf and ntpq -p says: "poll 
>16". Is it the poll of ntpq -p or of ntpd?

The poll time is e^p where p is the poll number. 2^4=16 sec.  


>Best regards,
>../nico

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>David J Taylor wrote:
>> Unruh wrote:
>> []
>>> With a minpoll of 4, just setting the phase correctly with zero drift
>>> compensation would at worst be out by 1ms by the next reading. And
>>> you can get a pretty good estimate of the drift, even if it is
>>> changing. The temp coefficient is not 10PPM/degree C. More like 1 or
>>> less. That means the first few measurements gives a pretty good
>>> estimate of the drift ( ie to a few PPM) and then the finer
>>> corrections can come while things settle down.
>> 
>> It isn't NTP which is the limit, but the GPS receiver acquiring lock from 
>> scratch after an indeterminate period of being switched off.  The GPS 
>> could take minutes to lock and declare that it has valid time.
>> 
>> David 
>> 
>> 

>And ntpd could take many minutes to bludgeon the local clock into 
>submission!  It's easy to determine and set the correct time.  It's less 
>easy to determine and set the correct frequency and thus KEEP the 
>correct time.

Actually it is relatively easy to determine the frequency as well in a
short time. and then refine it. It is NOT easy if you use a Markovian strategy
like ntp uses. 

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>David J Taylor wrote:
>> Richard B. Gilbert wrote:
>> []
>>> And ntpd could take many minutes to bludgeon the local clock into
>>> submission!  It's easy to determine and set the correct time.  It's
>>> less easy to determine and set the correct frequency and thus KEEP the
>>> correct time.
>> 
>> Wasn't the OP looking for about 0.5s accuracy?  Ah, no, that was someone 
>> else.  Here we're aiming for:
>> 
>>   "Our application requires good time accuracy (better than 5ms) but it 
>> also needs to get there quickly (as quickly as possible, but ideally 
>> taking no more than about 15 minutes)."
>> 
>> I would have thought that a GPS and NTP would have been able to achieve 
>> that, at least with a current drift file.
>> 
>> Cheers,
>> David 
>> 
>> 

>Try it some time!  Ntpd makes a mad dash for zero offset, overshoots, 
>and then "rings" for a while.  Eventually it gets that tight synch that 
>we like to see but it does take about thirty minutes.

>I think I mentioned this here at the time I observed it.  I believe that 
>I also remarked that I could have done it a lot faster by hand if I had 
>the "control knobs".

a) The clock filter means that 7/8 of the data points get tossed. That
means that it is 128 sec between data points. Ntp must have a damping time
longer than that. and is about twice that. Ie, the error is reduced by
approximately 1/e in that damping time. Ie, if the original error was 30
ms, it will be about 12mx after 4 min, 5 after 8 min,.... but that is for
offset errors. For frequency errors it is worse. First it has to wait for
the frequency actually to create an offset error, and then start to fix
it so frequency offsets take even longer to damp out. 

b) Yes, you might have been able to do it faster, but it is unclear.
Remember what ntpo does is correct errors only by changing the frequency of
the clock. Ie, the only knob you are allowed to twidle is the frequency
knob. That is tougher. (It is like driving-- If you find yourself driving
on the wrong side of the road, all you can change is the direction the car
is driving not its position. It is really really easy to overshoot and find
yourself in the ditch. ntp is designed NOT to land in the ditch, ever. That
means it is conservative in its stearing. 

>It's the poll interval of ntpd.  Ntpq does not poll!  The poll interval 
>varies between 2^MINPOLL and 2^MAXPOLL.  You have set MINPOLL=MAXPOLL=4 
>giving a poll interval of 2^4 or 16 seconds.  This is usually the 
>correct choice for a GPS receiver.

Why do you say that?  Or let me ask it another way, how would you
decide what the right polling interval is?

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

>My own experience suggests that, at least with a hand-held GPS, it can be 
>a lot longer than 45 seconds.  That figure may only apply if the GPS has a 
>180-degree clear view of the sky.  But the GPS18 LVC does usually recover 
>quickly enough (mine has a less than 180-degree sky FoV).

The 45 second number if probably marketing.  I'm not sure
how to translate that into reality.

I wouldn't be surprised if older units took a lot longer.


>If we accept 45s, is that shorter than the typical system boot time from 
>cold?  Could the system boot be delayed enough so that the GPS was 
>guaranteed to be ready by the time it was needed?

With a bit of work, you can boot in much less that 45 seconds.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

>Agreed. Which is also why I find it amazing that on my gps controlled
>server, with a Regina level 1 backup, the regina offset is less than 1ms
>even though the round trip time is 40-50 ms. Ie, assymmetric router delays
>do NOT appear to be a problem.
>Just one data point however.. 

Look at your statistics while you download a huge file, for example
a CD.

My DSL line has 100 ms of queueing delays.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Unruh schrieb:
> nb@komeda-berlin.de (Nicola Berndt) writes:
> 
>> Richard B. Gilbert schrieb:
>>> David Woolley wrote:
>>>> Richard B. Gilbert wrote:
>>>>
>>>>> To turn your equipment on after months of downtime and expect it to 
>>>>> lock on to the correct time with millisecond accuracy within seconds 
>>>>> is asking for a hell of a lot.
>>>> Not really.  He's starting a GPS receiver at the same time and that has 
>>>> to lock to 50ns.
>>>>
>>>> Doing it on a general purpose computer is more difficult, but not 
>>>> particularly impossible.
>>> Even with GPS and a full four satellite fix, ten seconds to synchronize 
>>> is extremely ambitious!!  You can set the time to within whatever 
>>> precision the hardware and software support but that is only half the 
>>> problem.  You also need to set the correct clock frequency.  On a cold 
>>> start, the clock frequency is a moving target as the hardware warms up.
>>>
>>> I would expect to wait at least thirty minutes for the system to 
>>> stabilize with both the correct phase (time) and frequency.
> 
>> To transfer the full almanac of GPS it takes roughly 12 minutes from a 
>> cold start. Then the receiver knows everything there is for it to know. 
>> Some receivers (like mine) you can tell it's location, wich gets you in 
>> the 10 s range for precise time. Then again, who claimed, it has to be 
>> 10 s? I would be very happy with these 12 mins..
> 
> For some receivers if they know their position, they can get the time
> virutally instantly from "cold start". All you need is one sattelite. If the receiver has no idea where it is, it can take much longer. 
>  Whether or not the receiver the OP has has that
> capability I do not know. 
> 
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions


Hi,

U-Blox state on page 24 of this - 
http://www.u-blox.com/customersupport/docs/GPS_Compendium(GPS-X-02007).pdf 
- document a rate of 50 bits/second sent out by the satellites and a 
time of 12.5 mins to transmit the full almanach. I don't know, if really 
the entire almanac is needed for precise time, but I'd actually suspect 
that.

Regards,
.../nico

Nicola Berndt wrote:

> time of 12.5 mins to transmit the full almanach. I don't know, if really 
> the entire almanac is needed for precise time, but I'd actually suspect 
> that.

I don't think the almanac is strictly necessary.  What you need is the 
detailed ephemeris for each satellite you are using.  That takes 30 
seconds to transmit.

My old GPS receiver takes a long time to acquire from cold because it 
can only read data from one satellite (one spreading code) at a time. 
It starts at satellite 1 and tries each one for some time (I suspect it 
is trying different frequency offsets and different phases) until it 
finds one.  It might speed up a bit then, as it will have an approximate 
frequency, but it still continues stepping one at a time until it has 
enough for a 2D fix.  At that point, I think it does use the almanac, 
although it may use an old one, to decide which other satellites should 
be in view.

A modern, high performance, device, may be able to decode data for the 
whole constellation at once, and therefore cold start much faster.

If you know your position, you can get a time lock within 30 seconds of 
finding the first satellite.

According to the June 1995 GPS SPS Signal Specification document, the 
almanac repeats every 24 "pages".  So it will take 12 minutes to 
transmit.  I presume the extra half minute is to find the start of a 
page.  15 of the 45 seconds quoted for cold starts one one receiver may 
well be to find a safe starting point for decoding.

David J Taylor wrote:
> 
>   "Our application requires good time accuracy (better than 5ms) but it 
> also needs to get there quickly (as quickly as possible, but ideally 
> taking no more than about 15 minutes)."
> 
> I would have thought that a GPS and NTP would have been able to achieve 
> that, at least with a current drift file.

Assuming default parameters and worst case initial error, and no PPS, it 
will start with an error of 128ms and take about 40 minutes before it 
crosses zero.  It will then overshoot, so, might take several cycles to 
settle within 5ms.  Using minpoll 4 may get it to cross zero within the 
15 minutes, but the overshoot may still violate the criteria.

Nicola Berndt wrote:

> 
> To transfer the full almanac of GPS it takes roughly 12 minutes from a 
> cold start. Then the receiver knows everything there is for it to know. 

It needs more like 6 hours for that, as it can only get the detailed 
ephemeris when a satellite is above the horizon.  Of course, it doesn't 
really need to know the details of satellites until they actually come 
into view.

> Some receivers (like mine) you can tell it's location, wich gets you in 
> the 10 s range for precise time. Then again, who claimed, it has to be 
> 10 s? I would be very happy with these 12 mins..

You will need at least 30 seconds for full accuracy, for a warm start, 
but I can imagine that you could be well within 10 microseconds in 10 
seconds, if your almanac wasn't too out of date.

(Incidentally, it is possible to preload the current almanac data.)

Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
> My DSL line has 100 ms of queueing delays.

That "feels" about right if one assumes the goal is to enable
link-rate on a transcontinental (US at least) path.

rick jones
http://www.netperf.org/
-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Unruh wrote:
> nb@komeda-berlin.de (Nicola Berndt) writes:
> 
>> Richard B. Gilbert schrieb:
>>> David Woolley wrote:
>>>> Richard B. Gilbert wrote:
>>>>
>>>>> To turn your equipment on after months of downtime and expect it to 
>>>>> lock on to the correct time with millisecond accuracy within seconds 
>>>>> is asking for a hell of a lot.
>>>> Not really.  He's starting a GPS receiver at the same time and that has 
>>>> to lock to 50ns.
>>>>
>>>> Doing it on a general purpose computer is more difficult, but not 
>>>> particularly impossible.
>>> Even with GPS and a full four satellite fix, ten seconds to synchronize 
>>> is extremely ambitious!!  You can set the time to within whatever 
>>> precision the hardware and software support but that is only half the 
>>> problem.  You also need to set the correct clock frequency.  On a cold 
>>> start, the clock frequency is a moving target as the hardware warms up.
>>>
>>> I would expect to wait at least thirty minutes for the system to 
>>> stabilize with both the correct phase (time) and frequency.
> 
>> To transfer the full almanac of GPS it takes roughly 12 minutes from a 
>> cold start. Then the receiver knows everything there is for it to know. 
>> Some receivers (like mine) you can tell it's location, wich gets you in 
>> the 10 s range for precise time. Then again, who claimed, it has to be 
>> 10 s? I would be very happy with these 12 mins..
> 
> For some receivers if they know their position, they can get the time
> virutally instantly from "cold start". All you need is one sattelite. If the receiver has no idea where it is, it can take much longer. 
>  Whether or not the receiver the OP has has that
> capability I do not know. 
> 
> 

There is a subtle difference between *getting* the correct time and 
*keeping* the correct time!  A GPS receiver can generate a Pulse Per 
Second (PPS) signal accurate to within about 50 nanoseconds.  This does 
not mean that you can get the same accuracy out of your computer!

Hal Murray wrote:
>> It's the poll interval of ntpd.  Ntpq does not poll!  The poll interval 
>> varies between 2^MINPOLL and 2^MAXPOLL.  You have set MINPOLL=MAXPOLL=4 
>> giving a poll interval of 2^4 or 16 seconds.  This is usually the 
>> correct choice for a GPS receiver.
> 
> Why do you say that?  

Because the GPS time signal is extremely accurate!

> Or let me ask it another way, how would you
> decide what the right polling interval is?
> 

NTPD uses much longer poll intervals over the internet or even over a 
local network because of the variable delays introduced by the network. 
  No two packets are guaranteed the same path between two points unless 
there IS only one path.  In addition to the variations in travel time 
due to differing paths, there are also variable queuing delays!

Ntpd does not know how long any particular packet was delayed, it only 
knows what the typical delay is.  The longer polling intervals smooth 
out the errors caused by variable delays.

See Dave's book for a rigorous mathematical explanation.  Or, if your 
math is as poor as mine, you'll just have to take Dave's word for it.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>Unruh wrote:
>> nb@komeda-berlin.de (Nicola Berndt) writes:
>> 
>>> Richard B. Gilbert schrieb:
>>>> David Woolley wrote:
>>>>> Richard B. Gilbert wrote:
>>>>>
>>>>>> To turn your equipment on after months of downtime and expect it to 
>>>>>> lock on to the correct time with millisecond accuracy within seconds 
>>>>>> is asking for a hell of a lot.
>>>>> Not really.  He's starting a GPS receiver at the same time and that has 
>>>>> to lock to 50ns.
>>>>>
>>>>> Doing it on a general purpose computer is more difficult, but not 
>>>>> particularly impossible.
>>>> Even with GPS and a full four satellite fix, ten seconds to synchronize 
>>>> is extremely ambitious!!  You can set the time to within whatever 
>>>> precision the hardware and software support but that is only half the 
>>>> problem.  You also need to set the correct clock frequency.  On a cold 
>>>> start, the clock frequency is a moving target as the hardware warms up.
>>>>
>>>> I would expect to wait at least thirty minutes for the system to 
>>>> stabilize with both the correct phase (time) and frequency.
>> 
>>> To transfer the full almanac of GPS it takes roughly 12 minutes from a 
>>> cold start. Then the receiver knows everything there is for it to know. 
>>> Some receivers (like mine) you can tell it's location, wich gets you in 
>>> the 10 s range for precise time. Then again, who claimed, it has to be 
>>> 10 s? I would be very happy with these 12 mins..
>> 
>> For some receivers if they know their position, they can get the time
>> virutally instantly from "cold start". All you need is one sattelite. If the receiver has no idea where it is, it can take much longer. 
>>  Whether or not the receiver the OP has has that
>> capability I do not know. 
>> 
>> 

>There is a subtle difference between *getting* the correct time and 
>*keeping* the correct time!  A GPS receiver can generate a Pulse Per 
>Second (PPS) signal accurate to within about 50 nanoseconds.  This does 
>not mean that you can get the same accuracy out of your computer!

Of course not ( and the GPS18 only gives 1us accuracy anyway) but the OP
wanted accuracy to 1ms, which is trivial for both the computer and the gps.

David Woolley wrote:
> David J Taylor wrote:
>>
>>   "Our application requires good time accuracy (better than 5ms) but
>> it also needs to get there quickly (as quickly as possible, but
>> ideally taking no more than about 15 minutes)."
>>
>> I would have thought that a GPS and NTP would have been able to
>> achieve that, at least with a current drift file.
>
> Assuming default parameters and worst case initial error, and no PPS,
> it will start with an error of 128ms and take about 40 minutes before
> it crosses zero.  It will then overshoot, so, might take several
> cycles to settle within 5ms.  Using minpoll 4 may get it to cross
> zero within the 15 minutes, but the overshoot may still violate the
> criteria.

OK, David, so having a GPS/PPS source and distributing that to the clients 
should be far better?  How much better?

Isn't the 128ms a worst-case estimate, because NTP would set the time by 
stepping initially if the appropriate parameter is specified?  Wouldn't 
the initial offset then be near zero?

Thanks,
David 

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>Hal Murray wrote:
>>> It's the poll interval of ntpd.  Ntpq does not poll!  The poll interval 
>>> varies between 2^MINPOLL and 2^MAXPOLL.  You have set MINPOLL=MAXPOLL=4 
>>> giving a poll interval of 2^4 or 16 seconds.  This is usually the 
>>> correct choice for a GPS receiver.
>> 
>> Why do you say that?  

>Because the GPS time signal is extremely accurate!

>> Or let me ask it another way, how would you
>> decide what the right polling interval is?
>> 

>NTPD uses much longer poll intervals over the internet or even over a 
>local network because of the variable delays introduced by the network. 
>  No two packets are guaranteed the same path between two points unless 
>there IS only one path.  In addition to the variations in travel time 
>due to differing paths, there are also variable queuing delays!

No. The longer poll intervals are mainly about keeping packets off the servers. In
principle it is always better to poll more. (in practice with the ntp
model, this is only partially true-- you want the 8 times the poll interval
to be close tothe Allan minimum if the noise model really is exponential
phase and 1/f drift noise. ( on most modern networks not the greatest
assumption-- day to night temp variations are probably more important for
the frequency noise). 

>Ntpd does not know how long any particular packet was delayed, it only 
>knows what the typical delay is.  The longer polling intervals smooth 
>out the errors caused by variable delays.

No, it knows exactly now long the delay is. It just does not know if that
delay occured outbound, inbound or both. (I think you are thinking about
the broadcast model)



>See Dave's book for a rigorous mathematical explanation.  Or, if your 
>math is as poor as mine, you'll just have to take Dave's word for it.

Unruh wrote:
[]
> Of course not ( and the GPS18 only gives 1us accuracy anyway) but the
> OP wanted accuracy to 1ms, which is trivial for both the computer and
> the gps.

The OP wanted 5ms.

David 

David J Taylor wrote:

> Isn't the 128ms a worst-case estimate, because NTP would set the time by 
> stepping initially if the appropriate parameter is specified?  Wouldn't 
> the initial offset then be near zero?

I meant the largest representable value less than 128ms, which for the 
purposes of looking at startup transients can be approximated to 128ms.

Unruh wrote:

> 
> Of course not ( and the GPS18 only gives 1us accuracy anyway) but the OP
> wanted accuracy to 1ms, which is trivial for both the computer and the gps.
> 
I think there have been reports that the 1 microsecond is actually a 
conservative figure.

Also, especially for a relatively basic device, like that, I doubt that 
it will indicate the time to be valid before it has accurate ephemeris 
data (and, in that case, a 2D position).

David Woolley wrote:
> David J Taylor wrote:
>
>> Isn't the 128ms a worst-case estimate, because NTP would set the
>> time by stepping initially if the appropriate parameter is
>> specified?  Wouldn't the initial offset then be near zero?
>
> I meant the largest representable value less than 128ms, which for the
> purposes of looking at startup transients can be approximated to
> 128ms.

OK, but isn't it likely that the initial setting is much closer than 
128ms, after the first step has been made?

David 

David J Taylor wrote:

> OK, but isn't it likely that the initial setting is much closer than 
> 128ms, after the first step has been made?

There won't be a first step if the time is within 128ms.  The example I 
was giving was the worst case initial error, which is just less than 128ms.

"Unruh" <unruh-spam@physics.ubc.ca> wrote in message
news:UJyMk.3986$fF3.1213@edtnps83...

> [...] The longer poll intervals are mainly about keeping packets off
> the servers. In principle it is always better to poll more. ...

Yes, but. One of the given reasons for polling less often is to let
the host clock accrue more error so that it becomes better measureable
amid other error sources, for example jitter from random network delays.

But you can poll every second and still correct very small frequency
errors, if only you don't _forget_ polls from very long ago. Keeping
a simple FIFO queue of poll results is too simple.

Groetjes,
Maarten Wiltink

"David J Taylor" <david-taylor@blueyonder.neither-this-part.nor-this-bit.co.uk> writes:

>David Woolley wrote:
>> David J Taylor wrote:
>>>
>>>   "Our application requires good time accuracy (better than 5ms) but
>>> it also needs to get there quickly (as quickly as possible, but
>>> ideally taking no more than about 15 minutes)."
>>>
>>> I would have thought that a GPS and NTP would have been able to
>>> achieve that, at least with a current drift file.
>>
>> Assuming default parameters and worst case initial error, and no PPS,
>> it will start with an error of 128ms and take about 40 minutes before
>> it crosses zero.  It will then overshoot, so, might take several
>> cycles to settle within 5ms.  Using minpoll 4 may get it to cross
>> zero within the 15 minutes, but the overshoot may still violate the
>> criteria.

>OK, David, so having a GPS/PPS source and distributing that to the clients 
>should be far better?  How much better?

That is his minpoll 4 case. refclocks are almost always run at minpoll 4.
They could be run at minpoll 2 but ntp will not allow it. 


>Isn't the 128ms a worst-case estimate, because NTP would set the time by 
>stepping initially if the appropriate parameter is specified?  Wouldn't 
>the initial offset then be near zero?

That was what he said "worst case initial error" He should have said
127.999msec though I think:-)

Actually it is NOT the worst case scenario. Try  a drift which is seriously
off instead. That takes much longer to settle down. First ntp has to notice
that the drift is off, and then has to start correcting it. Thus a drift of
say 200PPM (500 would be a worst case, but ntp cannot correct a 500PPM
drift so there is no point in going there) will take quite a bit longer to
correct (should take about twice as long to first go through zero).



>Thanks,
>David 

"Maarten Wiltink" <maarten@kittensandcats.net> writes:

>"Unruh" <unruh-spam@physics.ubc.ca> wrote in message
>news:UJyMk.3986$fF3.1213@edtnps83...

>> [...] The longer poll intervals are mainly about keeping packets off
>> the servers. In principle it is always better to poll more. ...

>Yes, but. One of the given reasons for polling less often is to let
>the host clock accrue more error so that it becomes better measureable
>amid other error sources, for example jitter from random network delays.

>But you can poll every second and still correct very small frequency
>errors, if only you don't _forget_ polls from very long ago. Keeping
>a simple FIFO queue of poll results is too simple.

Agreed. But even a simply fifo is ok, if you keep a long enough train of
values. If you keep none, as ntp does, then it is tougher, and more
frequent polling does degrade the frequency accuracy in the presence of
noise. (but increases the phase accuracy).

Unruh wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
>> Hal Murray wrote:
>>>> It's the poll interval of ntpd.  Ntpq does not poll!  The poll interval 
>>>> varies between 2^MINPOLL and 2^MAXPOLL.  You have set MINPOLL=MAXPOLL=4 
>>>> giving a poll interval of 2^4 or 16 seconds.  This is usually the 
>>>> correct choice for a GPS receiver.
>>> Why do you say that?  
> 
>> Because the GPS time signal is extremely accurate!
> 
>>> Or let me ask it another way, how would you
>>> decide what the right polling interval is?
>>>
> 
>> NTPD uses much longer poll intervals over the internet or even over a 
>> local network because of the variable delays introduced by the network. 
>>  No two packets are guaranteed the same path between two points unless 
>> there IS only one path.  In addition to the variations in travel time 
>> due to differing paths, there are also variable queuing delays!
> 
> No. The longer poll intervals are mainly about keeping packets off the servers. In
> principle it is always better to poll more. (in practice with the ntp
> model, this is only partially true-- you want the 8 times the poll interval
> to be close tothe Allan minimum if the noise model really is exponential
> phase and 1/f drift noise. ( on most modern networks not the greatest
> assumption-- day to night temp variations are probably more important for
> the frequency noise). 

ntp presents a very light load on the servers unless you have some 
idiots polling at two second intervals (other than an initial burst at 
startup).

The longer poll intervals allow ntpd to measure small errors very 
accurately.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>Unruh wrote:
>> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> 
>>> Hal Murray wrote:
>>>>> It's the poll interval of ntpd.  Ntpq does not poll!  The poll interval 
>>>>> varies between 2^MINPOLL and 2^MAXPOLL.  You have set MINPOLL=MAXPOLL=4 
>>>>> giving a poll interval of 2^4 or 16 seconds.  This is usually the 
>>>>> correct choice for a GPS receiver.
>>>> Why do you say that?  
>> 
>>> Because the GPS time signal is extremely accurate!
>> 
>>>> Or let me ask it another way, how would you
>>>> decide what the right polling interval is?
>>>>
>> 
>>> NTPD uses much longer poll intervals over the internet or even over a 
>>> local network because of the variable delays introduced by the network. 
>>>  No two packets are guaranteed the same path between two points unless 
>>> there IS only one path.  In addition to the variations in travel time 
>>> due to differing paths, there are also variable queuing delays!
>> 
>> No. The longer poll intervals are mainly about keeping packets off the servers. In
>> principle it is always better to poll more. (in practice with the ntp
>> model, this is only partially true-- you want the 8 times the poll interval
>> to be close tothe Allan minimum if the noise model really is exponential
>> phase and 1/f drift noise. ( on most modern networks not the greatest
>> assumption-- day to night temp variations are probably more important for
>> the frequency noise). 

>ntp presents a very light load on the servers unless you have some 
>idiots polling at two second intervals (other than an initial burst at 
>startup).

>The longer poll intervals allow ntpd to measure small errors very 
>accurately.

If you want good time, use short polls. If you want good frequency, use
long polls. ntp tries to strike a balance by having the poll interval be
roughly the minimum of the Allan variance. But since it assumes, rathr than
measures the location of that minimum, it is pretty useless for any real
life situation. Thus, If you have continuous connectivity to the server,
short poll intervals will give you the best time ( but not the best
frequency) If you occasionally loose connectivity for some period, then the
lack of good freq will hurt you as the time will drift off too fast. 
Longer poll intervals thus allow you to measure frequency drifts more
accurately, but if you have continuous connectivity, why do you care if you
know the drift rate accurately?

The primary reason for long poll intervals is not to swamp the public
servers. -- while one packet is not too bad, 10^6 packets pers second
because of for example a very badly designed router which has your server's
address hardwired in totally swamps your connction. 

So, if it is your own server which only you use, poll as often as you wish.
If it is someone elses, don't.

Unruh wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
>> Unruh wrote:
>>> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>>>
>>>> Hal Murray wrote:
>>>>>> It's the poll interval of ntpd.  Ntpq does not poll!  The poll interval 
>>>>>> varies between 2^MINPOLL and 2^MAXPOLL.  You have set MINPOLL=MAXPOLL=4 
>>>>>> giving a poll interval of 2^4 or 16 seconds.  This is usually the 
>>>>>> correct choice for a GPS receiver.
>>>>> Why do you say that?  
>>>> Because the GPS time signal is extremely accurate!
>>>>> Or let me ask it another way, how would you
>>>>> decide what the right polling interval is?
>>>>>
>>>> NTPD uses much longer poll intervals over the internet or even over a 
>>>> local network because of the variable delays introduced by the network. 
>>>>  No two packets are guaranteed the same path between two points unless 
>>>> there IS only one path.  In addition to the variations in travel time 
>>>> due to differing paths, there are also variable queuing delays!
>>> No. The longer poll intervals are mainly about keeping packets off the servers. In
>>> principle it is always better to poll more. (in practice with the ntp
>>> model, this is only partially true-- you want the 8 times the poll interval
>>> to be close tothe Allan minimum if the noise model really is exponential
>>> phase and 1/f drift noise. ( on most modern networks not the greatest
>>> assumption-- day to night temp variations are probably more important for
>>> the frequency noise). 
> 
>> ntp presents a very light load on the servers unless you have some 
>> idiots polling at two second intervals (other than an initial burst at 
>> startup).
> 
>> The longer poll intervals allow ntpd to measure small errors very 
>> accurately.
> 
> If you want good time, use short polls. If you want good frequency, use
> long polls. ntp tries to strike a balance by having the poll interval be

And if you want both good time AND good frequency?  Ideally the system 
should provide both.

> roughly the minimum of the Allan variance. But since it assumes, rathr than
> measures the location of that minimum, it is pretty useless for any real
> life situation. Thus, If you have continuous connectivity to the server,
> short poll intervals will give you the best time ( but not the best
> frequency) If you occasionally loose connectivity for some period, then the
> lack of good freq will hurt you as the time will drift off too fast. 
> Longer poll intervals thus allow you to measure frequency drifts more
> accurately, but if you have continuous connectivity, why do you care if you
> know the drift rate accurately?
> 
> The primary reason for long poll intervals is not to swamp the public
> servers. -- while one packet is not too bad, 10^6 packets pers second
> because of for example a very badly designed router which has your server's
> address hardwired in totally swamps your connction. 
> 
> So, if it is your own server which only you use, poll as often as you wish.
> If it is someone elses, don't.
> 
> 

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>Unruh wrote:
>> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> 
>>> Unruh wrote:
>>>> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>>>>
>>>>> Hal Murray wrote:
>>>>>>> It's the poll interval of ntpd.  Ntpq does not poll!  The poll interval 
>>>>>>> varies between 2^MINPOLL and 2^MAXPOLL.  You have set MINPOLL=MAXPOLL=4 
>>>>>>> giving a poll interval of 2^4 or 16 seconds.  This is usually the 
>>>>>>> correct choice for a GPS receiver.
>>>>>> Why do you say that?  
>>>>> Because the GPS time signal is extremely accurate!
>>>>>> Or let me ask it another way, how would you
>>>>>> decide what the right polling interval is?
>>>>>>
>>>>> NTPD uses much longer poll intervals over the internet or even over a 
>>>>> local network because of the variable delays introduced by the network. 
>>>>>  No two packets are guaranteed the same path between two points unless 
>>>>> there IS only one path.  In addition to the variations in travel time 
>>>>> due to differing paths, there are also variable queuing delays!
>>>> No. The longer poll intervals are mainly about keeping packets off the servers. In
>>>> principle it is always better to poll more. (in practice with the ntp
>>>> model, this is only partially true-- you want the 8 times the poll interval
>>>> to be close tothe Allan minimum if the noise model really is exponential
>>>> phase and 1/f drift noise. ( on most modern networks not the greatest
>>>> assumption-- day to night temp variations are probably more important for
>>>> the frequency noise). 
>> 
>>> ntp presents a very light load on the servers unless you have some 
>>> idiots polling at two second intervals (other than an initial burst at 
>>> startup).
>> 
>>> The longer poll intervals allow ntpd to measure small errors very 
>>> accurately.
>> 
>> If you want good time, use short polls. If you want good frequency, use
>> long polls. ntp tries to strike a balance by having the poll interval be

>And if you want both good time AND good frequency?  Ideally the system 
>should provide both.

There is a tradeoff, and you have to decide where in that tradeoff you want
to be. For most people, when they ask for the time, they want the  minimum
error in that time. for some they want time spans (eg measuring 100 sec
they want the least error in thet 100 s) Some want that if their
connectivity goes down for a day, the time on their machine during that day
is as small as possible. All demand different strategies. And by "good"
what do you mean?

In general in measuring anything the more measurements you have the better
it is. Unfortunately it also depends on how those measurements are used.
ntp uses ONLY the latest measurements to adjust the clock. Old measurements
are thrown away. That is valuable data.




>> roughly the minimum of the Allan variance. But since it assumes, rathr than
>> measures the location of that minimum, it is pretty useless for any real
>> life situation. Thus, If you have continuous connectivity to the server,
>> short poll intervals will give you the best time ( but not the best
>> frequency) If you occasionally loose connectivity for some period, then the
>> lack of good freq will hurt you as the time will drift off too fast. 
>> Longer poll intervals thus allow you to measure frequency drifts more
>> accurately, but if you have continuous connectivity, why do you care if you
>> know the drift rate accurately?
>> 
>> The primary reason for long poll intervals is not to swamp the public
>> servers. -- while one packet is not too bad, 10^6 packets pers second
>> because of for example a very badly designed router which has your server's
>> address hardwired in totally swamps your connction. 
>> 
>> So, if it is your own server which only you use, poll as often as you wish.
>> If it is someone elses, don't.
>> 
>> 

On Sat, Oct 25, 2008 at 4:51 AM, David Woolley
<david@ex.djwhome.demon.co.uk.invalid> wrote:
>> Of course not ( and the GPS18 only gives 1us accuracy anyway) but the OP
>> wanted accuracy to 1ms, which is trivial for both the computer and the gps.
>>
> I think there have been reports that the 1 microsecond is actually a
> conservative figure.

Wouldn't the serial port itself prevent anything better than b	104 B5s
because of the commonly used 9600 baud rate on the serial line? Even
at the max possible (according to Garmin) baud rate of 38400, 26 B5s
would seem to be the best possible. Or does the PPS signal not depend
on the serial baud rate?

I have just acquired a GPS18LVC and am starting to wade into
configuring on FreeBSD, but I am not expecting anything better than
100 B5s at 9600 baud.
-- 
RPM

Ryan Malayter wrote:

> would seem to be the best possible. Or does the PPS signal not depend
> on the serial baud rate?

PPS doesn't depend on the baud rate.

Also, asynchronous interfaces generally sample at 16 times the baud 
rate, so a 9600 baud transmission could be resolved to 6.61 
microseconds, even without PPS.

malayter@gmail.com (Ryan Malayter) writes:

>On Sat, Oct 25, 2008 at 4:51 AM, David Woolley
><david@ex.djwhome.demon.co.uk.invalid> wrote:
>>> Of course not ( and the GPS18 only gives 1us accuracy anyway) but the OP
>>> wanted accuracy to 1ms, which is trivial for both the computer and the gps.
>>>
>> I think there have been reports that the 1 microsecond is actually a
>> conservative figure.

>Wouldn't the serial port itself prevent anything better than b	104 B5s
>because of the commonly used 9600 baud rate on the serial line? Even
>at the max possible (according to Garmin) baud rate of 38400, 26 B5s
>would seem to be the best possible. Or does the PPS signal not depend
>on the serial baud rate?

The PPS is on a separate line. It is NOT on the serial port. 

>I have just acquired a GPS18LVC and am starting to wade into
>configuring on FreeBSD, but I am not expecting anything better than
>100 B5s at 9600 baud.

That may be what you expect, but you can get it 1usec (1 micro second).

 

"Ryan Malayter" <malayter@gmail.com> wrote in message
news:5d7f07420810261009i23334bc8q7c8c2cfaf7f47ec0@mail.gmail.com...

> [...] Or does the PPS signal not depend
> on the serial baud rate?

It's generally rigged to trigger an interrupt in the receiving
machine.

Groetjes,
Maarten Wiltink

>That was what he said "worst case initial error" He should have said
>127.999msec though I think:-)
>
>Actually it is NOT the worst case scenario. Try  a drift which is seriously
>off instead. That takes much longer to settle down. First ntp has to notice
>that the drift is off, and then has to start correcting it. Thus a drift of
>say 200PPM (500 would be a worst case, but ntp cannot correct a 500PPM
>drift so there is no point in going there) will take quite a bit longer to
>correct (should take about twice as long to first go through zero).

I think the worst case drift error is 2*500 PPM.  You can have -500 in the
drift file when the value should be +500.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:
> 
>>It isn't NTP which is the limit, but the GPS receiver acquiring lock from
>>scratch after an indeterminate period of being switched off.  The GPS
>>could take minutes to lock and declare that it has valid time.
> 
> From the spec sheet for the Garmin GPS 18x:
> 
>   Reacquisition: Less than 2 seconds
>   Hot:           Approx. 1 second (all data known)
>   Warm:          Approx. 38 seconds (initial position, time, and
>               almanac known; ephemeris unknown)
>   Cold:          Approx. 45 seconds
> 
> I believe that's typical of modern GPS receivers.

If "Cold" means there are no satellite data stored in the receiver then this
can not be true unless some assumptions are made which may or may not be
correct.

The GPS timing frames are using GPS time, not UTC. 

GPS receivers can compute UTC from GPS time if they have received the UTC
parameter set from the satellites, which contains the current UTC offset in
seconds, plus a possible leap second announcement, plus some coefficients
for a polynomial required to compute small offsets in a
nanosecond/microsecond range.

This UTC data set is part of the satellite's navigational messages which is
repeated once every 12 minutes, so it may take up to 12 minutes after
powering up the GPS receiver in cold mode until those parameters are
available and thus the correct UTC time can be computed.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany