Paul wrote:
On Tue, Aug 26, 2014 at 9:54 AM, Phil W Lee p...@lee-family.me.uk wrote:
Paul tik-...@bodosom.net considered Mon, 25 Aug 2014 19:13:45 GMT the perfect
time to write:
it's just a wrapper (syntactic sugar) around the real API.
Thre's not much point in adding that capability
On Tue, Aug 26, 2014 at 9:54 AM, Phil W Lee p...@lee-family.me.uk wrote:
Paul tik-...@bodosom.net considered Mon, 25 Aug 2014 19:13:45 GMT the
perfect time to write:
it's just a wrapper (syntactic sugar) around the real API.
Thre's not much point in adding that capability without the files
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of that also ntp-dev-doc, but
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
As the SHM driver 28 dev docs say, it is the ancient way to talk to gpsd
Then that better be corrected! It is hogwash.
The SHM driver has existed much longer than gpsd timekeeping.
In 2005 or 2006, I added timesyncing to gpsd. Before that, it
Rob writes:
Harlan wrote:
All the time variables are fixed-point decimals in seconds - you
should be able to say 0.001 to mean a millisecond (or -0.001 if you
need to go the other direction).
Should. But:
if (pp-sloppyclockflag CLK_FLAG1)
up-max_delta = 0;
Rob writes:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
As the SHM driver 28 dev docs say, it is the ancient way to talk to gpsd
Then that better be corrected! It is hogwash.
I've got a couple of folks wondering about driver46. I'll let Juergen
discuss this.
He has reasons for
On Mon, Aug 25, 2014 at 4:44 AM, Harlan Stenn st...@ntp.org wrote:
Personally, I don't
understand why we should support these devices, but apparently it's
important to some folks and perhaps I just don't understand the issue.
You have to draw the line somewhere. Perhaps the ntp developers
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
As the SHM driver 28 dev docs say, it is the ancient way to talk to gpsd
Then that better be corrected! It is hogwash.
I've got a couple of folks wondering about driver46. I'll let Juergen
Harlan Stenn st...@ntp.org wrote:
Now I'm trying to remember another discussion where the issue is 'we
have a refclock that will give us the time but not the date.' as I
recall that has bearing on the SHM driver. Personally, I don't
understand why we should support these devices, but
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Paul wrote:
To carp yet again: you should add timepps.h to the tar ball and stick
to that. Leave the package building to the distributions. If people
want/need more current features they should learn how to build the
current dev source and you
Harlan Stenn wrote:
Rob writes:
Harlan wrote:
All the time variables are fixed-point decimals in seconds - you
should be able to say 0.001 to mean a millisecond (or -0.001 if you
need to go the other direction).
Should. But:
if (pp-sloppyclockflag CLK_FLAG1)
On Mon, Aug 25, 2014 at 12:00 PM, Martin Burnicki
martin.burni...@meinberg.de wrote:
Since current Linux kernels *do* support PPS, and timepps.h is a valid
interface to use it, does anyone know *why* timepps.h isn't in the standard
set of header files for Linux, and is never going to be?
The
On 24/08/14 05:43, Rob wrote:
The issues #2 and #3 could have been avoided by just naming the package
ntp, at a higher version number. Then one could install and track the
development version by adding the proper repository
I don't think that is going to be acceptable. The correct way is to
David Woolley david@ex.djwhome.demon.invalid wrote:
On 24/08/14 05:43, Rob wrote:
The issues #2 and #3 could have been avoided by just naming the package
ntp, at a higher version number. Then one could install and track the
development version by adding the proper repository
I don't think
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of that also ntp-dev-doc, but
it is essentially empty (only an automatically
On 2014-08-24 05:12, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of that also ntp-dev-doc, but
it is essentially empty (only
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-08-24 05:12, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of that also ntp-dev-doc, but
it is essentially empty (only an
On 2014-08-24 13:48, Rob wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-08-24 05:12, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of that also ntp-dev-doc, but
it is essentially empty (only an automatically generated changelog).
There appears to be a package
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of that also ntp-dev-doc, but
it is essentially empty (only an automatically generated changelog).
It's in the source
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of that also ntp-dev-doc, but
it is essentially empty (only an automatically generated changelog).
There appears to be a
David Lord sn...@lordynet.org wrote:
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of that also ntp-dev-doc, but
it is essentially empty (only an automatically generated
On Sat, Aug 23, 2014 at 6:05 AM, Harlan Stenn st...@ntp.org wrote:
No idea what you mean there - we do 64-bit builds (under linux and other
OSes) all the time. You might want to check with whoever handles
building packages for your distro.
You lot are not fulfilling your obligation to Rob.
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of that also ntp-dev-doc, but
it is essentially empty (only an automatically
Paul tik-...@bodosom.net wrote:
On Sat, Aug 23, 2014 at 6:05 AM, Harlan Stenn st...@ntp.org wrote:
No idea what you mean there - we do 64-bit builds (under linux and other
OSes) all the time. You might want to check with whoever handles
building packages for your distro.
You lot are not
Paul writes:
More seriously -- having that somewhat stale deb repo probably isn't
helping anyone and causes confusion (like yours) between ntp-dev tar
balls and ntp-dev debs including the (nearly empty) ntp-dev-doc deb.
I didn't know that Rob was talking about the debian package stuff from
On Sat, Aug 23, 2014 at 4:00 PM, Harlan Stenn st...@ntp.org wrote:
I didn't know that Rob was talking about the debian package stuff from
ntp.org until he replied to that message.
Look for 'ntp-dev conflicts with ntp' from early this month. Of
course there's going to be confusion when 99.99%
Paul writes:
On Sat, Aug 23, 2014 at 4:00 PM, Harlan Stenn st...@ntp.org wrote:
I didn't know that Rob was talking about the debian package stuff from
ntp.org until he replied to that message.
Look for 'ntp-dev conflicts with ntp' from early this month. Of
course there's going to be
Harlan Stenn st...@ntp.org wrote:
To carp yet again: you should add timepps.h to the tar ball and stick
to that. Leave the package building to the distributions. If people
want/need more current features they should learn how to build the
current dev source and you should make that a LOT
Martin Burnicki martin.burni...@meinberg.de wrote:
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
This could basically work with all types of refclock, e.g.:
# refclocks with PPS signal and status, but no absolute time
server 127.127.8.0 noselect
server 127.127.22.0 stat
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
--
Harlan Stenn st...@ntp.org
http://networktimefoundation.org - be a member!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Le 1 août 2014 à 00:43, Rob a écrit :
William Unruh un...@invalid.ca 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
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de 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
Rob wrote:
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de 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
William Unruh wrote:
Yes, not entirely surprizing, especially considering the way ntp is
designed right now. This is a combination of bad ntpd design, and
restart when an external source is mandatory.
I think the design was OK when it was originally invented many years
ago. However, as you
Rob wrote:
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote:
Unlike otherwise stated in this thread I don't think it's a good idea to
leave the 1 PPS
Harlan Stenn wrote:
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
On Thu, Jul 31, 2014 at 04:31:08PM +0200, 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:
1) A refclock provides absolute time, status, and a PPS signal
1a) The refclock contains a good oscillator, so
On Thu, Jul 31, 2014 at 10:43:12PM +, Rob wrote:
William Unruh un...@invalid.ca 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
Miroslav Lichvar wrote:
On Thu, Jul 31, 2014 at 04:31:08PM +0200, 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:
1) A refclock provides absolute time, status, and a PPS signal
1a) The refclock contains a
Martin Burnicki martin.burni...@meinberg.de wrote:
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de 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
Martin Burnicki martin.burni...@meinberg.de wrote:
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
Martin Burnicki martin.burni...@meinberg.de wrote:
My point is that most of the internal clocks on computers are well able
to maintain the time to better than a second for a long time, even if
they were freewheeling, and if disciplined by a PPS, they are able to
maintain the time forever
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
This could basically work with all types of refclock, e.g.:
# refclocks with PPS signal and status, but no absolute time
server 127.127.8.0 noselect
server 127.127.22.0 stat 127.127.8.0 # sync state from parse driver
server
Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
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
Rob wrote:
I think your suggestions are very good.
Thanks!
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Fri, Aug 01, 2014 at 12:59:32PM +0200, Martin Burnicki wrote:
Miroslav Lichvar wrote:
To generalize it a bit more, there could be also a case of a PPS that
is not locked in phase and a case of a PPS that's not even locked in
frequency. When only a source with poor short-term stability is
Martin Burnicki writes:
Harlan Stenn wrote:
And the General Timestamp API (GTSAPI) project from NTF would nicely
wrap this information into a timestamp for you, directly.
For cases 2a) and 2b) there is no absolute time available from the
PPS source. If a status is available this could be
Rob wrote:
Martin Burnicki wrote:
In the example above the daemon could also just write
the sync status to the SHM segment.
Since the noselect keyword is given ntpd would poll
it but not try to use it as normal refclock.
Yes but if I remember well the SHM clock does not have
a sync
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
Rob schrieb:
A C agcarver+...@acarver.net 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
Martin Burnicki martin.burni...@meinberg.de wrote:
Rob schrieb:
A C agcarver+...@acarver.net 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
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
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
PPS
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
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
On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de 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
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de 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,
Martin Burnicki martin.burni...@meinberg.de 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
On 2014-07-31, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de 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.
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote:
Unlike otherwise stated in this thread I don't think it's a good idea to
leave the 1 PPS signal alone
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 offset 0.5
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 PPS
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 oscillator,
Harlan Stenn st...@ntp.org 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 nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
On 2014-07-31, Martin Burnicki martin.burni...@meinberg.de wrote:
Unlike otherwise stated in this thread I don't think it's a
William Unruh un...@invalid.ca 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
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
On 2014-07-31, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca 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
On 2014-07-31, William Unruh un...@invalid.ca wrote:
On 2014-07-31, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca 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
William Unruh un...@invalid.ca 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
On Thu, Jul 31, 2014 at 12:17 PM, A C agcarver+...@acarver.net 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
On 2014-07-31 16:15, Henry Hallam wrote:
On Thu, Jul 31, 2014 at 12:17 PM, A C agcarver+...@acarver.net 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
Paradoxically , the LCL clock is fine when there are no refclocks. That is,
when you don't need or want it.
remote refid st t when poll reach delay offset jitter
==
*127.127.1.1 .LOCL.
On 2014-07-30, Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-07-29 21:32, Paul wrote:
On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
These statuses show the same issue with local clock reach, implying if reach
stays
at zero, sync will be
William Unruh un...@invalid.ca wrote:
On 2014-07-30, Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-07-29 21:32, Paul wrote:
On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
These statuses show the same issue with local clock reach, implying
mike cook michael.c...@sfr.fr wrote:
Paradoxically , the LCL clock is fine when there are no refclocks. That is,
when you don't need or want it.
remote refid st t when poll reach delay offset jitter
Le 30 juil. 2014 à 11:00, Rob a écrit :
mike cook michael.c...@sfr.fr wrote:
Paradoxically , the LCL clock is fine when there are no refclocks. That is,
when you don't need or want it.
remote refid st t when poll reach delay offset jitter
On Wed, Jul 30, 2014 at 12:46 AM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
Not seen this topic mentioned in the last year or more.
See my posts about PPS is a falseticker? of Sun Jun 15 14:37:32 UTC
2014 and Wed Jun 18 20:59:03 UTC 2014 .
These statuses show the same issue with
On 2014-07-30, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
On 2014-07-30, Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-07-29 21:32, Paul wrote:
On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
These statuses show the
On 30/07/14 07:50, mike cook wrote:
Paradoxically , the LCL clock is fine when there are no refclocks.
That is, when you don't need or want it.
My understanding was that the original purpose of the local clock was to
cover the case when there were no NTP managed reference clocks (but
there
Rob wrote: What happened instead is that it started to drift shortly after. I
got
alerted by nagios when it was 10us off, which was within an hour or so.
That is why I added the LOCL clock and it solved that issue, but revealed
another one.
Have you tried orphan mode instead of locl?
--
David Woolley writes:
On 30/07/14 07:50, mike cook wrote:
Paradoxically , the LCL clock is fine when there are no refclocks.
That is, when you don't need or want it.
My understanding was that the original purpose of the local clock was
to cover the case when there were no NTP managed
I while ago I discussed the problem with an ntpd server that has to
be synchronized to a GPSDO that provides PPS but no absolute time.
After the usual discussion about you should not want that, a solution
was finally found using the following tricky workaround:
# PPS via ATOM
server 127.127.22.0
On 2014-07-29, Rob nom...@example.com wrote:
I while ago I discussed the problem with an ntpd server that has to
be synchronized to a GPSDO that provides PPS but no absolute time.
After the usual discussion about you should not want that, a solution
was finally found using the following
On 2014-07-29 11:33, William Unruh wrote:
On 2014-07-29, Rob nom...@example.com wrote:
The reasoning is that once the time is locked to PPS, it should remain
close enough for the local clock to be trusted as an absolute time
source (this system is rarely rebooted).
It should do that even
William Unruh un...@invalid.ca wrote:
On 2014-07-29, Rob nom...@example.com wrote:
I while ago I discussed the problem with an ntpd server that has to
be synchronized to a GPSDO that provides PPS but no absolute time.
After the usual discussion about you should not want that, a solution
was
Rob,
Looks like a bug anterior to your version. I see the same issue with
version=ntpd 4.2.6p5@1.2349-o whether or not there is a preferred local clock
or not, and whether or not there are other active server associations.
One for Harlen if it has not already been flagged.
Tue Jul 29
On 2014-07-29, A C agcarver+...@acarver.net wrote:
On 2014-07-29 11:33, William Unruh wrote:
On 2014-07-29, Rob nom...@example.com wrote:
The reasoning is that once the time is locked to PPS, it should remain
close enough for the local clock to be trusted as an absolute time
source (this
On 2014-07-29 12:46, William Unruh wrote:
On 2014-07-29, A C agcarver+...@acarver.net wrote:
On 2014-07-29 11:33, William Unruh wrote:
[1] ATOM's own documentation suggest maxpoll of 4 to 6 to keep the clock
synced to PPS. But that pins everything else to the same value unless a
minpoll is
mike cook michael.c...@sfr.fr wrote:
Rob,
Looks like a bug anterior to your version. I see the same issue with
version=ntpd 4.2.6p5@1.2349-o whether or not there is a preferred local
clock or not, and whether or not there are other active server associations.
One for Harlen if it has
A C agcarver+...@acarver.net wrote:
On 2014-07-29 11:33, William Unruh wrote:
On 2014-07-29, Rob nom...@example.com wrote:
The reasoning is that once the time is locked to PPS, it should remain
close enough for the local clock to be trusted as an absolute time
source (this system is rarely
On 2014-07-29 14:46, Rob wrote:
mike cook michael.c...@sfr.fr wrote:
Rob,
Looks like a bug anterior to your version. I see the same issue with
version=ntpd 4.2.6p5@1.2349-o whether or not there is a preferred local clock
or not, and whether or not there are other active server
On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
As I discovered recently under similar circumstances, offline servers are
considered
falsetickers, and if you have insufficient other candidates, or fewer than
3, nothing
gets selected.
I don't think I'm
On 2014-07-29 21:32, Paul wrote:
On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
As I discovered recently under similar circumstances, offline servers are
considered falsetickers, and if you have insufficient other candidates, or
fewer than 3, nothing gets
96 matches
Mail list logo
