William Unruh wrote:
Ie, once ATOM has been selected, it should remain selected, unless it
also gets switched of for a few hours, or there is a disagreement
between ATOM and some other selected clock source by more than a second.
On the other hand, if the PPS signal is bound to a certain time s
Rob schrieb:
A C wrote:
ATOM always stops when the prefer peers die even if there are other
peers available but not marked prefer. I'm still running an older
development version (4.2.7p270) that I modified to remove all the prefer
code so that the selection algorithm continues to run normally
Martin Burnicki wrote:
> Rob schrieb:
>> A C wrote:
>>> ATOM always stops when the prefer peers die even if there are other
>>> peers available but not marked prefer. I'm still running an older
>>> development version (4.2.7p270) that I modified to remove all the prefer
>>> code so that the sele
William Unruh wrote:
Once ntpd has started using the pps clock, there is no need for anything
to number the seconds. The system itself does that perfectly fine. There
is no way that the system is going jump a second, unless it is a very
very badly broken system. Ie, one only needs something to nu
On Thu, Jul 31, 2014 at 10:43:20AM +0200, Martin Burnicki wrote:
> Rob schrieb:
> >However, that is broken. Not only do you probably not want to mark
> >that clock prefer (external references are often more accurate than the
> >serial NMEA time, for example), but also you may have two or more ATOM
Miroslav Lichvar wrote:
Agreed, it would be useful to have an option to specify the PPS->time
source association for each PPS refclock directly.
In chrony, this is done with the lock refclock option. It's typically
used like this:
refclock SHM 0 offset 0.5 refid SHM0 noselect
refclock PPS /dev/
Rob wrote:
Unfortunately it is very customary for PPS devices to always send their
pulses even when they are not locked. This may make some sense when
lock is lost after it had been available, and the device continues to
free run with some accuracy. However, it is also done when the device
cold
On 2014-07-31, Martin Burnicki wrote:
>
> Unlike otherwise stated in this thread I don't think it's a good idea to
> leave the 1 PPS signal alone disciplining the time of the NTP server.
> This can easily yield unforeseen problems, similarly as if you use an
> IRIG time reference which only pro
William Unruh wrote:
> On 2014-07-31, Martin Burnicki wrote:
>>
>> Unlike otherwise stated in this thread I don't think it's a good idea to
>> leave the 1 PPS signal alone disciplining the time of the NTP server.
>> This can easily yield unforeseen problems, similarly as if you use an
>> IRIG
Martin Burnicki wrote:
> This sounds good. I think we'd have to distinguish some basic cases a
> few of which immediately come to my mind:
It looks good.
What is important for my box (but maybe only for mine...) is that there
is some method to feed OK/FAULT status to ntpd without a reference cl
On 2014-07-31, Rob wrote:
> William Unruh wrote:
>> On 2014-07-31, Martin Burnicki wrote:
>>>
>>> Unlike otherwise stated in this thread I don't think it's a good idea to
>>> leave the 1 PPS signal alone disciplining the time of the NTP server.
>>> This can easily yield unforeseen problems, si
William Unruh wrote:
> On 2014-07-31, Rob wrote:
>> William Unruh wrote:
>>> On 2014-07-31, Martin Burnicki wrote:
Unlike otherwise stated in this thread I don't think it's a good idea to
leave the 1 PPS signal alone disciplining the time of the NTP server.
This can easily
Martin Burnicki writes:
> Miroslav Lichvar wrote:
> > Agreed, it would be useful to have an option to specify the PPS->time
> > source association for each PPS refclock directly.
> >
> > In chrony, this is done with the lock refclock option. It's typically
> > used like this:
> >
> > refclock SHM 0
Rob writes:
> > A reboot is a restart and on a restart you need an external source for
> > the seconds.
>
> Why? The time is copied to the CMOS clock regularly, and one could
> expect that during the short reboot the CMOS would not drift away so
> much that the time could not be synced to the PP
On 2014-07-31 07:31, Martin Burnicki wrote:
> Miroslav Lichvar wrote:
> This sounds good. I think we'd have to distinguish some basic cases a
> few of which immediately come to my mind:
>
> 1) A refclock provides absolute time, status, and a PPS signal
>
> 1a) The refclock contains a good oscill
Harlan Stenn wrote:
> Rob writes:
>> > A reboot is a restart and on a restart you need an external source for
>> > the seconds.
>>
>> Why? The time is copied to the CMOS clock regularly, and one could
>> expect that during the short reboot the CMOS would not drift away so
>> much that the time
On 2014-07-31, Rob wrote:
> William Unruh wrote:
>> On 2014-07-31, Rob wrote:
>>> William Unruh wrote:
On 2014-07-31, Martin Burnicki wrote:
>
> Unlike otherwise stated in this thread I don't think it's a good idea to
> leave the 1 PPS signal alone disciplining the time of th
William Unruh wrote:
>> Why? The time is copied to the CMOS clock regularly, and one could
>> expect that during the short reboot the CMOS would not drift away so
>> much that the time could not be synced to the PPS unambiguously.
>
> Sure it could. And how does the system know what a "short rebo
On 30/07/14 23:15, Harlan Stenn wrote:
The reason to use a "middle range" stratum for a local refclock is so
that nobody else will start to belive that source if that machine gets
access to outside machines again.
You use a high stratum number for that. The default is too low for
nearly all t
On 2014-07-31, Rob wrote:
> William Unruh wrote:
>>> Why? The time is copied to the CMOS clock regularly, and one could
>>> expect that during the short reboot the CMOS would not drift away so
>>> much that the time could not be synced to the PPS unambiguously.
>>
>> Sure it could. And how does
On 2014-07-31, William Unruh wrote:
> On 2014-07-31, Rob wrote:
>> William Unruh wrote:
Why? The time is copied to the CMOS clock regularly, and one could
expect that during the short reboot the CMOS would not drift away so
much that the time could not be synced to the PPS unamb
William Unruh wrote:
> I think you need to read up on the cmos clock. As I said, it reports
> only the seconds, but is settable and "readable" to microseconds.
The CMOS clock is running off a 32768Hz crystal, so no way it can be
more accurately set than 30us.
Even it could be possible in theory
On Thu, Jul 31, 2014 at 12:17 PM, A C wrote:
> Some of the cheap GPS receivers derive the PPS from the RF carrier sent
> by the constellation. The PPS output is available if the oscillator is
> still receiving a synchronizing signal from the receiver even if the GPS
> CPU itself has unlocked. Un
On 2014-07-31 16:15, Henry Hallam wrote:
> On Thu, Jul 31, 2014 at 12:17 PM, A C wrote:
>> Some of the cheap GPS receivers derive the PPS from the RF carrier sent
>> by the constellation. The PPS output is available if the oscillator is
>> still receiving a synchronizing signal from the receiver
24 matches
Mail list logo
