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
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
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 sync
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
[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 correct.
That was what he said worst case initial error He should have said
127.999msec though I think:-)
Actually it is NOT the worst case scenario. Try a drift which is seriously
off instead. That takes much longer to settle down. First ntp has to notice
that the drift is off, and then has to start
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 actually a
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
[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 have been
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
___
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
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
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
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
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
David J Taylor wrote:
OK, but isn't it likely that the initial setting is much closer than
128ms, after the first step has been made?
There won't be a first step if the time is within 128ms. The example I
was giving was the worst case initial error, which is just less than 128ms.
Unruh [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 more
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 polling less
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 would have thought that a
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 is usually the
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
giving a 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 set MINPOLL=MAXPOLL=4
giving a
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
varies between 2^MINPOLL and
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
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 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
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
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
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.
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
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
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
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 .
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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?
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.
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
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
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
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
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.
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
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
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:
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
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
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
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.
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...
[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
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
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
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
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
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
[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
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
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
On Wed, 1 Oct 2008 10:24:22 GMT, David McConnell wrote:
The driftfile also sometimes seems to do more harm than good - especially
after a reboot.
Some kernels do a calibration of clock against RTC clock. This will make
driftfile misleading.
/hjj
___
The driftfile also sometimes seems to do more harm than good - especially
after a reboot.
Some kernels do a calibration of clock against RTC clock. This will make
driftfile misleading.
There is a bug in the Linux calibration routine for the TSC mode
clock. It doesn't get a consistent answer.
[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
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
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
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
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
[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
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
[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
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
]
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
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:
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
]
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
[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
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
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
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
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
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
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
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
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
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
[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
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
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
1 - 100 of 106 matches
Mail list logo
