Re: [ntp:questions] ntp.conf true and prefer option for server command

2017-01-23 Thread suhas manjunath
Hi Brian,


Sources marked true are passed by the select process;
> sources marked prefer may be discarded by the select process;
> sources marked true or prefer may be discarded by the cluster process;
> sources marked prefer reaching the combine process will be selected
> as the system source and their offset and jitter used as the system
> values used to discipline the system clock.
>


But the man page of ntp.conf says using true option it will always survive
the selection and clustering algorithms.

*"true* Force the association to assume truechimer status; that is, always
survive the selection and clustering algorithms. This option can be used
with any association, but is most useful for reference clocks with large
jitter on the serial port and precision pulse-per-second (PPS) signals.
Caution: this option defeats the algorithms designed to cast out
falsetickers and can allow these sources to set the system clock. This
option is valid only with the *server* and *peer* commands. "

 So if i use true and prefer option together it has to pass cluster process
also and hence it has to be taken as preferred server. but in our case it
is not taking as preferred server.

Thank you in advance for your time.

Regards,
Suhas
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


[ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations

2017-01-23 Thread Moser, Stefan
Hello everyone,

for unauthenticated peers, there is the restrict nopeer directive that stops 
unknown peers to initialize dynamic symmetric associations with an NTP server. 
However, from my own tests in my lab (and from NTP documentation), it seems 
that nopeer does not pertain to authenticated peers. In my lab, I saw this: If 
server A knows the authentication key of Server B and has a peer 
IP_address_of_server_B directive in its ntp.conf, A is able to form a dynamic 
symmetric association with server B even if server B has no configuration for 
server A at all, and server B lists server A in its association table (ntpq -p, 
type shown as S).

Do you know if there are any means to configure server B so that it does not 
allow server A to mobilize a dynamic symmetric association (meaning B should 
still provide time services to A, but should not consider A as a time source)? 
Maybe there is a similar option to nopeers, but I cannot find any in NTP 
documentation.

Stefan

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


[ntp:questions] Unable to use SHA1 with ntp4.2.8p9

2017-01-23 Thread sneha b
Hi,

I am using ntp4.2.8p9 with openssl 1.0.2j, with this md5 is working fine.
But when I use SHA1 I get below error while executine ntpd -q:

"Invalid type for key"

I downloaded the source code from ntp.org with patch and built the exe
using vxproj.
Do I need to enable some filags as to use SHA1.

I just set the openssl path in environment variables for include and
library.

Any inputs or fix in this regard will be of great use, as I am struggling
since long.

Below is the content of ntp.keys file:

# ntpkey_SHAkey_HCA-R9YL4RC.3627968244
# Fri Dec 19 14:27:24 2014

 1 MD5 s%hh5/yPldNiCAY@W&t$  # MD5 key
 2 MD5 Bhq]@PXUV7Z(-xHHl  # MD5 key
 7 MD5 ytRQhn%1U<}IzW^P0EJ-  # MD5 key
 8 MD5 W~/3[]6g"ylC9vJTHJ}V  # MD5 key
 9 MD5 39Udu|jeZ*tcS"o+kKwu  # MD5 key
10 MD5 -AJq19S~9Q?GPgbIHoyx  # MD5 key
11 SHA1 2fee5e55aae45c9dea60fd2776d2c0386b4f51f6  # SHA1 key
12 SHA1 56eefc7ce3d0ff1a71405ea9db12c7a590eee212  # SHA1 key
13 SHA1 f68a2d3bd8639e12e6d723ea992481082c1c44cf  # SHA1 key
14 SHA1 cb907cd6cb7bb7fd8195b234e985af70143bb5ca  # SHA1 key
15 SHA1 4a243f4e0216bcd9e70ffaba135a15a9d2c2d73c  # SHA1 key
16 SHA1 71619f3870ee35bea35d89597ee9c5121be38fa6  # SHA1 key
17 SHA1 cb1cb1a6135519b8e50010575abe2bfe9adbb733  # SHA1 key
18 SHA1 2bf365d8535197455b06ef8fc6a20a1b6aa5c012  # SHA1 key
19 SHA1 7012d6aab691f53a415330d6b8ed648c8c0e867f  # SHA1 key

MD5 is working only problem is with SHA1.

Thanks,
Sneha
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Unable to use SHA1 with ntp4.2.8p9

2017-01-23 Thread sneha b
This is on windows 7.

On Mon, Jan 23, 2017 at 4:26 PM, sneha b  wrote:

> Hi,
>
> I am using ntp4.2.8p9 with openssl 1.0.2j, with this md5 is working fine.
> But when I use SHA1 I get below error while executine ntpd -q:
>
> "Invalid type for key"
>
> I downloaded the source code from ntp.org with patch and built the exe
> using vxproj.
> Do I need to enable some filags as to use SHA1.
>
> I just set the openssl path in environment variables for include and
> library.
>
> Any inputs or fix in this regard will be of great use, as I am struggling
> since long.
>
> Below is the content of ntp.keys file:
>
> # ntpkey_SHAkey_HCA-R9YL4RC.3627968244
> # Fri Dec 19 14:27:24 2014
>
>  1 MD5 s%hh5/yPldNiCAY@W&t$  # MD5 key
>  2 MD5 Bhq]  3 MD5 q6+*  4 MD5 6S/hBc0tFO37iao@9IWy  # MD5 key
>  5 MD5 tcz/N)BeGZRVth"p0Y;a  # MD5 key
>  6 MD5 Pl_\mk>@PXUV7Z(-xHHl  # MD5 key
>  7 MD5 ytRQhn%1U<}IzW^P0EJ-  # MD5 key
>  8 MD5 W~/3[]6g"ylC9vJTHJ}V  # MD5 key
>  9 MD5 39Udu|jeZ*tcS"o+kKwu  # MD5 key
> 10 MD5 -AJq19S~9Q?GPgbIHoyx  # MD5 key
> 11 SHA1 2fee5e55aae45c9dea60fd2776d2c0386b4f51f6  # SHA1 key
> 12 SHA1 56eefc7ce3d0ff1a71405ea9db12c7a590eee212  # SHA1 key
> 13 SHA1 f68a2d3bd8639e12e6d723ea992481082c1c44cf  # SHA1 key
> 14 SHA1 cb907cd6cb7bb7fd8195b234e985af70143bb5ca  # SHA1 key
> 15 SHA1 4a243f4e0216bcd9e70ffaba135a15a9d2c2d73c  # SHA1 key
> 16 SHA1 71619f3870ee35bea35d89597ee9c5121be38fa6  # SHA1 key
> 17 SHA1 cb1cb1a6135519b8e50010575abe2bfe9adbb733  # SHA1 key
> 18 SHA1 2bf365d8535197455b06ef8fc6a20a1b6aa5c012  # SHA1 key
> 19 SHA1 7012d6aab691f53a415330d6b8ed648c8c0e867f  # SHA1 key
>
> MD5 is working only problem is with SHA1.
>
> Thanks,
> Sneha
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


[ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread Lloyd Dizon
Hi.
I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
offsets between the GPS readings and network NTPs.

lloyd@jadzia:~ $ ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
 LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
0.001
xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
142.320
*ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
1.687
+246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
1.376
+ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
3.299
-khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
4.474



Sometimes it will be the GPS which will have 1000ms offset and the NTP
serveurs will have 4-6ms instead.


Anybody has a clue what is going on?


Thank you.
Lloyd
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread Harlan Stenn
Lloyd Dizon writes:
> Hi.
> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
> offsets between the GPS readings and network NTPs.
> 
> lloyd@jadzia:~ $ ntpq -p
>  remote   refid  st t when poll reach   delay   offset
> jitter
> =
> =
>  LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
> 0.001

Why are you using the LOCAL refclock?

> xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
> 142.320

Is your NMEA source identifying the wrong second?

> *ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
> 1.687
> +246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
> 1.376
> +ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
> 3.299
> -khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
> 4.474

Your NMEA source is sending ntpd samples every 16 seconds.  It's filling
the sample buffer, and the the other sources (are you using iburst on
these?  You should be...) are taking a while to provide enough samples
to detect that your NMEA source is "off" by a second.

> Sometimes it will be the GPS which will have 1000ms offset and the NTP
> serveurs will have 4-6ms instead.
> 
> Anybody has a clue what is going on?

I think your NMEA signal is identifying the wrong second.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread François Meyer

Hi, these are milliseconds, not seconds, so your offset is
1 s, not 1000s.


Anybody has a clue what is going on?


A bogus (out of date) leap second file somewhere on the raspi ?


On Mon, 23 Jan 2017, Lloyd Dizon wrote:


Hi.
I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
offsets between the GPS readings and network NTPs.

lloyd@jadzia:~ $ ntpq -p
remote   refid  st t when poll reach   delay   offset
jitter
==
LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
0.001
xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
142.320
*ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
1.687
+246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
1.376
+ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
3.299
-khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
4.474



Sometimes it will be the GPS which will have 1000ms offset and the NTP
serveurs will have 4-6ms instead.


Anybody has a clue what is going on?


Thank you.
Lloyd
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions



--
François MeyerTel : (+33) 3 81 66 69 27   Mob : 6 27 28 56 83
Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE
Institut UTINAM * Universite de Franche-Comte * CNRS UMR 6213 ***
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread François Meyer
Oops. seems I need some optics upgrade... 
Badly misread, sorry.


On Mon, 23 Jan 2017, François Meyer wrote:


Hi, these are milliseconds, not seconds, so your offset is
1 s, not 1000s.


Anybody has a clue what is going on?


A bogus (out of date) leap second file somewhere on the raspi ?


On Mon, 23 Jan 2017, Lloyd Dizon wrote:


Hi.
I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
offsets between the GPS readings and network NTPs.

lloyd@jadzia:~ $ ntpq -p
remote   refid  st t when poll reach   delay   offset
jitter


==

LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
0.001
xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
142.320
*ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
1.687
+246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
1.376
+ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
3.299
-khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
4.474



Sometimes it will be the GPS which will have 1000ms offset and the NTP
serveurs will have 4-6ms instead.


Anybody has a clue what is going on?


Thank you.
Lloyd
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions



--
François MeyerTel : (+33) 3 81 66 69 27   Mob : 6 27 28 56 83
Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE
Institut UTINAM * Universite de Franche-Comte * CNRS UMR 6213 ***
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


--
François MeyerTel : (+33) 3 81 66 69 27   Mob : 6 27 28 56 83
Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE
Institut UTINAM * Universite de Franche-Comte * CNRS UMR 6213 ***
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread Lloyd Dizon
On Mon, Jan 23, 2017 at 1:03 PM, Harlan Stenn  wrote:

> Lloyd Dizon writes:
> > Hi.
> > I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
> > offsets between the GPS readings and network NTPs.
> >
> > lloyd@jadzia:~ $ ntpq -p
> >  remote   refid  st t when poll reach   delay   offset
> > jitter
> > 
> =
> > =
> >  LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
> > 0.001
>
> Why are you using the LOCAL refclock?
>

I shouldn't. I removed it now.


> xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
> > 142.320
>
> Is your NMEA source identifying the wrong second?
>
> > *ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
> > 1.687
> > +246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
> > 1.376
> > +ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
> > 3.299
> > -khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
> > 4.474
>
> Your NMEA source is sending ntpd samples every 16 seconds.  It's filling
> the sample buffer, and the the other sources (are you using iburst on
> these?  You should be...) are taking a while to provide enough samples
> to detect that your NMEA source is "off" by a second.
>

I changed the min and maxpoll to 6 to be consistent with the network
servers.
I'm still getting a 1000ms offset though.


> Anybody has a clue what is going on?
>
> I think your NMEA signal is identifying the wrong second.
>

So my NMEA device is broken then. Is there a way to compensate manually if
the device is systematically adding (or subtracting) 1000ms. Is is correct
to compensate manually.
I looked at the time1 argument to fudge but I only had 300ms removed from
the offset.

Before using "time1 1":

Every 1.0s: ntpq
-pn
Mon Jan 23 15:27:46 2017

 remote   refid  st t when poll reach   delay   offset
jitter
==
x127.127.20.0.GPS.0 l   48   64   170.000   10.095
6.428
*178.209.53.202  166.171.80.133 u   31   64   37   11.298  1015.56
9.837
+81.94.123.1685.158.25.74 2 u   30   64   379.788  1013.30
9.577
+212.51.144.44   .PPS.1 u   28   64   379.864  1013.35
9.723
+82.197.188.130  195.186.1.1003 u   32   64   379.832  1013.75
9.664


After using time1 1:
Every 1.0s: ntpq
-pn
Mon Jan 23 15:28:27 2017

 remote   refid  st t when poll reach   delay   offset
jitter
==
 127.127.20.0.GPS.0 l   16   6400.0000.000
0.001
*192.33.96.102   .PPS.1 u4   641   13.617  721.727
0.112
+5.148.175.134   131.188.3.2222 u4   6419.377  720.615
0.436
+81.94.123.1785.158.25.74 2 u3   6419.659  720.234
0.552
-46.22.26.12 162.23.41.56 2 u2   641   15.923  722.333
0.171
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread Jan Ceuleers
On 23/01/17 12:25, Lloyd Dizon wrote:
> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
> offsets between the GPS readings and network NTPs.

Could you show us the relevant extracts from your ntp.conf file related
to the GPS source? That is: at least the server line and any fudge lines?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread Lloyd Dizon
Hi.
See below.

On Mon, Jan 23, 2017 at 4:54 PM, Jan Ceuleers 
wrote:

> On 23/01/17 12:25, Lloyd Dizon wrote:
> > I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
> > offsets between the GPS readings and network NTPs.
>
> Could you show us the relevant extracts from your ntp.conf file related
> to the GPS source? That is: at least the server line and any fudge lines?
>

enable mode7

# Local
#server 127.127.1.0
#fudge 127.127.1.0 stratum 10

# GPS with PPS enabled
server 127.127.20.0 mode 17 minpoll 6 maxpoll 6 iburst true prefer
fudge 127.127.20.0 time1 1 flag1 1 refid GPS

# Internet time servers for sanity
server 0.ch.pool.ntp.org iburst prefer
server 1.ch.pool.ntp.org iburst
server 2.ch.pool.ntp.org iburst
server 3.ch.pool.ntp.org iburst

# By default, exchange time with everybody, but don't allow configuration.
restrict default kod limited nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict -6 ::1

# Drift file etc.
driftfile /var/lib/ntp/ntp.drift
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread Mike Cook
Harlen’s idea may be right. If your GPS is seeing a lot of SVs then the NMEA 
stream can overrun the second. The time used is that of the end of the the 
first recognized NMEA sentence containing the time field in the cycle.
If you are able to send the commands necessary, you can limit the data stream 
length by selecting just $GPRMC which is often the first sent.
The NMEA command to do that depends on the receiver. What make/model do you 
have?

To check on what your device is sending, cat your NMEA device.

$ sudo cat /dev/gps0  #  that will get the whole stream 

You can check the UTC date from one sentence against another source to see if 
the seconds field is right. It could be that the receiver isn’t counting in 
leap seconds correctly. I had that with one receiver. 

Does your GPS have PPS output? If you have a scope you can check if the data is 
running into the following second. 

Have fun

> Le 23 janv. 2017 à 13:03, Harlan Stenn  a écrit :
> 
> Lloyd Dizon writes:
>> Hi.
>> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
>> offsets between the GPS readings and network NTPs.
>> 
>> lloyd@jadzia:~ $ ntpq -p
>> remote   refid  st t when poll reach   delay   offset
>> jitter
>> =
>> =
>> LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
>> 0.001
> 
> Why are you using the LOCAL refclock?
> 
>> xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
>> 142.320
> 
> Is your NMEA source identifying the wrong second?
> 
>> *ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
>> 1.687
>> +246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
>> 1.376
>> +ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
>> 3.299
>> -khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
>> 4.474
> 
> Your NMEA source is sending ntpd samples every 16 seconds.  It's filling
> the sample buffer, and the the other sources (are you using iburst on
> these?  You should be...) are taking a while to provide enough samples
> to detect that your NMEA source is "off" by a second.
> 
>> Sometimes it will be the GPS which will have 1000ms offset and the NTP
>> serveurs will have 4-6ms instead.
>> 
>> Anybody has a clue what is going on?
> 
> I think your NMEA signal is identifying the wrong second.
> -- 
> Harlan Stenn 
> http://networktimefoundation.org - be a member!
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations

2017-01-23 Thread Charles Elliott
> Do you know if there are any means to configure server B so that it does
not allow server A to mobilize > a dynamic symmetric association (meaning B
should still provide time services to A, but should not > consider A as a
time source)? Maybe there is a similar option to nopeers, but I cannot find
any in NTP >documentation.

But this is the normal (Unicast) situation.  Unless I am missing something
here, just don't tell B that A exists.  B does not have to know anything
about A for NTPD to work correctly.  The peer relationship is rarely used.
In fact, I don't remember anyone ever asking about the peer option before.

Charles Elliott



-Original Message-
From: questions
[mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of
Moser, Stefan
Sent: Monday, January 23, 2017 3:53 AM
To: questions@lists.ntp.org
Subject: [ntp:questions] Can I stop authenticated peers from mobilizing
symmetric associations

Hello everyone,

for unauthenticated peers, there is the restrict nopeer directive that stops
unknown peers to initialize dynamic symmetric associations with an NTP
server. However, from my own tests in my lab (and from NTP documentation),
it seems that nopeer does not pertain to authenticated peers. In my lab, I
saw this: If server A knows the authentication key of Server B and has a
peer IP_address_of_server_B directive in its ntp.conf, A is able to form a
dynamic symmetric association with server B even if server B has no
configuration for server A at all, and server B lists server A in its
association table (ntpq -p, type shown as S).

Do you know if there are any means to configure server B so that it does not
allow server A to mobilize a dynamic symmetric association (meaning B should
still provide time services to A, but should not consider A as a time
source)? Maybe there is a similar option to nopeers, but I cannot find any
in NTP documentation.

Stefan

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread Jan Ceuleers
On 23/01/17 17:43, Lloyd Dizon wrote:
>
> On Mon, Jan 23, 2017 at 4:54 PM, Jan Ceuleers
> mailto:jan.ceule...@computer.org>> wrote:
>
> Could you show us the relevant extracts from your ntp.conf file
> related
> to the GPS source? That is: at least the server line and any fudge
> lines?
>
>
> enable mode7
> (etc)

Okay, your offset isn't caused by a fudge factor. I'm out.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread Brian Inglis
On 2017-01-23 09:43, Lloyd Dizon wrote:
> On Mon, Jan 23, 2017 at 4:54 PM, Jan Ceuleers wrote:
>> On 23/01/17 12:25, Lloyd Dizon wrote:
>>> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
>>> offsets between the GPS readings and network NTPs.
>> Could you show us the relevant extracts from your ntp.conf file related
>> to the GPS source? That is: at least the server line and any fudge lines?
> # GPS with PPS enabled
> server 127.127.20.0 mode 17 minpoll 6 maxpoll 6 iburst true prefer
> fudge 127.127.20.0 time1 1 flag1 1 refid GPS

NMEA drivers need about 4.-.6s time2 fudge split the difference; 
if you have PPS enabled in the kernel, try: 

server 127.127.20.0 mode 17 prefer minpoll 4 maxpoll 4
fudge  127.127.20.0 flag1 1 flag3 1 time2 0.500 # pps kernel msg offset .5s

without PPS enabled, GPS is only good for navigation.
Give it 15 minutes to load the almanac and leap seconds count, and start 
providing UTC instead of GPS time.
If your GPS provider provides almanac data and a utility to preload it, 
you have to add that to the startup script.
Setting the CPU governor to performance in there also helps frequency 
stability.
I'm keeping low us time even over wifi network:

$ ntpq -p -c rl -c cl
 remote   refid  st t when poll reach   delay   offset  jitter
==
oGPS_NMEA(0) .GPS.0 l   12   16  3770.0000.003   0.001
*W10 .GPS.1 s7   16  3771.8890.542  43.149
+nist-time-serve .ACTS.   1 u   22   64  377   76.064  -14.426 102.263
+utcnist2.colora .NIST.   1 u   35   64  377   89.428   -8.613  68.220
+nisttime.edzone .ACTS.   1 u   50   64  377  102.386  -22.114  82.215
+montpelier.ilan .GPS.1 u4   64  377  110.528   -8.813  86.635
+tock.usnogps.na .PTP.1 u   31   64  377  127.9910.042  87.657
-ns2.cs.ucalgary 136.159.2.2492 u   35   64  377   13.4112.875   2.666
+SUE.CC.UREGINA. 142.3.100.2  2 u-   64  377   30.631   -1.914  75.804
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd 4.2.6p5@1.2349-o Mon Sep 19 21:57:11 UTC 2016 (1)",
processor="armv7l", system="Linux/4.4.38-v7+", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdisp=0.417, refid=GPS,
reftime=dc30ee85.86d31d83  Mon, Jan 23 2017 21:05:09.526,
clock=dc30ee92.d5162ac9  Mon, Jan 23 2017 21:05:22.832, peer=14553, tc=4,
mintc=3, offset=0.003, frequency=-4.292, sys_jitter=0.001,
clk_jitter=0.000, clk_wander=0.001, tai=37, leapsec=20170101,
expire=20170628
associd=0 status=00f2 15 events, clk_bad_format,
device="NMEA GPS Clock",
timecode="$GPRMC,210521.000,A,5108.3564,N,11411.5671,W,0.62,342.03,230117,,,D*71",
poll=64009, noreply=0, badformat=30, baddata=0, fudgetime1=0.000,
stratum=0, refid=GPS, flags=5

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations

2017-01-23 Thread Brian Inglis
On 2017-01-23 10:17, Charles Elliott wrote:
>> On Monday, January 23, 2017 3:53 AM, Moser, Stefan wrote:
>> for unauthenticated peers, there is the restrict nopeer directive
>> that stops unknown peers to initialize dynamic symmetric
>> associations with an NTP server. However, from my own tests in my
>> lab (and from NTP documentation), it seems that nopeer does not
>> pertain to authenticated peers. In my lab, I saw this: If server A
>> knows the authentication key of Server B and has a peer

B does not know A exists according to this:

>> IP_address_of_server_B directive in its ntp.conf, A is able to form
>> a dynamic symmetric association with server B even if server B has
>> no configuration for server A at all, and server B lists server A
>> in its association table (ntpq -p, type shown as S).
>> Do you know if there are any means to configure server B so that it
>> does not allow server A to mobilize a dynamic symmetric association
>> (meaning B should still provide time services to A, but should not
>> consider A as a time source)? Maybe there is a similar option to
>> nopeers, but I cannot find any in NTP documentation.

Are you sure you have not defined A in B using an alternate name or 
IP address?
Have you tried explicitly defining A in B as a server with noselect?
See https://www.eecis.udel.edu/~mills/ntp/html/confopt.html

> But this is the normal (Unicast) situation. Unless I am missing
> something here, just don't tell B that A exists. B does not have to
> know anything about A for NTPD to work correctly. The peer
> relationship is rarely used. In fact, I don't remember anyone ever
> asking about the peer option before.

A number of us use it between our GPS enabled home systems on the LAN, 
and others use it between their campus and lab systems with ref clocks.
It's cheaper and easier than TWSTFT when you're not a national lab 
providing UTC with access to sat channels. ;^>

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Unable to use SHA1 with ntp4.2.8p9

2017-01-23 Thread Brian Inglis
On 2017-01-23 03:57, sneha b wrote:
> On Mon, Jan 23, 2017 at 4:26 PM, sneha b wrote:
>> I am using ntp4.2.8p9 with openssl 1.0.2j, with this md5 is working
>> fine.
>> But when I use SHA1 I get below error while executine ntpd -q:
>> "Invalid type for key"
>> I downloaded the source code from ntp.org with patch and built the
>> exe using vxproj.
>> Do I need to enable some filags as to use SHA1.
>> I just set the openssl path in environment variables for include and
>> library.
>> Any inputs or fix in this regard will be of great use, as I am
>> struggling since long.
>> Below is the content of ntp.keys file:
>> # ntpkey_SHAkey_HCA-R9YL4RC.3627968244
>> # Fri Dec 19 14:27:24 2014
>>  1 MD5 s%hh5/yPldNiCAY@W&t$  # MD5 key
>>  2 MD5 Bhq]>  3 MD5 q6+*>  4 MD5 6S/hBc0tFO37iao@9IWy  # MD5 key
>>  5 MD5 tcz/N)BeGZRVth"p0Y;a  # MD5 key
>>  6 MD5 Pl_\mk>@PXUV7Z(-xHHl  # MD5 key
>>  7 MD5 ytRQhn%1U<}IzW^P0EJ-  # MD5 key
>>  8 MD5 W~/3[]6g"ylC9vJTHJ}V  # MD5 key
>>  9 MD5 39Udu|jeZ*tcS"o+kKwu  # MD5 key
>> 10 MD5 -AJq19S~9Q?GPgbIHoyx  # MD5 key
>> 11 SHA1 2fee5e55aae45c9dea60fd2776d2c0386b4f51f6  # SHA1 key
>> 12 SHA1 56eefc7ce3d0ff1a71405ea9db12c7a590eee212  # SHA1 key
>> 13 SHA1 f68a2d3bd8639e12e6d723ea992481082c1c44cf  # SHA1 key
>> 14 SHA1 cb907cd6cb7bb7fd8195b234e985af70143bb5ca  # SHA1 key
>> 15 SHA1 4a243f4e0216bcd9e70ffaba135a15a9d2c2d73c  # SHA1 key
>> 16 SHA1 71619f3870ee35bea35d89597ee9c5121be38fa6  # SHA1 key
>> 17 SHA1 cb1cb1a6135519b8e50010575abe2bfe9adbb733  # SHA1 key
>> 18 SHA1 2bf365d8535197455b06ef8fc6a20a1b6aa5c012  # SHA1 key
>> 19 SHA1 7012d6aab691f53a415330d6b8ed648c8c0e867f  # SHA1 key
>> MD5 is working only problem is with SHA1.
> This is on windows 7.

Try Meinberg 4.2.8p5 (optionally have it install files only):

https://www.meinbergglobal.com/download/ntp/windows/ntp-4.2.8p5-win32-setup.exe

especially if you are using NMEA ref clocks, there are still some 
issues in later releases being worked on for next release.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] 1000s offset between GPS module and NTP servers

2017-01-23 Thread juergen perlinger
Hi all,

On 01/23/2017 05:43 PM, Lloyd Dizon wrote:
> Hi.
> See below.
> 
> On Mon, Jan 23, 2017 at 4:54 PM, Jan Ceuleers 
> wrote:
> 
>> On 23/01/17 12:25, Lloyd Dizon wrote:
>>> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
>>> offsets between the GPS readings and network NTPs.
>>
>> Could you show us the relevant extracts from your ntp.conf file related
>> to the GPS source? That is: at least the server line and any fudge lines?
>>
> 
> enable mode7
> 
> # Local
> #server 127.127.1.0
> #fudge 127.127.1.0 stratum 10
> 
> # GPS with PPS enabled
> server 127.127.20.0 mode 17 minpoll 6 maxpoll 6 iburst true prefer
> fudge 127.127.20.0 time1 1 flag1 1 refid GPS

Why do you add one full second time correction to the time PPS stamp?

I admit that having the output of ntpq in millisecs and the config vaues
in seconds is confusing, but 'time1 1' adds a full second to the PPS
time stamp. This shouldn't be needed -- PPS delay correction is in the
sub-millisecond range if it's used at all.

If you have problems with a huge delay between PPS and your first NMEA
sentence of a new burst, use fudge time2 (!!) to compensate for that.
This can just lead to assigning a wrong second to the PPS value, see

http://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks
https://support.ntp.org/bin/view/Support/ConfiguringGarminRefclocks
http://doc.ntp.org/current-stable/drivers/driver20.html

I'm using a GPS18x-LVC with the following settings:

server 127.127.20.0 mode 33 noselect minpoll 4 maxpoll 8
fudge 127.127.20.0 flag1 1 time2 0.51 refid GPSc

Note the time2 offset of 510msec that I need to get the NMEA data stream
aligned with the PPS signal. If I don't do this, I end up with the wrong
second assigned to the PPS signal, too.

> 
> # Internet time servers for sanity
> server 0.ch.pool.ntp.org iburst prefer
> server 1.ch.pool.ntp.org iburst
> server 2.ch.pool.ntp.org iburst
> server 3.ch.pool.ntp.org iburst
> 
> # By default, exchange time with everybody, but don't allow configuration.
> restrict default kod limited nomodify notrap nopeer noquery
> restrict -6 default kod limited nomodify notrap nopeer noquery
> 
> # Local users may interrogate the ntp server more closely.
> restrict 127.0.0.1
> restrict -6 ::1
> 
> # Drift file etc.
> driftfile /var/lib/ntp/ntp.drift
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions