[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: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
> From: "David McConnell" <[EMAIL PROTECTED]> > Date: Tue, 30 Sep 2008 14:04:18 +0100 > Sender: [EMAIL PROTECTED] > > > 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? Most important is to start ntpd at boot time with the -g option so that it will immediately set the time. Then adjust your ntp.conf to set the maxpoll and minpoll to 4 for your reference clock. "minpoll 4 maxpoll 4" This will get the time synced to close to correct, hopefully a few microseconds, within a couple of minutes, depending on your hardware. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpvDhnJbdizH.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Kevin Oberman wrote: > [demime 1.01d removed an attachment of type multipart/signed] This has failed to reach the newsgroup. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
> From: "David McConnell" <[EMAIL PROTECTED]> > Date: Tue, 30 Sep 2008 14:04:18 +0100 > Sender: [EMAIL PROTECTED] > > > 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? Sorry for the dup for everyone on the mailing list, but I need to send it unsigned to make it to the news group. Most important is to start ntpd at boot time with the -g option so that it will immediately set the time. Then adjust your ntp.conf to set the maxpoll and minpoll to 4 for your reference clock. "minpoll 4 maxpoll 4" This will get the time synced to close to correct, hopefully a few microseconds, within a couple of minutes, depending on your hardware. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1222806547_81119P Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFI4owTkn3rs5h7N1ERAmQBAJ4hJZT+g/g867Jcijg6bPrhrzT9AQCeN+5k Orv1xQK+MBGU7BWQ8YXnhio= =LqU7 -END PGP SIGNATURE- --==_Exmh_1222806547_81119P-- ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Kevin Oberman wrote: > > Most important is to start ntpd at boot time with the -g option so that > it will immediately set the time. Then adjust your ntp.conf to set the > maxpoll and minpoll to 4 for your reference clock. > "minpoll 4 maxpoll 4" Most reference clocks ignore maxpoll, and I think quite a lot ignore minpoll. > > This will get the time synced to close to correct, hopefully a few > microseconds, within a couple of minutes, depending on your hardware. It will get you with a maximum error of about 128ms. You can do somewhat better if you ensure that you start off more than 128ms out, as that will force an initial step. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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.
>
This is where it is documented in the source code for 4.2.4p4
(ntpd/loopfilter.c):
* State < step > step Comments
*
* NSETFREQstep, FREQ no ntp.drift
*
* FSETSYNCstep, 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.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
[EMAIL PROTECTED] (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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
David Woolley <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
"Richard B. Gilbert" <[EMAIL PROTECTED]> 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. > 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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). ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Unruh wrote: > David Woolley <[EMAIL PROTECTED]> 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 -- - <[EMAIL PROTECTED]> "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Unruh wrote: > [EMAIL PROTECTED] (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! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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.
>>
>
>
> This is where it is documented in the source code for 4.2.4p4
> (ntpd/loopfilter.c):
>
> * State < step > step Comments
> *
> * NSETFREQstep, FREQ no ntp.drift
> *
> * FSETSYNCstep, 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!
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
David Woolley <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
"David J Taylor" <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
[EMAIL PROTECTED] 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Behalf Of David McConnell
> Sent: 30 September 2008 14:04
> To: questions@lists.ntp.org; [EMAIL PROTECTED]
> 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: [ntp:questions] 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
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: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]
>>Behalf Of David McConnell
>>Sent: 30 September 2008 14:04
>>To: questions@lists.ntp.org; [EMAIL PROTECTED]
>>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 s
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
[EMAIL PROTECTED] (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: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]
>> Behalf Of David McConnell
>> Sent: 30 September 2008 14:04
>> To: questions@lists.ntp.org; [EMAIL PROTECTED]
>> 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: [ntp:questions] 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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> >>[mailto:[EMAIL PROTECTED]
> ntp.org]On
> >>Behalf Of David McConnell
> >>Sent: 30 September 2008 14:04
> >>To: questions@lists.ntp.org; [EMAIL PROTECTED]
> >>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)
Re: [ntp:questions] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
[EMAIL PROTECTED] (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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
[EMAIL PROTECTED] (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? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
[EMAIL PROTECTED] (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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
[EMAIL PROTECTED] (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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
"Richard B. Gilbert" <[EMAIL PROTECTED]> 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. ___ questions mailin
Re: [ntp:questions] 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) 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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. 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Unruh wrote: > "Richard B. Gilbert" <[EMAIL PROTECTED]> 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? N
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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?? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Hal Murray <[EMAIL PROTECTED]> 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... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
[EMAIL PROTECTED] (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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >Unruh wrote: >> "Richard B. Gilbert" <[EMAIL PROTECTED]> 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
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
"Richard B. Gilbert" <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Hal Murray <[EMAIL PROTECTED]> 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... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Unruh <[EMAIL PROTECTED]> 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... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Rick Jones <[EMAIL PROTECTED]> writes: >Hal Murray <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Rick Jones <[EMAIL PROTECTED]> writes: >Unruh <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Hal Murray <[EMAIL PROTECTED]> 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... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>>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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
David Woolley <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
"Richard B. Gilbert" <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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.. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Unruh schrieb: > "Richard B. Gilbert" <[EMAIL PROTECTED]> 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Nicola Berndt wrote: > Unruh schrieb: >> "Richard B. Gilbert" <[EMAIL PROTECTED]> 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 > 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! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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". ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
[EMAIL PROTECTED] (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
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
"Richard B. Gilbert" <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
[EMAIL PROTECTED] (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.. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
"Richard B. Gilbert" <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
>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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Unruh schrieb: > [EMAIL PROTECTED] (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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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.) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Hal Murray <[EMAIL PROTECTED]> 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... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
Unruh wrote: > [EMAIL PROTECTED] (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! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
"Richard B. Gilbert" <[EMAIL PROTECTED]> 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >Unruh wrote: >> [EMAIL PROTECTED] (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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
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). ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
