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:
>
> Reacquisi
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
> ...
>yes, it's too bad. I just arrieved at work 2 hours ago, turned on the machine,
>wich has an initial offset of 50 ms today (last was 5?!) and I sit here since
>two
>hours reading newpapers, waiting for time to settle in order to
>An Update from what we have decided to do.
>
>As NTP is designed to achieve accuracy slowly and conservatively. We
>have decided not to go down the NTP route.
>
>We have decided to use the PPS signal from the GPS and force the system
>time into being correct.
>
>It is a great shame the NTP doesn't
>Ie, you have to sanity check the PPS to make sure that what you think is
>correct, really IS correct.
It's even worse than that. When the PPS ticks, you know you
are on a second boundary, but you don't know which second.
You have to get the second from someplace else, perhaps by
parsing the NM
[EMAIL PROTECTED] (David Ashmore) writes:
>An Update from what we have decided to do.
>As NTP is designed to achieve accuracy slowly and conservatively. We
>have decided not to go down the NTP route.
>We have decided to use the PPS signal from the GPS and force the system
>time into being correc
An Update from what we have decided to do.
As NTP is designed to achieve accuracy slowly and conservatively. We
have decided not to go down the NTP route.
We have decided to use the PPS signal from the GPS and force the system
time into being correct.
It is a great shame the NTP doesn't achieve
>That was what he said "worst case initial error" He should have said
>127.999msec though I think:-)
>
>Actually it is NOT the worst case scenario. Try a drift which is seriously
>off instead. That takes much longer to settle down. First ntp has to notice
>that the drift is off, and then has to s
"Ryan Malayter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [...] Or does the PPS signal not depend
> on the serial baud rate?
It's generally rigged to trigger an interrupt in the receiving
machine.
Groetjes,
Maarten Wiltink
___
que
[EMAIL PROTECTED] (Ryan Malayter) writes:
>On Sat, Oct 25, 2008 at 4:51 AM, David Woolley
><[EMAIL PROTECTED]> 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 ha
Ryan Malayter wrote:
> would seem to be the best possible. Or does the PPS signal not depend
> on the serial baud rate?
PPS doesn't depend on the baud rate.
Also, asynchronous interfaces generally sample at 16 times the baud
rate, so a 9600 baud transmission could be resolved to 6.61
microseco
On Sat, Oct 25, 2008 at 4:51 AM, David Woolley
<[EMAIL PROTECTED]> 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 actuall
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>>
>>> Unruh wrote:
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
> Hal Murray wrote:
>>> It's the poll interval of ntpd. Ntpq does not poll! The poll interval
Unruh wrote:
> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>
>> Unruh wrote:
>>> "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
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>Unruh wrote:
>> "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
Unruh wrote:
> "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
"David J Taylor" <[EMAIL PROTECTED]> writes:
>David Woolley wrote:
>> David J Taylor wrote:
>>>
>>> "Our application requires good time accuracy (better than 5ms) but
>>> it also needs to get there quickly (as quickly as possible, but
>>> ideally taking no more than about 15 minutes)."
>>>
>>> I
"Maarten Wiltink" <[EMAIL PROTECTED]> writes:
>"Unruh" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> [...] The longer poll intervals are mainly about keeping packets off
>> the servers. In principle it is always better to poll more. ...
>Yes, but. One of the given reasons for p
"Unruh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [...] The longer poll intervals are mainly about keeping packets off
> the servers. In principle it is always better to poll more. ...
Yes, but. One of the given reasons for polling less often is to let
the host clock accrue mo
David J Taylor wrote:
> OK, but isn't it likely that the initial setting is much closer than
> 128ms, after the first step has been made?
There won't be a first step if the time is within 128ms. The example I
was giving was the worst case initial error, which is just less than 128ms.
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,
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
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
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
htt
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
"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
"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
>>> c
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 t
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 secon
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
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 c
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,
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
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 sec
>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 anothe
>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 se
>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
"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 fr
[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.)
"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 i
>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
[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
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 beli
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
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 t
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 accur
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 sec
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/d
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:
>
> Reacquisit
>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
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 he
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 GP
>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'
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 G
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
"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 r
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
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
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
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.
Doin
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 abo
>>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 un
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 the
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 migh
>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 resolutio
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) temper
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
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 s
"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 t
"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 converg
[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 requir
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.]
Ma
>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.
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
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 thro
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 remem
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/pro
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
>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 t
"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 que
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). Espec
[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
>> 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 ans
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
__
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
>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 num
[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 he
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
[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
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 describe
[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
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
m
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,
m: [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
>>
>>
o:[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
>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
-
> 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 ntp
[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 mo
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 dow
"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
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
1 - 100 of 119 matches
Mail list logo
