Slow convergence of NTP with GPS/PPS - NTP

This is a discussion on Slow convergence of NTP with GPS/PPS - NTP ; 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 ...

Re: Slow convergence of NTP with GPS/PPS

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.

Re: Slow convergence of NTP with GPS/PPS

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.

Re: Slow convergence of NTP with GPS/PPS

>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.

Re: Slow convergence of NTP with GPS/PPS

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
>>

Re: Slow convergence of NTP with GPS/PPS

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
>>

Re: Slow convergence of NTP with GPS/PPS

Based on the replies, we have (regretfully) decided that ntpd does not suit
our particular need.

Instead we have written some software to read GPS sentences + handle PPS
pulse interrupts and manage the system time ourselves.
Somewhat crude, but seems to work OK so far....

Thanks again for all the help.

David

> -----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 L. Mills
> Sent: 02 October 2008 20:12
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>
>
> 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
> >>
>
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
>

Re: Slow convergence of NTP with GPS/PPS

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

Re: Slow convergence of NTP with GPS/PPS

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

Re: Slow convergence of NTP with GPS/PPS

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

Re: Slow convergence of NTP with GPS/PPS

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?

Re: Slow convergence of NTP with GPS/PPS

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

Re: Slow convergence of NTP with GPS/PPS

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

Re: Slow convergence of NTP with GPS/PPS

>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.

Re: Slow convergence of NTP with GPS/PPS

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.

Re: Slow convergence of NTP with GPS/PPS

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

Re: Slow convergence of NTP with GPS/PPS

>> 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.

Re: Slow convergence of NTP with GPS/PPS

>>> 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.

Re: Slow convergence of NTP with GPS/PPS

>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)

Re: Slow convergence of NTP with GPS/PPS

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.

Re: Slow convergence of NTP with GPS/PPS

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.