Get the fudge time(s) right,
prefer the PPS,
increase mindist.
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Wed, Jun 18, 2014 at 4:04 PM, E-Mail Sent to this address will be added
to the BlackLists Null@blacklist.anitech-systems.invalid wrote:
prefer the PPS,
The point was that you can't prefer the PPS driver.
While this driver can discipline the time and frequency relative to the
PPS source,
Paul tik-...@bodosom.net wrote:
On Sun, Jun 15, 2014 at 12:11 PM, Rob nom...@example.com wrote:
Did you put prefer on the PPS and not on another source?
That was the complete output of ntpq. The local clock is marked prefer; it
can reliably number the seconds. This is just a demonstration
On Mon, Jun 16, 2014 at 3:26 AM, Rob nom...@example.com wrote:
Note that we do not have a local clock, only PPS.
I'm starting to wonder if you simply refuse to read the documentation or
you're just trolling to cause trouble.
I want to use that majority vote, not one particular server.
Is
Paul tik-...@bodosom.net wrote:
On Mon, Jun 16, 2014 at 3:26 AM, Rob nom...@example.com wrote:
Note that we do not have a local clock, only PPS.
I'm starting to wonder if you simply refuse to read the documentation or
you're just trolling to cause trouble.
To avoid further confusion, I
A C agcarver+...@acarver.net wrote:
On 2014-06-14 12:57, Rob wrote:
A C agcarver+...@acarver.net wrote:
I actually disliked having to use a prefer peer for PPS as well. So I
modified the source code to remove that requirement. As long as there's
a source that is acceptable to the selection
Brian Inglis brian.ing...@shaw.ca wrote:
On 2014-06-14 12:03, Rob wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
I see no problem, really no problem, in this configuration and I wonder
why the software makers do see a problem in it and want me to make a
configuration decision that
Paul tik-...@bodosom.net wrote:
On Sat, Jun 14, 2014 at 2:03 PM, Rob nom...@example.com wrote:
Everyone seems to think that GPS equates NMEA. Wrong.
...
It apparently assumes anyone who has a PPS signal also has a
device that provides date and time information, which is wrong.
...
But of
Paul tik-...@bodosom.net wrote:
On Sat, Jun 14, 2014 at 12:42 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
There may be no problem with time only messages: the NMEA driver page,
shows support of GLL and GGA which provide only time.
Other drivers may allow similarly limited
On Sun, Jun 15, 2014 at 12:11 PM, Rob nom...@example.com wrote:
Did you put prefer on the PPS and not on another source?
That was the complete output of ntpq. The local clock is marked prefer; it
can reliably number the seconds. This is just a demonstration and I think
it unwise to run this
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-06-13 10:17, Rob wrote:
I installed the ntp-dev package for Debian as recommended here to get
better resolution for the offset and jitter values.
The service was started with a local PPS clock (ATOM) and a couple of
low-stratum
Le 14 juin 2014 à 10:27, Rob a écrit :
The PPS source is a GPSDO which provides 1PPS, 10 MHz and status on
a serial port, but no date information (it does provide time, but that
is not very useful without date).
So I choose not to use the time info and use external (network) sources
are
mike cook michael.c...@sfr.fr wrote:
Le 14 juin 2014 à 10:27, Rob a écrit :
The PPS source is a GPSDO which provides 1PPS, 10 MHz and status on
a serial port, but no date information (it does provide time, but that
is not very useful without date).
So I choose not to use the time info and
On Sat, Jun 14, 2014 at 8:15 AM, Rob nom...@example.com wrote:
It is a strange feature.
You must have some method of numbering the PPS delimited seconds.
I am always looking for solutions that are stable by themselves, without
constant attention and trickery.
NTP is stable. There are
mike cook wrote:
Le 14 juin 2014 à 10:27, Rob a écrit :
The PPS source is a GPSDO which provides 1PPS, 10 MHz and status on
a serial port, but no date information (it does provide time, but that
is not very useful without date).
So I choose not to use the time info and use external (network)
David Lord sn...@lordynet.org wrote:
NetBSD seems to require a reboot to get PPS working. Once up
it stays synced until GPS signal is lost which happens here
several times a year.
/etc/ntp.conf
# Sure GPS
server 127.127.20.2 mode 18 prefer
fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0
Paul tik-...@bodosom.net wrote:
On Sat, Jun 14, 2014 at 8:15 AM, Rob nom...@example.com wrote:
It is a strange feature.
You must have some method of numbering the PPS delimited seconds.
Why can't 5 agreeing network servers be that method?
I am always looking for solutions that are stable
On 2014-06-14 09:05, Rob wrote:
David Lord sn...@lordynet.org wrote:
NetBSD seems to require a reboot to get PPS working. Once up
it stays synced until GPS signal is lost which happens here
several times a year.
/etc/ntp.conf
# Sure GPS
server 127.127.20.2 mode 18 prefer
fudge 127.127.20.2
Rob wrote:
David Lord sn...@lordynet.org wrote:
NetBSD seems to require a reboot to get PPS working. Once up
it stays synced until GPS signal is lost which happens here
several times a year.
/etc/ntp.conf
# Sure GPS
server 127.127.20.2 mode 18 prefer
fudge 127.127.20.2 stratum 7 time2 0.407
Le 14 juin 2014 à 16:56, Rob a écrit :
By the way, you can have more than one server marked prefer.
So the solution is to mark everything but the PPS server marked prefer?
What is the value of that?
The documentation, although a bit long in the tooth, does not recommend
multiple
mike cook michael.c...@sfr.fr wrote:
Le 14 juin 2014 à 16:56, Rob a écrit :
By the way, you can have more than one server marked prefer.
So the solution is to mark everything but the PPS server marked prefer?
What is the value of that?
The documentation, although a bit long in the
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
I see no problem, really no problem, in this configuration and I wonder
why the software makers do see a problem in it and want me to make a
configuration decision that introduces yet more problems.
There may be no problem with time only
On 2014-06-14 01:27, Rob wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
On 2014-06-13 10:17, Rob wrote:
I installed the ntp-dev package for Debian as recommended here to get
better resolution for the offset and jitter values.
The service was started with a local PPS clock (ATOM)
A C agcarver+...@acarver.net wrote:
I actually disliked having to use a prefer peer for PPS as well. So I
modified the source code to remove that requirement. As long as there's
a source that is acceptable to the selection algorithm (and marked with
the *) then PPS turns on. No perfer peer
On Sat, Jun 14, 2014 at 12:42 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
There may be no problem with time only messages: the NMEA driver page,
shows support of GLL and GGA which provide only time.
Other drivers may allow similarly limited information.
The date has to be
On 2014-06-14 12:03, Rob wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
I see no problem, really no problem, in this configuration and I wonder
why the software makers do see a problem in it and want me to make a
configuration decision that introduces yet more problems.
There may
On 2014-06-14 12:03, Rob wrote:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
I see no problem, really no problem, in this configuration and I wonder
why the software makers do see a problem in it and want me to make a
configuration decision that introduces yet more problems.
There may
On Sat, Jun 14, 2014 at 2:03 PM, Rob nom...@example.com wrote:
Everyone seems to think that GPS equates NMEA. Wrong.
...
It apparently assumes anyone who has a PPS signal also has a
device that provides date and time information, which is wrong.
...
But of course the assumptions of the
On Sat, Jun 14, 2014 at 10:56 AM, Rob nom...@example.com wrote:
What is the value of that?
It can solve certain problems.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On 14/06/14 14:21, David Lord wrote:
Mostly offset from loop_summary is about 4 us but that
includes spikes of 35-40us caused by daily and weekly cron
jobs. I intend to try an OCXO derived system clock when I
have a spare m/b.
Offset is from measured time, not from true time. The extra load
On 2014-06-14 12:57, Rob wrote:
A C agcarver+...@acarver.net wrote:
I actually disliked having to use a prefer peer for PPS as well. So I
modified the source code to remove that requirement. As long as there's
a source that is acceptable to the selection algorithm (and marked with
the *)
David Woolley wrote:
On 14/06/14 14:21, David Lord wrote:
Mostly offset from loop_summary is about 4 us but that
includes spikes of 35-40us caused by daily and weekly cron
jobs. I intend to try an OCXO derived system clock when I
have a spare m/b.
Offset is from measured time, not from true
I installed the ntp-dev package for Debian as recommended here to get
better resolution for the offset and jitter values.
The service was started with a local PPS clock (ATOM) and a couple of
low-stratum external servers. The PPS was not available when ntpd
started, but was connected about 12
On Fri, Jun 13, 2014 at 12:17 PM, Rob nom...@example.com wrote:
Why is it so picky?
Why is your jitter so high?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Paul tik-...@bodosom.net wrote:
On Fri, Jun 13, 2014 at 12:17 PM, Rob nom...@example.com wrote:
Why is it so picky?
Why is your jitter so high?
High? 0.001 is 1us. That is not high, isn't it?
___
questions mailing list
On 2014-06-13 10:17, Rob wrote:
I installed the ntp-dev package for Debian as recommended here to get
better resolution for the offset and jitter values.
The service was started with a local PPS clock (ATOM) and a couple of
low-stratum external servers. The PPS was not available when ntpd
36 matches
Mail list logo
