nmea and initial large offset
Rini van Zetten
I'm trying to setup an embedded system with ntpd and a gps device as reference clock.
Everyhing went fine when the clock is not too far away when i start ntpd.
But when the clock offset is big (1-1-1970 for example), the ntpd refuses to use the gps reference clock.
Using the "-g" option does not make any difference.
I'm using ntpd 4.2.6p1
Does anybody know how to setup this ? (i have no lan connection, so an initial ntpdate is no option)
Regards,
Rini
Kalle Pokki
The system clock needs to be within 4 hours of the correct time for
NTP to synchronize to a reference clock. It seems this is not
considered a bug by the NTP developers although the behaviour is a
major blocker to use NTP with a reference clock in embedded not
constantly supervised environments. If the RTC time is lost, there is
no way for the system to synchronize to a reference clock anymore.
See https://bugs.ntp.org/417 for a discussion. There have been patches
to overcome this, but they have not been accepted.
The most annoying thing is that there are no warning messages
anywhere. The time from the reference clock is just discarded
silently.
Andy Helten
Yes, this is exactly right. We worked around this problem in our system
by grabbing the time from the refclock, setting system time with the
refclock time, quick sync NTP, and then finally start the NTP daemon.
E-Mail Sent to this address will be added to the BlackLists
> I'm trying to setup an embedded system with ntpd and a
> gps device as reference clock.
> Everyhing went fine when the clock is not too far away
> when i start ntpd.
> But when the clock offset is big (1-1-1970 for example),
> the ntpd refuses to use the gps reference clock.
> Using the "-g" option does not make any difference.
Does -g -q -x before starting NTPd as a service not get you there?
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Kalle Pokki
>
> Yes, this is exactly right. We worked around this problem in our system by
> grabbing the time from the refclock, setting system time with the refclock
> time, quick sync NTP, and then finally start the NTP daemon.
This is probably the only possible workaround without modifying NTP
code itself. However, in a vehicle that boots and starts all
operations in a place without GPS coverage, this also becomes quite
impossible to arrange properly.
The funny thing is that the exact date is provided by e.g. the SHM
refclock driver, but the year information is intentionally discarded
when the timestamp propagates up towards the NTP core code. Then the
code does all kinds of heuristics to guess the correct year, but is
unable to do that if the clock is off by more than four hours.
Rini van Zetten
> > But when the clock offset is big (1-1-1970 for example),
> > the ntpd refuses to use the gps reference clock.
> > Using the "-g" option does not make any difference.
> Does -g -q -x before starting NTPd as a service not get you there?
This does also not work. Thanks all for you input.
I'm afraid i have to add a workaround in my application which also gets the gps input,
to set the time when it's more then 4 hours away from gps time.
Regards,
Rini
unruh
> On Wed, May 5, 2010 at 16:44, Andy Helten <andy....@dot21rts.com> wrote:
>>
>> grabbing the time from the refclock, setting system time with the refclock
>> time, quick sync NTP, and then finally start the NTP daemon.
>
> This is probably the only possible workaround without modifying NTP
> code itself. However, in a vehicle that boots and starts all
> operations in a place without GPS coverage, this also becomes quite
> impossible to arrange properly.
>
> The funny thing is that the exact date is provided by e.g. the SHM
> refclock driver, but the year information is intentionally discarded
> when the timestamp propagates up towards the NTP core code. Then the
> code does all kinds of heuristics to guess the correct year, but is
> unable to do that if the clock is off by more than four hours.
I do not understand this. The ntp timestamp provides the date as well as
the time to ns. While the date has an ambiguity of soemthing like
100years, the assumption is that the century is the current one.
Kalle Pokki
>
>> The funny thing is that the exact date is provided by e.g. the SHM
>> refclock driver, but the year information is intentionally discarded
>> when the timestamp propagates up towards the NTP core code. Then the
>> code does all kinds of heuristics to guess the correct year, but is
>> unable to do that if the clock is off by more than four hours.
>
> I do not understand this. The ntp timestamp provides the date as well as
> the time to ns. While the date has an ambiguity of soemthing like
> 100years, the assumption is that the century is the current one.
Yes, but reference clock drivers don't use the ntp timestamp. Take a
look at e.g. the SHM driver. There
1) In ntpd/refclock_shm.c function shm_poll() receives a time stamp
from the shared memory block. The timestamp includes the reference
clock time and the system time at the time of sampling. The time is
expressed as struct timeval, i.e. seconds and microsecods since 1970.
2) Still in shm_poll(), the time is converted into
- day of year
- hour
- minute
- seconds
- nanoseconds
Note that year is lost here.
3) In ntpd/ntp_refclock.c function refclock_process() feeds the
timestamp to the median filters. First it must, however, call
4) In libntp/clocktime.c function clocktime() that does all kinds of
guessing what the year might be. If the system time differs from the
sample (not counting the year) more than CLOSETIME (4 hours, that is)
the function gives up and decides that this is a bad sample and needs
to be discarded.
Nothing is logged in syslog. The reachability counter shown with the
"peer" command in ntpq shows no samples have been received from the
reference clock. There is no indication where the data is lost or why.
Rob
> Yes, but reference clock drivers don't use the ntp timestamp. Take a
> look at e.g. the SHM driver. There
Is this piece of code something that our friend does not want to change
because he believes it is doing the right thing? Or is it merely badly
written by a contributor and nobody got around to cleaning it up?
I would say it is completely pointless to decompose a timeval timestamp
into separate fields and then back. That only costs CPU time and induces
errors.
Andy Helten
You should read the discussion in the bug report that was previously
provided by Kalle: https://bugs.ntp.org/417
It includes justification from David Mills on why it works this way. I
don't know that his justification specifically addressed the inability
to even force a quick sync with a refclock when it differs by more than
4 hours from system time (i.e. the CLOSETIME stuff). To me, there is no
justification for such behavior with respect to forcing a quick sync.
In such cases, ntpd is saying to the user "I know best" but it turns
that it doesn't.
Rob
It sometimes gets a bit tiresome that mr. Mills always brings up his
experiences with 20 year old systems to dictate what can be done with
ntpd today. He has seen clockchips (interestingly named TOY clocks by
him) that don't provide the year, and hence the year should not be
used by anything. He has a clockdriver that does not provide the year
and so no clockdriver should provide the year.
But is this still true today? I think any reasonable clock chip in use
today has the year information, and a reference clock like ntpshm has
year info within the range of 32bit time_t just as well. By the time
that will be a problem, time_t will be 64bit I hope.
We should not drive current users to despair (because they cannot set
their clocks) just because of some problem that existed 20 years ago
or will come up in 28 years time.
With such an attitude against change, it often surprises me that there
hasn't been a major fork of ntpd yet.
David Woolley
>
> With such an attitude against change, it often surprises me that there
> hasn't been a major fork of ntpd yet.
It's an infrastructure component with no user interface for the normal
user. Forked products tend to have significant user interfaces.
Richard B. Gilbert
> Andy Helten <andy....@dot21rts.com> wrote:
>> Rob wrote:
>>> Kalle Pokki <kalle...@iki.fi> wrote:
>>>
>>>> Yes, but reference clock drivers don't use the ntp timestamp. Take a
>>>> look at e.g. the SHM driver. There
>>>>
>>> Is this piece of code something that our friend does not want to change
>>> because he believes it is doing the right thing? Or is it merely badly
>>> written by a contributor and nobody got around to cleaning it up?
>>>
>>> I would say it is completely pointless to decompose a timeval timestamp
>>> into separate fields and then back. That only costs CPU time and induces
>>> errors.
>> You should read the discussion in the bug report that was previously
>> provided by Kalle: https://bugs.ntp.org/417
>>
>> It includes justification from David Mills on why it works this way. I
>> don't know that his justification specifically addressed the inability
>> to even force a quick sync with a refclock when it differs by more than
>> 4 hours from system time (i.e. the CLOSETIME stuff). To me, there is no
>> justification for such behavior with respect to forcing a quick sync.
>> In such cases, ntpd is saying to the user "I know best" but it turns
>> that it doesn't.
>
> It sometimes gets a bit tiresome that mr. Mills always brings up his
> experiences with 20 year old systems to dictate what can be done with
> ntpd today. He has seen clockchips (interestingly named TOY clocks by
TOY Clock or "Time Of Year Clock" is a Hardware clock present on, AFAIK,
all models of DEC VAX and Alpha computers. It runs on battery power
when the system is powered down. Many computers, including most PCs
feature such a clock. They generally do not keep time very well!
> him) that don't provide the year, and hence the year should not be
> used by anything. He has a clockdriver that does not provide the year
> and so no clockdriver should provide the year.
> But is this still true today? I think any reasonable clock chip in use
The clock CHIP is not the problem. The problem is that the quartz
crystal that provides the "tick" is usually one that failed quality
control at a wristwatch factory.
If the manufacturer was willing to spend money he could build a clock
that would not gain or lose more than three or four seconds per year.
Would you pay an additional $50 per PC in order to have such a clock?
I believe that most people don't care. The only reason that most
computers need a clock is in order to get the date right when you are
using Quicken, or similar software, to write checks!
> today has the year information, and a reference clock like ntpshm has
> year info within the range of 32bit time_t just as well. By the time
> that will be a problem, time_t will be 64bit I hope.
> We should not drive current users to despair (because they cannot set
> their clocks) just because of some problem that existed 20 years ago
> or will come up in 28 years time.
>
> With such an attitude against change, it often surprises me that there
> hasn't been a major fork of ntpd yet.
The source code for NTPD is available. Fork away. Or fork off!
Rob
> The clock CHIP is not the problem. The problem is that the quartz
> crystal that provides the "tick" is usually one that failed quality
> control at a wristwatch factory.
The issue under discussion is not the accuracy of the clock, but the
"fact" that it does not provide the year, only month/day/h/m/s.
I don't know about a chip that does not provide the year, but probably
it existed in some obscure computer more than 20 years ago.
I know the chip used in early PCs had only 2 year digits and thus could
not provide the century information, but I consider this a non-problem
as it can be easily worked around by having some threshold value above
which the year is considered in the past century (e.g. 80).
Defending silly algorithms in code with limitations in old hardware no
longer in use in running systems seems a bit silly to me.
But I often recognize a pattern where people who operate ntpd in different
environments than the one envisioned by the author get turned away when
suggesting changes.
We all know the discussions about systems not running 24h/day, systems
with instability related to temperature that changes over a day/night
pattern, arbitrary nonconfigrable limits on clock drift, initial clock
offset etc.
unruh
but the rtc on pcs do provide the year. They may not keep time well,
but do keep it to better than a year.
>
>> him) that don't provide the year, and hence the year should not be
>> used by anything. He has a clockdriver that does not provide the year
>> and so no clockdriver should provide the year.
>> But is this still true today? I think any reasonable clock chip in use
>
> The clock CHIP is not the problem. The problem is that the quartz
> crystal that provides the "tick" is usually one that failed quality
> control at a wristwatch factory.
Who cares. It keeps time to seconds per month, and unless you switch off
your computer for a century, that is 'good enough'
to intialise the clock.
>
> If the manufacturer was willing to spend money he could build a clock
> that would not gain or lose more than three or four seconds per year.
> Would you pay an additional $50 per PC in order to have such a clock?
> I believe that most people don't care. The only reason that most
> computers need a clock is in order to get the date right when you are
> using Quicken, or similar software, to write checks!
I have no idea how this answers the criticism.
>
>> today has the year information, and a reference clock like ntpshm has
>> year info within the range of 32bit time_t just as well. By the time
>> that will be a problem, time_t will be 64bit I hope.
>> We should not drive current users to despair (because they cannot set
>> their clocks) just because of some problem that existed 20 years ago
>> or will come up in 28 years time.
>>
>> With such an attitude against change, it often surprises me that there
>> hasn't been a major fork of ntpd yet.
>
> The source code for NTPD is available. Fork away. Or fork off!
Oh dear. A suggestion for improvement of a clear deficiency on ntpd is
made and you come up with this.
Uwe Klein
> Defending silly algorithms in code with limitations in old hardware no
> longer in use in running systems seems a bit silly to me.
Any abstraction _must_ cover all variations that are sensible or
expectable.
An abstraction that only covers the smallest common set of features
and that attaches to the available set of most extended limitations
is just broken.
An abstraction should have a builtin mechanism for extensions
( and be "innoculated" against possibly resulting breakage.).
uwe
David Woolley
> Rob wrote:
>> Defending silly algorithms in code with limitations in old hardware no
>> longer in use in running systems seems a bit silly to me.
>
>
> Any abstraction _must_ cover all variations that are sensible or
> expectable.
It seems to me that an abstraction that allows for the year is more
general than one that doesn't. It should be the driver's responsibility
for fixing up cases where the device doesn't provide the year, with
maybe the help of a driver support utility library routine.
Uwe Klein
universal structure. length, capability flags...
uwe
Richard B. Gilbert
Please feel free to design your own algorithms to deal with the "systems
not running 24h/day" and, while you're at it, deal with temperature
variations and support drift rates up to 5,000 PPM, etc, etc.
NTPD, when used as intended keeps time very well!
Richard B. Gilbert
Please feel free to install your own "fix" for the deficiencies you
perceive in NTPD and see how well it keeps time. I know, you want
SOMEBODY ELSE to do the work! There may not be anyone else!
unruh
> Rob wrote:
>> Defending silly algorithms in code with limitations in old hardware no
>> longer in use in running systems seems a bit silly to me.
>
>
> Any abstraction _must_ cover all variations that are sensible or
> expectable.
While one might regard it as desireable that they cover the possible
systems, that does NOT mean that the program has to run just the lowest
common denominator. It should test to see if the system is one of the
brain damaged ones, and then run a special case, not assume that because
one in a million is brain damaged, all must be treated as if they are.
unruh
I do. I run chrony, which is both far faster than ntpd at converging,
and is a factor of 3 (or more) more accurate than ntpd, and now also
supports some hardware clocks, and can correct for far higher clock
drifts than ntpd (unfortunately only on linux or bsd).
You really sound like a bureaucrat-- It has always
been done this way and if it does not work for you, you are broken not
it.
Rob
I don't feel free to design those because I can anticipate that the
changes will be rejected and will not go into the distribution version.
John Hasler
> I don't feel free to design those because I can anticipate that the
> changes will be rejected and will not go into the distribution
> version.
Then use and contribute to Chrony. We welcome contributions. Why
continue to criticize Ntpd if you feel that your suggestions will be
ignored?
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Rob
> Rob writes:
>> I don't feel free to design those because I can anticipate that the
>> changes will be rejected and will not go into the distribution
>> version.
>
> Then use and contribute to Chrony. We welcome contributions. Why
> continue to criticize Ntpd if you feel that your suggestions will be
> ignored?
I think ntpd has a good number of features and advantages, and I only
wonder why nobody has yet decided to take the code and fork a version
that has some of the properties of chrony, and fixes some of the obvious
problems when being used in a different environment than the maintainer
envisioned.
(like embedded systems, where there is a need to set the initial time
without operator intervention)
John Hasler
> I think ntpd has a good number of features and advantages...
Why not add those features and advantages to Chrony?
> ...I only wonder why nobody has yet decided to take the code and
> fork...
Because you haven't done it.
Rob
> Rob writes:
>> I think ntpd has a good number of features and advantages...
>
> Why not add those features and advantages to Chrony?
Because I have good experience with ntpd.
>> ...I only wonder why nobody has yet decided to take the code and
>> fork...
>
> Because you haven't done it.
Maybe the chrony people should have started with a fork from ntpd.
Then I would probably be using it now.
Richard B. Gilbert
Of course they will not go into the distribution version. At least it
won't go into Dave Mills' distribution.
IF you can make it work across the full spectrum of NTPD usage it will
be distributed somehow and people will use it if they perceive that it
does, and does well, things that the official *Mills" distribution cannot!
If Dave Mills says "It can't work!" I think the burden of proof that it
can and does work is on you.
David J Taylor
news:nZSdnW01DOAWX3jW...@giganews.com...
[]
> Of course they will not go into the distribution version. At least it
> won't go into Dave Mills' distribution.
>
> IF you can make it work across the full spectrum of NTPD usage it will
> be distributed somehow and people will use it if they perceive that it
> does, and does well, things that the official *Mills" distribution
> cannot!
>
> If Dave Mills says "It can't work!" I think the burden of proof that it
> can and does work is on you.
I find it somewhat disappointing that this attitude exists. At least for
end nodes, why can't there be a faster convergence option available? The
scenario for NTP usage today is very significantly different from twenty
years ago.
I'm also disappointed that people spend time arguing about these issues,
when the bugs I have reported (such as significant performance differences
between 4.2.4, 4.2.5 and 4.2.6) go unresolved.
Cheers,
David
Rob
> Rob wrote:
>> Richard B. Gilbert <rgilb...@comcast.net> wrote:
>>> Please feel free to design your own algorithms to deal with the "systems
>>> not running 24h/day" and, while you're at it, deal with temperature
>>> variations and support drift rates up to 5,000 PPM, etc, etc.
>>
>> I don't feel free to design those because I can anticipate that the
>> changes will be rejected and will not go into the distribution version.
>
> Of course they will not go into the distribution version. At least it
> won't go into Dave Mills' distribution.
>
> IF you can make it work across the full spectrum of NTPD usage it will
> be distributed somehow and people will use it if they perceive that it
> does, and does well, things that the official *Mills" distribution cannot!
I don't understand why certain features cannot be available as configurable
options, so that mr Mills can have his limited functionality version while
the rest of the world enjoys the practical, working, featureset.
For example, an option to tell ntpd that it should believe the reference
clocks when they majority-vote that the correct time is very far from the
OS time. Like -g but also for local reference clocks like GPS, e.g.
via ntpshm.
This should be possible. And it should not affect mr Mills' systems
when he makes sure he does not enable that option, so they happily
continue to run in January 1970 after a RTC power loss when he likes that
better.
> If Dave Mills says "It can't work!" I think the burden of proof that it
> can and does work is on you.
That is the problem. He keeps referring back to his books and the
facts he has collected 20 years ago, and a changing environment is not
part of his world.
Richard B. Gilbert
Dave's math is beyond me but I'm willing to take it on faith. It works!
I suspect that faster convergence would carry a price such as large
amplitude oscillation!
If you can't stand it, roll your own! You may find that it's far more
difficult than you think!
John Hasler
> I suspect that faster convergence would carry a price such as large
> amplitude oscillation!
Chrony converges faster and doesn't oscillate. I would like to see a
rigorous analysis of the algorithms used by Chrony, though.
> If you can't stand it, roll your own!
Richard Curnow did and we now have Chrony.
> You may find that it's far more difficult than you think!
It wasn't easy.
I really don't understand why Rob will neither switch to Chrony nor fork
Ntpd, since he is clearly dissatisfied and frustrated by Ntpd as it
stands. Both these choices are open to him, as is writing his own
implementation from scratch.
Richard B. Gilbert
Perhaps he enjoys complaining?
David Lord
Seems another possible alternative is on the way
http://www.cubinlab.ee.unimelb.edu.au/radclock/
At moment it's Linux/FreeBSD only, I guess it will be same as
for recent versions of ntpd and chrony and not be usable on
NetBSD.
David
unruh
I doubt it. chrony was largely written by one person, Richard Curnow.
His philosophy on how to control clocks was completely different from
Mill's and has been shown to work much better. It has now been taken
over by a small group with M Lichvar contributing most to the
development. It is a well developed program, different from ntpd in many
many ways, and experimentally much better in many many ways. It needs
theoretical work (eg are there conditions in which it becomes unstable?
Are there conditions under which it performes worse than a simply
Markovian feedback device that ntpd uses? Are there conditions in which
the clock filter algorithm of ntpd might be useful, and how can one
recognize them automatically. etc) and implimentational ideas.
But as to you using it, I have no idea why, if it were called a fork of
ntpd you would be more likely to use it.
unruh
>>
>>> If Dave Mills says "It can't work!" I think the burden of proof that it
>>> can and does work is on you.
His method has had a lot of both theoretical and experimental work. That
is great.
>>
>> That is the problem. He keeps referring back to his books and the
>> facts he has collected 20 years ago, and a changing environment is not
>> part of his world.
>
> Dave's math is beyond me but I'm willing to take it on faith. It works!
I am a theoretical physicist. I understand David's math. It is not
difficult.
>
> I suspect that faster convergence would carry a price such as large
> amplitude oscillation!
No it does not. Experimental fact from running chrony.
>
> If you can't stand it, roll your own! You may find that it's far more
> difficult than you think!
Or use something that others have rolled for you-- eg chrony. Jut as
easy as using ntpd.
Richard B. Gilbert
Since I installed NTPD years ago, using it is no effort at all. If my
contract with Comcast did not forbid me to operate a "server", I'd be
offering a stratum 1 NTP server.
Rob
>> Maybe the chrony people should have started with a fork from ntpd.
>> Then I would probably be using it now.
>
> I doubt it. chrony was largely written by one person, Richard Curnow.
> His philosophy on how to control clocks was completely different from
> Mill's and has been shown to work much better. It has now been taken
> over by a small group with M Lichvar contributing most to the
> development. It is a well developed program, different from ntpd in many
> many ways, and experimentally much better in many many ways. It needs
> theoretical work (eg are there conditions in which it becomes unstable?
> Are there conditions under which it performes worse than a simply
> Markovian feedback device that ntpd uses? Are there conditions in which
> the clock filter algorithm of ntpd might be useful, and how can one
> recognize them automatically. etc) and implimentational ideas.
>
> But as to you using it, I have no idea why, if it were called a fork of
> ntpd you would be more likely to use it.
I have heard that it does not support local reference clocks.
I have a DCF-77 receiver and a GPS receiver which is interfaced via gpsd.
My understanding is that chrony cannot use those, and uses only other
servers via the network.
That is not very useful for me.
When it had started as a fork from ntpd, this issue would probably not
exist (because ntpd supports both my local reference clocks).
David Lord
Recent version of chrony has some refclock support. I've only
tried 1.24-pre1 on NetBSD and there were too many problems
for me to be able to sort out any fix. It should be ok on both
FreeBSD and Linux. Support for reference clocks (SHM, SOCK, PPS
drivers). So both DCF-77 and GPS are covered via SHM driver +
radioclkd and gpsd.
David
John Hasler
> Or use something that others have rolled for you-- eg chrony. Jut as
> easy as using ntpd.
Richard B. Gilbert writes:
> Since I installed NTPD years ago, using it is no effort at all.
Well, then you know how easy it is to use Chrony. But then again you
have no reason to change and no one is suggesting that you should. Rob,
on the other hand, is dissatisfied with Ntpd.
unruh
> unruh <un...@wormhole.physics.ubc.ca> wrote:
>>> Maybe the chrony people should have started with a fork from ntpd.
>>> Then I would probably be using it now.
>>
>> I doubt it. chrony was largely written by one person, Richard Curnow.
>> His philosophy on how to control clocks was completely different from
>> Mill's and has been shown to work much better. It has now been taken
>> over by a small group with M Lichvar contributing most to the
>> development. It is a well developed program, different from ntpd in many
>> many ways, and experimentally much better in many many ways. It needs
>> theoretical work (eg are there conditions in which it becomes unstable?
>> Are there conditions under which it performes worse than a simply
>> Markovian feedback device that ntpd uses? Are there conditions in which
>> the clock filter algorithm of ntpd might be useful, and how can one
>> recognize them automatically. etc) and implimentational ideas.
>>
>> But as to you using it, I have no idea why, if it were called a fork of
>> ntpd you would be more likely to use it.
>
> I have heard that it does not support local reference clocks.
It does now. Lichvar added support. shm in particular. PPS support.
> I have a DCF-77 receiver and a GPS receiver which is interfaced via gpsd.
> My understanding is that chrony cannot use those, and uses only other
> servers via the network.
> That is not very useful for me.
Well you should now be happy.
> When it had started as a fork from ntpd, this issue would probably not
> exist (because ntpd supports both my local reference clocks).
You can actually use a modified ntpd to feed any of the ntpd reference
sources to chrony.
David J Taylor
news:slrnhuf5b9...@wormhole.physics.ubc.ca...
[]
> You can actually use a modified ntpd to feed any of the ntpd reference
> sources to chrony.
If there were a suitably modified NTP available, you wouldn't need chrony
in the first place! <G>
David
nemo_outis
wrote in news:hs8a1j$a86$1...@news.eternal-september.org:
...
> If there were a suitably modified NTP available, you
> wouldn't need chrony in the first place! <G>
If your aunt had wheels she'd be a trolleycar.
(which is the bowdlerized version of the original which ends in
"your uncle")
Regards,
unruh
By the original statement to which these were comments, I meant that
there were some small alterations in ntpd which would have ntpd use any
of its refclock drivers, and instead of feeding them to ntpd to filter
and discipline the local clock it would feed them to chrony which would
do the local clock discipline. Ie, it would only use the refclock part
of ntpd. This requires ntpd to altered so that instead of sending the
refclock readings on to ntpd it would send them on to a tunnel to
chrony.
>
> Regards,
Dave Hart
> > when i start ntpd.
> > > But when the clock offset is big (1-1-1970 for example),
> > > the ntpd refuses to use the gps reference clock.
> > > Using the "-g" option does not make any difference.
> > Does -g -q -x before starting NTPd as a service not get you there?
>
> This does also not work. Thanks all for you input.
>
> I'm afraid i have to add a workaround in my application which also gets the gps input,
> to set the time when it's more then 4 hours away from gps time.
I think a better answer is to disable ntpd's "panic" threshold
entirely with "tinker panic 0" in ntp.conf.
Hoping to stick a fork in the meat of this conversation,
Dave Hart
Mr. James W. Laferriere
Can you please share any good AND bad side effects from adding this
option to our conf files ?
I do not have enough knowledge about the internals of ntpd to make heads
or tail what side effects there may be form this .
Tia , JimL
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network&System Engineer | 3237 Holden Road | Give me Linux |
| bab...@baby-dragons.com | Fairbanks, AK. 99709 | only on AXP |
+------------------------------------------------------------------+
unruh
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>
> --566704117-1969238047-1274552283=:21754
> Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
> Content-Transfer-Encoding: quoted-printable
> X-MIME-Autoconverted: from 8bit to quoted-printable by ns3.baby-dragons.com id
> o4MIHxe1030135
>
> Hello Dave ,
>
> On Sat, 22 May 2010, Dave Hart wrote:
>>>> =A0when i start ntpd.
>>>>> But when the clock offset is big (1-1-1970 for example),
>>>>> Using the "-g" option does not make any difference.
>>>> Does -g -q -x before starting NTPd as a service not get you there?
>>>
>>> This does also not work. Thanks all for you input.
>>>
> s the gps input,
>>> to set the time when it's more then 4 hours away from gps time.
>>
>> I think a better answer is to disable ntpd's "panic" threshold
>> entirely with "tinker panic 0" in ntp.conf.
>>
>> Hoping to stick a fork in the meat of this conversation,
>> Dave Hart
> option to our conf files ?
> s=20
> or tail what side effects there may be form this .
The side effect is that if the time diverges by more than 4 hr, ntp will
keep running ( and should step the clock at its first opportunity
because 4hr>128ms)
>
David Woolley
>> I'm afraid i have to add a workaround in my application which also gets the gps input,
>> to set the time when it's more then 4 hours away from gps time.
>
> I think a better answer is to disable ntpd's "panic" threshold
> entirely with "tinker panic 0" in ntp.conf.
I thought the panic limit was 1,000 seconds. Has this been changed?
I thought the 4 hours was a new limit, that applied even if told not to
panic on the first setting.
Dave Hart
> Dave Hart wrote:
>
>>> I'm afraid i have to add a workaround in my application which also gets
>>> the gps input,
>>> to set the time when it's more then 4 hours away from gps time.
>>
>> I think a better answer is to disable ntpd's "panic" threshold
>> entirely with "tinker panic 0" in ntp.conf.
>
> I thought the panic limit was 1,000 seconds. Has this been changed?
No. Unless, of course, you use "tinker panic", in which case it's
whatever you specify, and 0 has the special meaning "never panic
exit". http://www.eecis.udel.edu/~mills/ntp/html/miscopt.html#tinker
> I thought the 4 hours was a new limit, that applied even if told not to
> panic on the first setting.
Not new, but different, yes. This 4 hour tolerance, as has been said
repeatedly in this thread, comes from the decision to not use any year
information provided by the reference clock driver, but instead infer
the year based on the other date and time components. In the case of
a GPS NTP appliance with zero memory of the time available at startup,
you need not only "tinker panic 0", but also to hack around this
year-guessing code to relax the 4 hour limit.
Cheers,
Dave Hart
_______________________________________________
questions mailing list
ques...@lists.ntp.org
http://lists.ntp.org/listinfo/questions