Re: [ntp:questions] NTP not syncing immediately

[Mike Cook]

Can’t remember who the OP was…

The original ntp.conf, if that was all the entries reference just the local 
clock so why start ntp at all. There will be no disciplining anyway.

That aside I have just run some tests on a non windows machine and don’t see 
the issue, unless you are saying that you do not see the ‘*’ next to  the local 
clock. 
That I do not see on startup with your config.
It can be corrected by the following:

server 127.127.1.0 prefer  
fudge 127.127.1.0 stratum 0
restrict 127.127.1.0

Then on start up:

Sat Sep 19 08:56:43 UTC 2015
[ ok ] Starting ntpd (via systemctl): ntpd.service.

Sat Sep 19 08:56:44 UTC 2015
 remote   refid  st t when poll reach   delay   offset  jitter
==
*127.127.1.0 .LOCL.   0 l-   6410.0000.000   0.002

there is sync with one second difference, but as I was polling with ntpq at 2 
sec intervals it my be less than one second. Probably immediate.

Hope that helps.

Mike

> Le 18 sept. 2015 à 18:24, Kiss Gábor  a écrit :
> 
>> I want to sync immediately, my project requires to sync immediately as the
>> client is real time systems.
> 
> I'm afraid "real time system" means something else. :-)
> It is not related to wallclock time.
> https://en.wikipedia.org/wiki/Real-time_computing
> 
> Gabor
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The main function of a modern police force is filling in forms."
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP not syncing immediately

[Marco Marongiu]

I can't really say, posting your full ntp.conf could help better.

Are you syncing against public or internal ntp servers?

Regards
-- M
On 18 Sep 2015 17:14, "sneha b"  wrote:

> Hi,
>
> NTP is not syncing immediately, its taking some 3 minutes time.
> I want to sync immediately, my project requires to sync immediately as the
> client is real time systems.
>
>
>
> NTP server is responding with below messages. Below are the wireshark
> captures.
>
> Flags: 0x0c
> 11..  = Leap Indicator: unknown (clock unsynchronized) (3)
> ..00 1... = Version number: NTP Version 1 (1)
>  .100 = Mode: server (4)
> Peer Clock Stratum: unspecified or invalid (0)
> Peer Polling Interval: invalid (0)
> Peer Clock Precision: 0.08 sec
> Root Delay:0. sec
> Reference Timestamp: Jan  1, 1970 00:00:00.0 UTC
> My ntp.conf file has below enteries:
>
> server 127.127.1.0
> fudge 127.127.1.0 stratum 0
> restrict 127.127.1.0
>
> If any insights will be of a very great help.
>
>
> I am stopping the service windows time.
>
> After some 3 minutes the sync is happening properly.But its not happening
> immediately. Can anybody help me in resolving.
>
> Thanks,
> Sneha
> ___
> 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] NTP not syncing immediately

[Kiss Gábor]

> I want to sync immediately, my project requires to sync immediately as the
> client is real time systems.

I'm afraid "real time system" means something else. :-)
It is not related to wallclock time.
https://en.wikipedia.org/wiki/Real-time_computing

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

Re: [ntp:questions] NTP not syncing to configured servers

[Chandra Kanth]

FYI,

This is the way we add server, so we are using iburst option already.

addserver 10.126.142.198 0  3  iburst minpoll 4 maxpoll 4

Thanks
Chandrakanth

On Wed, May 13, 2015 at 10:31 PM, Dallas Graves  wrote:

> Can you clarify if you’re setting “stratum 5” on your target servers, or
> your local “fudge” server?
>
> As far as I know, remote NTP servers should not require stratum option.  I
> only use this option on my local time source, and by that I mean issuing a
> rather high value as to ensure that it’s selected last.  One thing you may
> want to try is using iburst option which instructs NTP to issue 8 request
> packets if the first is not received, this often helps with network-related
> issues (which you may or may not be experiencing).
>
> If this is not helpful, perhaps you could sanitize your config and share
> it with the mailing list so we can better help you?
>
> Thanks,
> -Dallas
>
>
> On May 13, 2015, at 11:08 AM, Chandra Kanth  wrote:
>
> OK. Lets rule out its ACL/firewall issue. I have been able to use ntpdate
> -d command. I used it several times on this setup.
>
> Next, do you think arbitrary setting of stratum to low value such as 5 is
> problem?
> FYI, these servers are high end routers, so that's why we set its stratum
> to 5.
>
> On what basis we should set stratum value? What is the appropriate value?
> How do we determine what should be the stratum?
>
> Regards
> Chandrakanth
>
> On Wed, May 13, 2015 at 9:33 PM, Dallas Graves 
> wrote:
>
>> Your question is quite clear.  As I stated, you want to ensure that you
>> can, in fact, access the targeted NTP servers via the debug switch in the
>> ntpdate command.  If you’ve confirmed that access is not blocked by
>> firewall and/or ACL, then you’ll want to make sure you set the stratum
>> correctly in the ntp.conf configuration, ensuring that your fudge or (local
>> time source) is set at a higher stratum such as 10.
>>
>> Hope this helps.
>>
>> -Dallas
>>
>>
>>
>> On May 13, 2015, at 10:58 AM, Chandra Kanth  wrote:
>>
>> Hi Graves, Yu,
>>
>> First of all thanks for response. Let me clarify, this is private lab
>> setup, no public ntp servers.
>> The idea is to setup private ntp subnet, where the time on servers such
>> as .198 and .204 should be propagated to other clients.
>>
>> Think as .198 and .204 as private ntp servers which is configured as
>> lower stratum server. (i.e. /etc/ntp.conf contains stratum 5). So these
>> servers does not get a reference clock from any other lower stratum i.e.
>> stratum 4. It simply provides system time from its own local clock.
>>
>> The client here which .196 is running at higher stratum i.e. 10.
>>
>> So I'm was hoping the client (.196) should sync to any one of the server
>> since at least their stratum is lower.
>>
>> I hope the question is clear.
>>
>> Regards
>> Chandrakanth
>>
>>
>> On Wed, May 13, 2015 at 7:42 PM, Dallas Graves 
>> wrote:
>>
>>> To expound upon Yu’s comment.  If you don’t have access to the firewall,
>>> a good check would be to conduct a test against each of your targeted NTP
>>> servers with the “ntpdate -d” command, which is the debug switch and will
>>> let you know if you can or cannot reach the intended systems.
>>>
>>> -Dallas
>>>
>>>
>>> > On May 13, 2015, at 8:54 AM, Wang, Yu  wrote:
>>> >
>>> > Do your ntp servers have public IP addresses configured or do you do
>>> NAT for the two ntp servers? 10.126.142.198 and 10.126.142.204 are private
>>> addresses and won't be routed over the Internet.
>>> > The second place to check is firewall. Make sure it opens to upd/123
>>> between your ntp servers and outside ntp servers.
>>> >
>>> > Yu
>>> > Core Networking, FSU
>>> >
>>> >
>>> > -Original Message-
>>> > From: questions [mailto:questions-bounces+ywang10=
>>> fsu@lists.ntp.org] On Behalf Of Chandrakanth K
>>> > Sent: Wednesday, May 13, 2015 7:52 AM
>>> > To: questions@lists.ntp.org
>>> > Subject: [ntp:questions] NTP not syncing to configured servers
>>> >
>>> > Hi,
>>> >
>>> > I am seeing ntp not syncing to external configured servers. We tried
>>> both 4.2.4 and 4.2.6 versions.
>>> > The following is the configuration,
>>> >
>>> > We use two servers 10.126.142.198 and 10.126.142.204 in our Lab.
>>> > They are statically configured as running @ stratum level 5 and
>>> providing the clock from its own local clock.
>>> >
>>> > Even though the servers does not have a valid reference time and
>>> provides time from its own clock, according to me still we need to be able
>>> to sync to it since it is running at better stratum.
>>> > Please clarify.
>>> >
>>> > Logs:
>>> > -
>>> >
>>> > bash-4.2$ ntpq -np -c assoc
>>> > remote   refid  st t when poll reach   delay   offset
>>> jitter
>>> >
>>> ==
>>> > *127.127.1.0 .LOCL.  10 l   19   64  3770.000
>>> 0.000   0.001
>>> > 10.126.142.198  LOCAL(0) 6 u7   16  3770

Re: [ntp:questions] NTP not syncing to configured servers

[Chandra Kanth]

OK. Lets rule out its ACL/firewall issue. I have been able to use ntpdate
-d command. I used it several times on this setup.

Next, do you think arbitrary setting of stratum to low value such as 5 is
problem?
FYI, these servers are high end routers, so that's why we set its stratum
to 5.

On what basis we should set stratum value? What is the appropriate value?
How do we determine what should be the stratum?

Regards
Chandrakanth

On Wed, May 13, 2015 at 9:33 PM, Dallas Graves  wrote:

> Your question is quite clear.  As I stated, you want to ensure that you
> can, in fact, access the targeted NTP servers via the debug switch in the
> ntpdate command.  If you’ve confirmed that access is not blocked by
> firewall and/or ACL, then you’ll want to make sure you set the stratum
> correctly in the ntp.conf configuration, ensuring that your fudge or (local
> time source) is set at a higher stratum such as 10.
>
> Hope this helps.
>
> -Dallas
>
>
>
> On May 13, 2015, at 10:58 AM, Chandra Kanth  wrote:
>
> Hi Graves, Yu,
>
> First of all thanks for response. Let me clarify, this is private lab
> setup, no public ntp servers.
> The idea is to setup private ntp subnet, where the time on servers such as
> .198 and .204 should be propagated to other clients.
>
> Think as .198 and .204 as private ntp servers which is configured as lower
> stratum server. (i.e. /etc/ntp.conf contains stratum 5). So these servers
> does not get a reference clock from any other lower stratum i.e. stratum 4.
> It simply provides system time from its own local clock.
>
> The client here which .196 is running at higher stratum i.e. 10.
>
> So I'm was hoping the client (.196) should sync to any one of the server
> since at least their stratum is lower.
>
> I hope the question is clear.
>
> Regards
> Chandrakanth
>
>
> On Wed, May 13, 2015 at 7:42 PM, Dallas Graves 
> wrote:
>
>> To expound upon Yu’s comment.  If you don’t have access to the firewall,
>> a good check would be to conduct a test against each of your targeted NTP
>> servers with the “ntpdate -d” command, which is the debug switch and will
>> let you know if you can or cannot reach the intended systems.
>>
>> -Dallas
>>
>>
>> > On May 13, 2015, at 8:54 AM, Wang, Yu  wrote:
>> >
>> > Do your ntp servers have public IP addresses configured or do you do
>> NAT for the two ntp servers? 10.126.142.198 and 10.126.142.204 are private
>> addresses and won't be routed over the Internet.
>> > The second place to check is firewall. Make sure it opens to upd/123
>> between your ntp servers and outside ntp servers.
>> >
>> > Yu
>> > Core Networking, FSU
>> >
>> >
>> > -Original Message-
>> > From: questions [mailto:questions-bounces+ywang10=fsu@lists.ntp.org]
>> On Behalf Of Chandrakanth K
>> > Sent: Wednesday, May 13, 2015 7:52 AM
>> > To: questions@lists.ntp.org
>> > Subject: [ntp:questions] NTP not syncing to configured servers
>> >
>> > Hi,
>> >
>> > I am seeing ntp not syncing to external configured servers. We tried
>> both 4.2.4 and 4.2.6 versions.
>> > The following is the configuration,
>> >
>> > We use two servers 10.126.142.198 and 10.126.142.204 in our Lab.
>> > They are statically configured as running @ stratum level 5 and
>> providing the clock from its own local clock.
>> >
>> > Even though the servers does not have a valid reference time and
>> provides time from its own clock, according to me still we need to be able
>> to sync to it since it is running at better stratum.
>> > Please clarify.
>> >
>> > Logs:
>> > -
>> >
>> > bash-4.2$ ntpq -np -c assoc
>> > remote   refid  st t when poll reach   delay   offset
>> jitter
>> >
>> ==
>> > *127.127.1.0 .LOCL.  10 l   19   64  3770.0000.000
>>  0.001
>> > 10.126.142.198  LOCAL(0) 6 u7   16  3770.172
>> 859.844   0.501
>> > 10.126.142.204  LOCAL(0) 6 u   15   16  3770.227
>> 1057.22   0.240
>> >
>> > ind assID status  conf reach auth condition  last_event cnt
>> ===
>> >  1 26554  9614   yes   yes  none  sys.peer   reachable  1
>> >  2 26555  9014   yes   yes  nonereject   reachable  1
>> >  3 26556  9014   yes   yes  nonereject   reachable  1
>> >
>> > Logs: 10.126.142.198
>> > ---
>> > bash-4.2$ ntpq -np -c assoc
>> > remote   refid  st t when poll reach   delay   offset
>> jitter
>> >
>> ==
>> > *127.127.1.0 .LOCL.   5 l   10   64  3770.0000.000
>>  0.000
>> >
>> > ind assid status  conf reach auth condition  last_event cnt
>> ===
>> >  1 48508  965a   yes   yes  none  sys.peersys_peer  5
>> >
>> >
>> > Logs: 10.126.142.204
>> > ---
>> >
>> > bash-4.2$ nt

Re: [ntp:questions] NTP not syncing to configured servers

[Chandra Kanth]

Also you can see that the reach is 377 to both of the servers. So reach is
not a problem and not firewall issue etc.
It is something to do with the algorithm. Why ntp has rejected the servers?
Based on what values?
Is it offset, jitter, etc?

Thanks
Chandrakanth

On Wed, May 13, 2015 at 9:28 PM, Chandra Kanth  wrote:

> Hi Graves, Yu,
>
> First of all thanks for response. Let me clarify, this is private lab
> setup, no public ntp servers.
> The idea is to setup private ntp subnet, where the time on servers such as
> .198 and .204 should be propagated to other clients.
>
> Think as .198 and .204 as private ntp servers which is configured as lower
> stratum server. (i.e. /etc/ntp.conf contains stratum 5). So these servers
> does not get a reference clock from any other lower stratum i.e. stratum 4.
> It simply provides system time from its own local clock.
>
> The client here which .196 is running at higher stratum i.e. 10.
>
> So I'm was hoping the client (.196) should sync to any one of the server
> since at least their stratum is lower.
>
> I hope the question is clear.
>
> Regards
> Chandrakanth
>
>
> On Wed, May 13, 2015 at 7:42 PM, Dallas Graves 
> wrote:
>
>> To expound upon Yu’s comment.  If you don’t have access to the firewall,
>> a good check would be to conduct a test against each of your targeted NTP
>> servers with the “ntpdate -d” command, which is the debug switch and will
>> let you know if you can or cannot reach the intended systems.
>>
>> -Dallas
>>
>>
>> > On May 13, 2015, at 8:54 AM, Wang, Yu  wrote:
>> >
>> > Do your ntp servers have public IP addresses configured or do you do
>> NAT for the two ntp servers? 10.126.142.198 and 10.126.142.204 are private
>> addresses and won't be routed over the Internet.
>> > The second place to check is firewall. Make sure it opens to upd/123
>> between your ntp servers and outside ntp servers.
>> >
>> > Yu
>> > Core Networking, FSU
>> >
>> >
>> > -Original Message-
>> > From: questions [mailto:questions-bounces+ywang10=fsu@lists.ntp.org]
>> On Behalf Of Chandrakanth K
>> > Sent: Wednesday, May 13, 2015 7:52 AM
>> > To: questions@lists.ntp.org
>> > Subject: [ntp:questions] NTP not syncing to configured servers
>> >
>> > Hi,
>> >
>> > I am seeing ntp not syncing to external configured servers. We tried
>> both 4.2.4 and 4.2.6 versions.
>> > The following is the configuration,
>> >
>> > We use two servers 10.126.142.198 and 10.126.142.204 in our Lab.
>> > They are statically configured as running @ stratum level 5 and
>> providing the clock from its own local clock.
>> >
>> > Even though the servers does not have a valid reference time and
>> provides time from its own clock, according to me still we need to be able
>> to sync to it since it is running at better stratum.
>> > Please clarify.
>> >
>> > Logs:
>> > -
>> >
>> > bash-4.2$ ntpq -np -c assoc
>> > remote   refid  st t when poll reach   delay   offset
>> jitter
>> >
>> ==
>> > *127.127.1.0 .LOCL.  10 l   19   64  3770.0000.000
>>  0.001
>> > 10.126.142.198  LOCAL(0) 6 u7   16  3770.172
>> 859.844   0.501
>> > 10.126.142.204  LOCAL(0) 6 u   15   16  3770.227
>> 1057.22   0.240
>> >
>> > ind assID status  conf reach auth condition  last_event cnt
>> ===
>> >  1 26554  9614   yes   yes  none  sys.peer   reachable  1
>> >  2 26555  9014   yes   yes  nonereject   reachable  1
>> >  3 26556  9014   yes   yes  nonereject   reachable  1
>> >
>> > Logs: 10.126.142.198
>> > ---
>> > bash-4.2$ ntpq -np -c assoc
>> > remote   refid  st t when poll reach   delay   offset
>> jitter
>> >
>> ==
>> > *127.127.1.0 .LOCL.   5 l   10   64  3770.0000.000
>>  0.000
>> >
>> > ind assid status  conf reach auth condition  last_event cnt
>> ===
>> >  1 48508  965a   yes   yes  none  sys.peersys_peer  5
>> >
>> >
>> > Logs: 10.126.142.204
>> > ---
>> >
>> > bash-4.2$ ntpq -np -c assoc
>> > remote   refid  st t when poll reach   delay   offset
>> jitter
>> >
>> ==
>> > *127.127.1.0 .LOCL.   5 l   13   64  3770.0000.000
>>  0.000
>> >
>> > ind assid status  conf reach auth condition  last_event cnt
>> ===
>> >  1 32737  963a   yes   yes  none  sys.peersys_peer  3
>> >
>> >
>> > Regards
>> > Chandrakanth
>> > ___
>> > questions mailing list
>> > questions@lists.ntp.org
>> > http://lists.ntp.org/listinfo/questions
>> > 

Re: [ntp:questions] NTP not syncing to configured servers

[Chandra Kanth]

One more issue is if I set the server stratum to 10, then both client and
servers both run at the same stratum level.
Then how will the client give priority to servers and sync to it?

Regards
Chandrakanth

On Wed, May 13, 2015 at 9:38 PM, Chandra Kanth  wrote:

> OK. Lets rule out its ACL/firewall issue. I have been able to use ntpdate
> -d command. I used it several times on this setup.
>
> Next, do you think arbitrary setting of stratum to low value such as 5 is
> problem?
> FYI, these servers are high end routers, so that's why we set its stratum
> to 5.
>
> On what basis we should set stratum value? What is the appropriate value?
> How do we determine what should be the stratum?
>
> Regards
> Chandrakanth
>
> On Wed, May 13, 2015 at 9:33 PM, Dallas Graves 
> wrote:
>
>> Your question is quite clear.  As I stated, you want to ensure that you
>> can, in fact, access the targeted NTP servers via the debug switch in the
>> ntpdate command.  If you’ve confirmed that access is not blocked by
>> firewall and/or ACL, then you’ll want to make sure you set the stratum
>> correctly in the ntp.conf configuration, ensuring that your fudge or (local
>> time source) is set at a higher stratum such as 10.
>>
>> Hope this helps.
>>
>> -Dallas
>>
>>
>>
>> On May 13, 2015, at 10:58 AM, Chandra Kanth  wrote:
>>
>> Hi Graves, Yu,
>>
>> First of all thanks for response. Let me clarify, this is private lab
>> setup, no public ntp servers.
>> The idea is to setup private ntp subnet, where the time on servers such
>> as .198 and .204 should be propagated to other clients.
>>
>> Think as .198 and .204 as private ntp servers which is configured as
>> lower stratum server. (i.e. /etc/ntp.conf contains stratum 5). So these
>> servers does not get a reference clock from any other lower stratum i.e.
>> stratum 4. It simply provides system time from its own local clock.
>>
>> The client here which .196 is running at higher stratum i.e. 10.
>>
>> So I'm was hoping the client (.196) should sync to any one of the server
>> since at least their stratum is lower.
>>
>> I hope the question is clear.
>>
>> Regards
>> Chandrakanth
>>
>>
>> On Wed, May 13, 2015 at 7:42 PM, Dallas Graves 
>> wrote:
>>
>>> To expound upon Yu’s comment.  If you don’t have access to the firewall,
>>> a good check would be to conduct a test against each of your targeted NTP
>>> servers with the “ntpdate -d” command, which is the debug switch and will
>>> let you know if you can or cannot reach the intended systems.
>>>
>>> -Dallas
>>>
>>>
>>> > On May 13, 2015, at 8:54 AM, Wang, Yu  wrote:
>>> >
>>> > Do your ntp servers have public IP addresses configured or do you do
>>> NAT for the two ntp servers? 10.126.142.198 and 10.126.142.204 are private
>>> addresses and won't be routed over the Internet.
>>> > The second place to check is firewall. Make sure it opens to upd/123
>>> between your ntp servers and outside ntp servers.
>>> >
>>> > Yu
>>> > Core Networking, FSU
>>> >
>>> >
>>> > -Original Message-
>>> > From: questions [mailto:questions-bounces+ywang10=
>>> fsu@lists.ntp.org] On Behalf Of Chandrakanth K
>>> > Sent: Wednesday, May 13, 2015 7:52 AM
>>> > To: questions@lists.ntp.org
>>> > Subject: [ntp:questions] NTP not syncing to configured servers
>>> >
>>> > Hi,
>>> >
>>> > I am seeing ntp not syncing to external configured servers. We tried
>>> both 4.2.4 and 4.2.6 versions.
>>> > The following is the configuration,
>>> >
>>> > We use two servers 10.126.142.198 and 10.126.142.204 in our Lab.
>>> > They are statically configured as running @ stratum level 5 and
>>> providing the clock from its own local clock.
>>> >
>>> > Even though the servers does not have a valid reference time and
>>> provides time from its own clock, according to me still we need to be able
>>> to sync to it since it is running at better stratum.
>>> > Please clarify.
>>> >
>>> > Logs:
>>> > -
>>> >
>>> > bash-4.2$ ntpq -np -c assoc
>>> > remote   refid  st t when poll reach   delay   offset
>>> jitter
>>> >
>>> ==
>>> > *127.127.1.0 .LOCL.  10 l   19   64  3770.000
>>> 0.000   0.001
>>> > 10.126.142.198  LOCAL(0) 6 u7   16  3770.172
>>> 859.844   0.501
>>> > 10.126.142.204  LOCAL(0) 6 u   15   16  3770.227
>>> 1057.22   0.240
>>> >
>>> > ind assID status  conf reach auth condition  last_event cnt
>>> ===
>>> >  1 26554  9614   yes   yes  none  sys.peer   reachable  1
>>> >  2 26555  9014   yes   yes  nonereject   reachable  1
>>> >  3 26556  9014   yes   yes  nonereject   reachable  1
>>> >
>>> > Logs: 10.126.142.198
>>> > ---
>>> > bash-4.2$ ntpq -np -c assoc
>>> > remote   refid  st t when poll reach   delay   offset
>>> jitter
>>> >
>>> ==

Re: [ntp:questions] NTP not syncing to configured servers

[Chandra Kanth]

Hi Jochen,

We took care of restarting ntpd in fact. First we start ntpd with -g -q
option. This is similar to ntpdate command.
The -q causes it to quit after setting time.

Then ntpd is started with -g option and runs forever.
What other logs/output will be help here?

Regards
Chandrakanth


On Thu, May 14, 2015 at 1:30 AM, Jochen Bern 
wrote:

> On 05/13/2015 01:52 PM, Chandrakanth K wrote:
> > bash-4.2$ ntpq -np -c assoc
> >  remote   refid  st t when poll reach   delay   offset
> jitter
> >
> 
> > *127.127.1.0 .LOCL.  10 l   19   64  3770.0000.000
>  0.001
> >  10.126.142.198  LOCAL(0) 6 u7   16  3770.172  859.844
>  0.501
> >  10.126.142.204  LOCAL(0) 6 u   15   16  3770.227  1057.22
>  0.240
>
> ntpd has connected to both remote servers and retrieved data from them,
> so it's not an outright packet block on some firewall. Instead ...
>
> > ind assID status  conf reach auth condition  last_event cnt
> > =
> >   1 26554  9614   yes   yes  none  sys.peer   reachable  1
> >   2 26555 9014   yes   yes  nonereject   reachable  1
> >   3 26556  9014   yes   yes  nonereject   reachable  1
>
> ... it saw fit to label them as "reject"ed.
>
> I'ld guess that the two servers having an offset of ~0.2 s with respect
> to each other plays a role in that, and the client having another ~0.9 s
> offset from their average might be an obstacle until you restart the
> client ntpd, too.
>
> Regards,
> J. Bern
> --
> *NEU* - NEC IT-Infrastruktur-Produkte im :
> Server--Storage--Virtualisierung--Management SW--Passion for Performance
> Jochen Bern, Systemingenieur --- LINworks GmbH 
> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
> PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
> Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
> Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
> ___
> 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] NTP not syncing to configured servers

[Chandra Kanth]

Hi Graves, Yu,

First of all thanks for response. Let me clarify, this is private lab
setup, no public ntp servers.
The idea is to setup private ntp subnet, where the time on servers such as
.198 and .204 should be propagated to other clients.

Think as .198 and .204 as private ntp servers which is configured as lower
stratum server. (i.e. /etc/ntp.conf contains stratum 5). So these servers
does not get a reference clock from any other lower stratum i.e. stratum 4.
It simply provides system time from its own local clock.

The client here which .196 is running at higher stratum i.e. 10.

So I'm was hoping the client (.196) should sync to any one of the server
since at least their stratum is lower.

I hope the question is clear.

Regards
Chandrakanth


On Wed, May 13, 2015 at 7:42 PM, Dallas Graves  wrote:

> To expound upon Yu’s comment.  If you don’t have access to the firewall, a
> good check would be to conduct a test against each of your targeted NTP
> servers with the “ntpdate -d” command, which is the debug switch and will
> let you know if you can or cannot reach the intended systems.
>
> -Dallas
>
>
> > On May 13, 2015, at 8:54 AM, Wang, Yu  wrote:
> >
> > Do your ntp servers have public IP addresses configured or do you do NAT
> for the two ntp servers? 10.126.142.198 and 10.126.142.204 are private
> addresses and won't be routed over the Internet.
> > The second place to check is firewall. Make sure it opens to upd/123
> between your ntp servers and outside ntp servers.
> >
> > Yu
> > Core Networking, FSU
> >
> >
> > -Original Message-
> > From: questions [mailto:questions-bounces+ywang10=fsu@lists.ntp.org]
> On Behalf Of Chandrakanth K
> > Sent: Wednesday, May 13, 2015 7:52 AM
> > To: questions@lists.ntp.org
> > Subject: [ntp:questions] NTP not syncing to configured servers
> >
> > Hi,
> >
> > I am seeing ntp not syncing to external configured servers. We tried
> both 4.2.4 and 4.2.6 versions.
> > The following is the configuration,
> >
> > We use two servers 10.126.142.198 and 10.126.142.204 in our Lab.
> > They are statically configured as running @ stratum level 5 and
> providing the clock from its own local clock.
> >
> > Even though the servers does not have a valid reference time and
> provides time from its own clock, according to me still we need to be able
> to sync to it since it is running at better stratum.
> > Please clarify.
> >
> > Logs:
> > -
> >
> > bash-4.2$ ntpq -np -c assoc
> > remote   refid  st t when poll reach   delay   offset
> jitter
> >
> ==
> > *127.127.1.0 .LOCL.  10 l   19   64  3770.0000.000
>  0.001
> > 10.126.142.198  LOCAL(0) 6 u7   16  3770.172
> 859.844   0.501
> > 10.126.142.204  LOCAL(0) 6 u   15   16  3770.227
> 1057.22   0.240
> >
> > ind assID status  conf reach auth condition  last_event cnt
> ===
> >  1 26554  9614   yes   yes  none  sys.peer   reachable  1
> >  2 26555  9014   yes   yes  nonereject   reachable  1
> >  3 26556  9014   yes   yes  nonereject   reachable  1
> >
> > Logs: 10.126.142.198
> > ---
> > bash-4.2$ ntpq -np -c assoc
> > remote   refid  st t when poll reach   delay   offset
> jitter
> >
> ==
> > *127.127.1.0 .LOCL.   5 l   10   64  3770.0000.000
>  0.000
> >
> > ind assid status  conf reach auth condition  last_event cnt
> ===
> >  1 48508  965a   yes   yes  none  sys.peersys_peer  5
> >
> >
> > Logs: 10.126.142.204
> > ---
> >
> > bash-4.2$ ntpq -np -c assoc
> > remote   refid  st t when poll reach   delay   offset
> jitter
> >
> ==
> > *127.127.1.0 .LOCL.   5 l   13   64  3770.0000.000
>  0.000
> >
> > ind assid status  conf reach auth condition  last_event cnt
> ===
> >  1 32737  963a   yes   yes  none  sys.peersys_peer  3
> >
> >
> > Regards
> > Chandrakanth
> > ___
> > 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
>
> ___
> 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] NTP not syncing to configured servers

[Dallas Graves]

Looks like both of the remote servers are beyond the recoverable step counter, 
you’ll need to stop ntpd, then do an ntpdate -b $target_IP  to recover them, 
then restart the ntpd service.

-Dallas


> On May 13, 2015, at 3:00 PM, Jochen Bern  wrote:
> 
> On 05/13/2015 01:52 PM, Chandrakanth K wrote:
>> bash-4.2$ ntpq -np -c assoc
>> remote   refid  st t when poll reach   delay   offset  jitter
>> 
>> *127.127.1.0 .LOCL.  10 l   19   64  3770.0000.000   
>> 0.001
>> 10.126.142.198  LOCAL(0) 6 u7   16  3770.172  859.844   0.501
>> 10.126.142.204  LOCAL(0) 6 u   15   16  3770.227  1057.22   0.240
> 
> ntpd has connected to both remote servers and retrieved data from them,
> so it's not an outright packet block on some firewall. Instead ...
> 
>> ind assID status  conf reach auth condition  last_event cnt
>> =
>>  1 26554  9614   yes   yes  none  sys.peer   reachable  1
>>  2 26555  9014   yes   yes  nonereject   reachable  1
>>  3 26556  9014   yes   yes  nonereject   reachable  1
> 
> ... it saw fit to label them as "reject"ed.
> 
> I'ld guess that the two servers having an offset of ~0.2 s with respect
> to each other plays a role in that, and the client having another ~0.9 s
> offset from their average might be an obstacle until you restart the
> client ntpd, too.
> 
> Regards,
>   J. Bern
> -- 
> *NEU* - NEC IT-Infrastruktur-Produkte im :
> Server--Storage--Virtualisierung--Management SW--Passion for Performance
> Jochen Bern, Systemingenieur --- LINworks GmbH 
> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
> PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
> Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
> Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
> ___
> 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] NTP not syncing to configured servers

[Jochen Bern]

On 05/13/2015 01:52 PM, Chandrakanth K wrote:
> bash-4.2$ ntpq -np -c assoc
>  remote   refid  st t when poll reach   delay   offset  jitter
> 
> *127.127.1.0 .LOCL.  10 l   19   64  3770.0000.000   0.001
>  10.126.142.198  LOCAL(0) 6 u7   16  3770.172  859.844   0.501
>  10.126.142.204  LOCAL(0) 6 u   15   16  3770.227  1057.22   0.240

ntpd has connected to both remote servers and retrieved data from them,
so it's not an outright packet block on some firewall. Instead ...

> ind assID status  conf reach auth condition  last_event cnt
> =
>   1 26554  9614   yes   yes  none  sys.peer   reachable  1
>   2 26555  9014   yes   yes  nonereject   reachable  1
>   3 26556  9014   yes   yes  nonereject   reachable  1

... it saw fit to label them as "reject"ed.

I'ld guess that the two servers having an offset of ~0.2 s with respect
to each other plays a role in that, and the client having another ~0.9 s
offset from their average might be an obstacle until you restart the
client ntpd, too.

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP not syncing to configured servers

[Dallas Graves]

Can you clarify if you’re setting “stratum 5” on your target servers, or your 
local “fudge” server?  

As far as I know, remote NTP servers should not require stratum option.  I only 
use this option on my local time source, and by that I mean issuing a rather 
high value as to ensure that it’s selected last.  One thing you may want to try 
is using iburst option which instructs NTP to issue 8 request packets if the 
first is not received, this often helps with network-related issues (which you 
may or may not be experiencing).

If this is not helpful, perhaps you could sanitize your config and share it 
with the mailing list so we can better help you?

Thanks,
-Dallas


> On May 13, 2015, at 11:08 AM, Chandra Kanth  wrote:
> 
> OK. Lets rule out its ACL/firewall issue. I have been able to use ntpdate -d 
> command. I used it several times on this setup.
> 
> Next, do you think arbitrary setting of stratum to low value such as 5 is 
> problem?
> FYI, these servers are high end routers, so that's why we set its stratum to 
> 5.
> 
> On what basis we should set stratum value? What is the appropriate value? 
> How do we determine what should be the stratum?
> 
> Regards
> Chandrakanth
> 
> On Wed, May 13, 2015 at 9:33 PM, Dallas Graves  > wrote:
> Your question is quite clear.  As I stated, you want to ensure that you can, 
> in fact, access the targeted NTP servers via the debug switch in the ntpdate 
> command.  If you’ve confirmed that access is not blocked by firewall and/or 
> ACL, then you’ll want to make sure you set the stratum correctly in the 
> ntp.conf configuration, ensuring that your fudge or (local time source) is 
> set at a higher stratum such as 10.
> 
> Hope this helps.
> 
> -Dallas
> 
> 
> 
>> On May 13, 2015, at 10:58 AM, Chandra Kanth > > wrote:
>> 
>> Hi Graves, Yu,
>> 
>> First of all thanks for response. Let me clarify, this is private lab setup, 
>> no public ntp servers.
>> The idea is to setup private ntp subnet, where the time on servers such as 
>> .198 and .204 should be propagated to other clients.
>> 
>> Think as .198 and .204 as private ntp servers which is configured as lower 
>> stratum server. (i.e. /etc/ntp.conf contains stratum 5). So these servers 
>> does not get a reference clock from any other lower stratum i.e. stratum 4. 
>> It simply provides system time from its own local clock.
>> 
>> The client here which .196 is running at higher stratum i.e. 10.
>> 
>> So I'm was hoping the client (.196) should sync to any one of the server 
>> since at least their stratum is lower.
>> 
>> I hope the question is clear.
>> 
>> Regards
>> Chandrakanth
>> 
>> 
>> On Wed, May 13, 2015 at 7:42 PM, Dallas Graves > > wrote:
>> To expound upon Yu’s comment.  If you don’t have access to the firewall, a 
>> good check would be to conduct a test against each of your targeted NTP 
>> servers with the “ntpdate -d” command, which is the debug switch and will 
>> let you know if you can or cannot reach the intended systems.
>> 
>> -Dallas
>> 
>> 
>> > On May 13, 2015, at 8:54 AM, Wang, Yu > > > wrote:
>> >
>> > Do your ntp servers have public IP addresses configured or do you do NAT 
>> > for the two ntp servers? 10.126.142.198 and 10.126.142.204 are private 
>> > addresses and won't be routed over the Internet.
>> > The second place to check is firewall. Make sure it opens to upd/123 
>> > between your ntp servers and outside ntp servers.
>> >
>> > Yu
>> > Core Networking, FSU
>> >
>> >
>> > -Original Message-
>> > From: questions [mailto:questions-bounces+ywang10 
>> > =fsu@lists.ntp.org 
>> > ] On Behalf Of Chandrakanth K
>> > Sent: Wednesday, May 13, 2015 7:52 AM
>> > To: questions@lists.ntp.org 
>> > Subject: [ntp:questions] NTP not syncing to configured servers
>> >
>> > Hi,
>> >
>> > I am seeing ntp not syncing to external configured servers. We tried both 
>> > 4.2.4 and 4.2.6 versions.
>> > The following is the configuration,
>> >
>> > We use two servers 10.126.142.198 and 10.126.142.204 in our Lab.
>> > They are statically configured as running @ stratum level 5 and providing 
>> > the clock from its own local clock.
>> >
>> > Even though the servers does not have a valid reference time and provides 
>> > time from its own clock, according to me still we need to be able to sync 
>> > to it since it is running at better stratum.
>> > Please clarify.
>> >
>> > Logs:
>> > -
>> >
>> > bash-4.2$ ntpq -np -c assoc
>> > remote   refid  st t when poll reach   delay   offset  
>> > jitter
>> > ==
>> > *127.127.1.0 .LOCL.  10 l   19   64  3770.0000.000   
>> > 0.001
>> > 10.126.142.198  LOCAL(0) 6 u7   16  3770.172  859.84

Re: [ntp:questions] NTP not syncing to configured servers

[Dallas Graves]

Your question is quite clear.  As I stated, you want to ensure that you can, in 
fact, access the targeted NTP servers via the debug switch in the ntpdate 
command.  If you’ve confirmed that access is not blocked by firewall and/or 
ACL, then you’ll want to make sure you set the stratum correctly in the 
ntp.conf configuration, ensuring that your fudge or (local time source) is set 
at a higher stratum such as 10.

Hope this helps.

-Dallas



> On May 13, 2015, at 10:58 AM, Chandra Kanth  wrote:
> 
> Hi Graves, Yu,
> 
> First of all thanks for response. Let me clarify, this is private lab setup, 
> no public ntp servers.
> The idea is to setup private ntp subnet, where the time on servers such as 
> .198 and .204 should be propagated to other clients.
> 
> Think as .198 and .204 as private ntp servers which is configured as lower 
> stratum server. (i.e. /etc/ntp.conf contains stratum 5). So these servers 
> does not get a reference clock from any other lower stratum i.e. stratum 4. 
> It simply provides system time from its own local clock.
> 
> The client here which .196 is running at higher stratum i.e. 10.
> 
> So I'm was hoping the client (.196) should sync to any one of the server 
> since at least their stratum is lower.
> 
> I hope the question is clear.
> 
> Regards
> Chandrakanth
> 
> 
> On Wed, May 13, 2015 at 7:42 PM, Dallas Graves  > wrote:
> To expound upon Yu’s comment.  If you don’t have access to the firewall, a 
> good check would be to conduct a test against each of your targeted NTP 
> servers with the “ntpdate -d” command, which is the debug switch and will let 
> you know if you can or cannot reach the intended systems.
> 
> -Dallas
> 
> 
> > On May 13, 2015, at 8:54 AM, Wang, Yu  > > wrote:
> >
> > Do your ntp servers have public IP addresses configured or do you do NAT 
> > for the two ntp servers? 10.126.142.198 and 10.126.142.204 are private 
> > addresses and won't be routed over the Internet.
> > The second place to check is firewall. Make sure it opens to upd/123 
> > between your ntp servers and outside ntp servers.
> >
> > Yu
> > Core Networking, FSU
> >
> >
> > -Original Message-
> > From: questions [mailto:questions-bounces+ywang10 
> > =fsu@lists.ntp.org 
> > ] On Behalf Of Chandrakanth K
> > Sent: Wednesday, May 13, 2015 7:52 AM
> > To: questions@lists.ntp.org 
> > Subject: [ntp:questions] NTP not syncing to configured servers
> >
> > Hi,
> >
> > I am seeing ntp not syncing to external configured servers. We tried both 
> > 4.2.4 and 4.2.6 versions.
> > The following is the configuration,
> >
> > We use two servers 10.126.142.198 and 10.126.142.204 in our Lab.
> > They are statically configured as running @ stratum level 5 and providing 
> > the clock from its own local clock.
> >
> > Even though the servers does not have a valid reference time and provides 
> > time from its own clock, according to me still we need to be able to sync 
> > to it since it is running at better stratum.
> > Please clarify.
> >
> > Logs:
> > -
> >
> > bash-4.2$ ntpq -np -c assoc
> > remote   refid  st t when poll reach   delay   offset  
> > jitter
> > ==
> > *127.127.1.0 .LOCL.  10 l   19   64  3770.0000.000   
> > 0.001
> > 10.126.142.198  LOCAL(0) 6 u7   16  3770.172  859.844   
> > 0.501
> > 10.126.142.204  LOCAL(0) 6 u   15   16  3770.227  1057.22   
> > 0.240
> >
> > ind assID status  conf reach auth condition  last_event cnt 
> > ===
> >  1 26554  9614   yes   yes  none  sys.peer   reachable  1
> >  2 26555  9014   yes   yes  nonereject   reachable  1
> >  3 26556  9014   yes   yes  nonereject   reachable  1
> >
> > Logs: 10.126.142.198
> > ---
> > bash-4.2$ ntpq -np -c assoc
> > remote   refid  st t when poll reach   delay   offset  
> > jitter
> > ==
> > *127.127.1.0 .LOCL.   5 l   10   64  3770.0000.000   
> > 0.000
> >
> > ind assid status  conf reach auth condition  last_event cnt 
> > ===
> >  1 48508  965a   yes   yes  none  sys.peersys_peer  5
> >
> >
> > Logs: 10.126.142.204
> > ---
> >
> > bash-4.2$ ntpq -np -c assoc
> > remote   refid  st t when poll reach   delay   offset  
> > jitter
> > ==
> > *127.127.1.0 .LOCL.   5 l   13   64  3770.0000.000   
> > 0.000
> >
> > ind assid status  conf reach auth condition  last_event cnt 
> > ===

Re: [ntp:questions] NTP not syncing to configured servers

[Dallas Graves]

To expound upon Yu’s comment.  If you don’t have access to the firewall, a good 
check would be to conduct a test against each of your targeted NTP servers with 
the “ntpdate -d” command, which is the debug switch and will let you know if 
you can or cannot reach the intended systems.

-Dallas


> On May 13, 2015, at 8:54 AM, Wang, Yu  wrote:
> 
> Do your ntp servers have public IP addresses configured or do you do NAT for 
> the two ntp servers? 10.126.142.198 and 10.126.142.204 are private addresses 
> and won't be routed over the Internet. 
> The second place to check is firewall. Make sure it opens to upd/123 between 
> your ntp servers and outside ntp servers.
> 
> Yu
> Core Networking, FSU
> 
> 
> -Original Message-
> From: questions [mailto:questions-bounces+ywang10=fsu@lists.ntp.org] On 
> Behalf Of Chandrakanth K
> Sent: Wednesday, May 13, 2015 7:52 AM
> To: questions@lists.ntp.org
> Subject: [ntp:questions] NTP not syncing to configured servers
> 
> Hi,
> 
> I am seeing ntp not syncing to external configured servers. We tried both 
> 4.2.4 and 4.2.6 versions.
> The following is the configuration,
> 
> We use two servers 10.126.142.198 and 10.126.142.204 in our Lab.
> They are statically configured as running @ stratum level 5 and providing the 
> clock from its own local clock.
> 
> Even though the servers does not have a valid reference time and provides 
> time from its own clock, according to me still we need to be able to sync to 
> it since it is running at better stratum.
> Please clarify.
> 
> Logs:
> -
> 
> bash-4.2$ ntpq -np -c assoc
> remote   refid  st t when poll reach   delay   offset  jitter
> ==
> *127.127.1.0 .LOCL.  10 l   19   64  3770.0000.000   0.001
> 10.126.142.198  LOCAL(0) 6 u7   16  3770.172  859.844   
> 0.501
> 10.126.142.204  LOCAL(0) 6 u   15   16  3770.227  1057.22   
> 0.240
> 
> ind assID status  conf reach auth condition  last_event cnt 
> ===
>  1 26554  9614   yes   yes  none  sys.peer   reachable  1
>  2 26555  9014   yes   yes  nonereject   reachable  1
>  3 26556  9014   yes   yes  nonereject   reachable  1
> 
> Logs: 10.126.142.198
> ---
> bash-4.2$ ntpq -np -c assoc
> remote   refid  st t when poll reach   delay   offset  jitter
> ==
> *127.127.1.0 .LOCL.   5 l   10   64  3770.0000.000   0.000
> 
> ind assid status  conf reach auth condition  last_event cnt 
> ===
>  1 48508  965a   yes   yes  none  sys.peersys_peer  5
> 
> 
> Logs: 10.126.142.204
> ---
> 
> bash-4.2$ ntpq -np -c assoc
> remote   refid  st t when poll reach   delay   offset  jitter
> ==
> *127.127.1.0 .LOCL.   5 l   13   64  3770.0000.000   0.000
> 
> ind assid status  conf reach auth condition  last_event cnt 
> ===
>  1 32737  963a   yes   yes  none  sys.peersys_peer  3
> 
> 
> Regards
> Chandrakanth
> ___
> 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

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

Re: [ntp:questions] NTP not syncing to configured servers

[Wang, Yu]

Do your ntp servers have public IP addresses configured or do you do NAT for 
the two ntp servers? 10.126.142.198 and 10.126.142.204 are private addresses 
and won't be routed over the Internet. 
The second place to check is firewall. Make sure it opens to upd/123 between 
your ntp servers and outside ntp servers.

Yu
Core Networking, FSU


-Original Message-
From: questions [mailto:questions-bounces+ywang10=fsu@lists.ntp.org] On 
Behalf Of Chandrakanth K
Sent: Wednesday, May 13, 2015 7:52 AM
To: questions@lists.ntp.org
Subject: [ntp:questions] NTP not syncing to configured servers

Hi,

I am seeing ntp not syncing to external configured servers. We tried both 4.2.4 
and 4.2.6 versions.
The following is the configuration,

We use two servers 10.126.142.198 and 10.126.142.204 in our Lab.
They are statically configured as running @ stratum level 5 and providing the 
clock from its own local clock.

Even though the servers does not have a valid reference time and provides time 
from its own clock, according to me still we need to be able to sync to it 
since it is running at better stratum.
Please clarify.

Logs:
-

bash-4.2$ ntpq -np -c assoc
 remote   refid  st t when poll reach   delay   offset  jitter
==
*127.127.1.0 .LOCL.  10 l   19   64  3770.0000.000   0.001
 10.126.142.198  LOCAL(0) 6 u7   16  3770.172  859.844   
0.501
 10.126.142.204  LOCAL(0) 6 u   15   16  3770.227  1057.22   
0.240

ind assID status  conf reach auth condition  last_event cnt 
===
  1 26554  9614   yes   yes  none  sys.peer   reachable  1
  2 26555  9014   yes   yes  nonereject   reachable  1
  3 26556  9014   yes   yes  nonereject   reachable  1

Logs: 10.126.142.198
---
bash-4.2$ ntpq -np -c assoc
 remote   refid  st t when poll reach   delay   offset  jitter
==
*127.127.1.0 .LOCL.   5 l   10   64  3770.0000.000   0.000

ind assid status  conf reach auth condition  last_event cnt 
===
  1 48508  965a   yes   yes  none  sys.peersys_peer  5


Logs: 10.126.142.204
---

bash-4.2$ ntpq -np -c assoc
 remote   refid  st t when poll reach   delay   offset  jitter
==
*127.127.1.0 .LOCL.   5 l   13   64  3770.0000.000   0.000

ind assid status  conf reach auth condition  last_event cnt 
===
  1 32737  963a   yes   yes  none  sys.peersys_peer  3


Regards
Chandrakanth
___
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] NTP not syncing

[unruh]

On 2013-12-13, Richard B. Gilbert  wrote:
> On 12/7/2013 7:35 PM, Magnus Danielson wrote:
>> On 12/07/2013 11:39 PM, Harlan Stenn wrote:
>>> Magnus Danielson writes:
 The drift-file-accelerated lock-in isn't robust. Current behavior of
 response isn't very useful for most people experiencing it.
>>> I'm not sure I'd agree with the word "most".  It's certainly worked very
>>> well on hundreds of machines where I've run it, and the feedback I've
>>> had from people when I've told them about iburst and drift files has
>>> been positive except when they've had Linux kernels that calculate a
>>> different clock frequency on a reboot.
>> Experiencing the problem that is. When it works, it's a lovely tool.
>> Sorry if the wording was unclear in that aspect.
>>> There are at least 2 other issues here.
>>>
>>> One goes to "robust", and yes, we can do better with that.  It's not yet
>>> clear to me that in the wider perspective this effort will be worthwhile.
>> Well, you can either choose a rather simple back-out method or if you
>> think it is worthwhile a more elaborate method. Getting cyclic re-set of
>> time is a little to coarse a method. I think it is better to back-out
>> and one way or another recover phase and frequency.
>>> The other goes to the amount of time it takes to adequately determine
>>> the offset and drift.
>>>
>>> With a good driftfile and iburst, ntpd will sync to a handful of PPM in
>>> about 11 seconds' time.
>>>
>>> We've been working on a project to produce sufficiently accurate offset
>>> and drift measurements at startup time, and the main problem here is
>>> that it can take minutes to figure this out well, and there is a
>>> significant need to get the time in the right ballpark at startup in
>>> less than a minute.  These goals are mutually incompatible.  The intent
>>> is to find a way to "get there" as well as possible, as quickly as
>>> possible.
>> Getting the time in the right ball-park is by itself not all that hard.
>> However, frequency takes time to learn and getting phase errors down
>> quickly becomes an issue. NTP has as far as I have seen reduced loop
>> bandwidth and at the same time reduced the capture range, and whenever
>> you reduce the capture range you need to have heuristics to make sure
>> you back-out if things get upset. Recovery of old state is good, but one
>> needs to make sure that you don't loose that robustness.
>>
>> As for method of locking in quickly, that can be debated on in length.
>>
>> Cheers,
>> Magnus
>>
>
> It has been debated!  It will probably be debated for the next thirty
> or forty years.  There is something about the topic that seems to
> to encourage debate! ;-)

Not really. It has been pointed out that it is a problem for ntpd. And
Mills has stated that it is an uninteresting problem. That is not a
debate. It is one of the weaknesses of ntpd as used by many people. It
is not a particularly interesting weakness, I agree, if ntpd is run for
many months or years at a time. It is interesting if it is run only for
hours at a time however.  There has been a concession in that if there
is no drift file, ntpd now has software to try to make it get a
reasonable estimate of that drift quickly instead of waiting for the
feedback loop to converge from 0  to a reasonable estimate. ntpd,  however, 
still has
nothing to actually check on the drift file to make sure it is sane. 

ntpd could run the same startup code that it does if there is no drift
file, and, after it gets its initial estimate, it compares the result to
the drift file rate. If it is close, use the drift file. If it  is not
close ( eg >3PPM say or whatever the estimate on the error in the rapid
initial determination is) then use the estimate instead. The code is all
there. It is just the glue that is needed. 
(This is independent of the question as to whether or not the simple
feedback circuit of ntpd is the best way of conditioning the local
clock, which has to do with how fast ntpd responds to changes in the
local clock rate caused by temperature variations for example.)

 


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

Re: [ntp:questions] NTP not syncing

[Richard B. Gilbert]

On 12/7/2013 7:35 PM, Magnus Danielson wrote:

On 12/07/2013 11:39 PM, Harlan Stenn wrote:

Magnus Danielson writes:

The drift-file-accelerated lock-in isn't robust. Current behavior of
response isn't very useful for most people experiencing it.

I'm not sure I'd agree with the word "most".  It's certainly worked very
well on hundreds of machines where I've run it, and the feedback I've
had from people when I've told them about iburst and drift files has
been positive except when they've had Linux kernels that calculate a
different clock frequency on a reboot.

Experiencing the problem that is. When it works, it's a lovely tool.
Sorry if the wording was unclear in that aspect.

There are at least 2 other issues here.

One goes to "robust", and yes, we can do better with that.  It's not yet
clear to me that in the wider perspective this effort will be worthwhile.

Well, you can either choose a rather simple back-out method or if you
think it is worthwhile a more elaborate method. Getting cyclic re-set of
time is a little to coarse a method. I think it is better to back-out
and one way or another recover phase and frequency.

The other goes to the amount of time it takes to adequately determine
the offset and drift.

With a good driftfile and iburst, ntpd will sync to a handful of PPM in
about 11 seconds' time.

We've been working on a project to produce sufficiently accurate offset
and drift measurements at startup time, and the main problem here is
that it can take minutes to figure this out well, and there is a
significant need to get the time in the right ballpark at startup in
less than a minute.  These goals are mutually incompatible.  The intent
is to find a way to "get there" as well as possible, as quickly as
possible.

Getting the time in the right ball-park is by itself not all that hard.
However, frequency takes time to learn and getting phase errors down
quickly becomes an issue. NTP has as far as I have seen reduced loop
bandwidth and at the same time reduced the capture range, and whenever
you reduce the capture range you need to have heuristics to make sure
you back-out if things get upset. Recovery of old state is good, but one
needs to make sure that you don't loose that robustness.

As for method of locking in quickly, that can be debated on in length.

Cheers,
Magnus



It has been debated!  It will probably be debated for the next thirty
or forty years.  There is something about the topic that seems to
to encourage debate! ;-)

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

Re: [ntp:questions] NTP not syncing

[David Taylor]

On 08/12/2013 10:30, Brian Inglis wrote:
[]

Also why I would like to see the Windows ntpd support pinning, tsc/pcc use,
and other tweaks, independent of each other and the interpolation option.
That option currently has to be enabled to use those tweaks, but appears
in my tests to degrade results  compared to my current setup.


Some of these options depend on which version of Windows you are using - 
XP Vista/7, and 8/8.1 all differ in their capabilities and therefore in 
NTP's behaviour.  Sometimes, NTP gets the wrong guess at what options to 
use, and sometimes other programs appear to interact with the OS making 
NTP's start-up decision inappropriate.  But NTP 4.2.7 is now much better 
than earlier versions of NTP on Windows ever were.


Unfortunately, now I have a local stratum-1 server (low-cost), I do very 
little requiring Internet-only sync, except when I have my phone or 
tablet away from home when I can do little NTP-wise.  (iOS allows no 
access, Android requires rooting, which I haven't done).  Occasionally I 
have my Windows-7 netbook away from home, and the accuracy of NTP is 
that usage is more than adequate (assuming the hotel or ship allows NTP 
packets through, that is!).

--
Cheers,
David
Web: http://www.satsignal.eu

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

Re: [ntp:questions] NTP not syncing

[Brian Inglis]

On 2013-12-06 11:05, unruh wrote:

On 2013-12-06, Brian Inglis  wrote:

It would be better if ntpd used the drift file frequency for the first
two hours, instead of 15 minutes, before coming up with its (currently
wild assed) guesstimate, and then spending 4 hours getting back to the
drift frequency.


I do not think you understand. ntpd has a drift value-- a rate at which
it corrects the system clock (on linux this is using the adjtimex call).
If it find an offset, it changes that drift to eliminate that offset. If
one has a system where the drift file is off, but the offset is OK, then
ntp will take a while to even notice that the offset is increasing (part
of that wait is the poll interval, part is the clock filter which throws
out 80% of the poll results, and part of it is that the wrong drift will
not show up in the offset for a while.) Once it notices there is an
offset, it will alter the drift a little bit to try to eliminate that
offset. For the first while that offset will be small, and the drift
adjustment will be small. The offset continues to grow, and ntp makes
the drift correction larger and larger, but the offset continues to be
large. The drift finally badly overshoots and now the offset starts to
get smaller, but the drift keeps being increased because the offset is
still large. That drives the clock offsets finally off in the opposite
direction.
It is this behaviour, that it only looks at the current offset to adjust
the drift that is the problem. With even a little bit of history, it is
obvious that the drift rate is way off. But ntpd does not keep any
history. This is one of the reasons why chrony performs so much better
than ntpd does. It does keep a history (it does a linear regression on
the past 3-64 offsets to determine the current offset and drift) and
uses it. The number of history points kept is varied depending on how
well the linear model (offset plus drift) fits the data.
There are other differences as well.

ntpd works fine in keeping the time in a situation where there is only
noise-- variable network time delays, gaussian random white noise
affecting the local clock frequency or clock reading, etc. But for large
errors (bad drift file, sudden temperature change, ...) ntpd does poorly
in the sense that it takes a long time to notice and fix.  Since one of
the key sources of noise in a computer is temperature variations, this
means that in normal use ntpd does significantly worse than chrony in
keeping the offsets small (the offsets are at least a factor of 2 and I
have heard reports of a factor of 20 higher standard deviation in ntpd
than in chrony). I do not have good figures on how its drift rate
fluctuations compare to those of ntpd-- but probably worse.



This is on Windows 7, current stable ntpd, NMEA user mode pps ref clock
(serialpps does not work with a 64 bit PCIe serial port driver stack).

I try to avoid any issues by copying the drift file daily, if it is
within limits, and copying back before startup, if it outside limits,
to reduce issues with wild ntpd drift estimates.

Could whatever was patched in Linux be required in the Windows port?


What was patched in Linux was the kernel by the kernel developers. Ie
way outside ntpd's pervue, and impossible on Windows.


AFAICT the Windows port does what the Linux kernel and adjtimex do, by
disabling the default system time adjustment, and estimating the frequency
to correct the phase offset, within the system adjustment limits.

But the drift estimate takes 15 minutes, not 11 seconds, and then is off
by many PPM, takes 2 hours to get within 1 PPM, and another 2 hours to start
oscillating around the true system drift value.

I have seen no sign of drifts diverging, it is slowly and consistently
driven towards the true hardware rate, by the ref clock.

On my system, ignoring hours after NTP restart, drift < 1ppm, drift range
< .04ppm, wander range < .0003ppm, phase offset range < 10us, mean < .25us.
TSCs are constant/invariant, synced, and all run at the 2.6GHz CPU clock,
with skews < 3us after 3 weeks uptime, so within read error timing.
NTPD runs on the last CPU at Realtime priority, so is unlikely to be
affected by system use.
I am now seeing obvious heating system artifacts, especially when the
temperature plunged to the coldest on earth the other day.

So I take notice when offset or drift are above those expected ranges!

Also why I would like to see the Windows ntpd support pinning, tsc/pcc use,
and other tweaks, independent of each other and the interpolation option.
That option currently has to be enabled to use those tweaks, but appears
in my tests to degrade results  compared to my current setup.

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-08, Harlan Stenn  wrote:
> unruh writes:
>> On 2013-12-07, Harlan Stenn  wrote:
>> > unruh writes:
>> >> As I said, get chrony if you want much faster convergence, if you want
>> >> better control of the time offset from UTC, and if yourun Linux or
>> >> BSD.
>> >
>> > And this begs the question of "faster convergence towards *what*?"
>> 
>> UTC :-)
>
> At least you added the smiley.
>
>> > NTP looks a a number of time sources, finds a majority clique that
>> > exhibit "good" (consistent with respect to each other, as observed by
>> > the local system) behavior, and steers the clock towards that time.
>> 
>> So does chrony, except that it takes one of those (the one with the
>> smallest spread I believe) as the representative.
>
> And this is the crux of the difference in approach, as it "shifts faith"
> from the current machine to the machine being followed.
>
> Sometimes this will be right and sometimes it will be wrong.

ntp shifts faith to the machines being followed. Just as ntpd chrony
also looks at as many servers as you have configured, and tries to
figure out the best range just as ntpd does. Because chrony keeps
information about the past, it can for example decide which of the
servers has the smallest standard deviation lying within the group of
good servers. 

>
>> > As I understand it, chrony steers the local clock towards the master
>> > time source it is following.
>> 
>> And it figures out which source it is following by looking at all of
>> the sources it is following.
>
> Is there something other than the code where I can learn more about
> this?

Not as far as I know. And it has been a while since I have looked at the
code, so my understanding might be problematic. 


>
>> > Assuming this is all true (or true enough), there are times and
>> > situations where one of these approaches is better than the other, and
>> > other times and situations where the converse is true.
>> 
>> Yes, but tests that both I and Lichvar have run show that chrony follows
>> to much higher accuracy than does ntpd.
>
> And again, it is not clear that chrony is following the better source of
> time.

Well, in my tests I had a gps pps source locally which did not feed into
chrony, but was used only to look at the time offset of the system. Mind
you I used only one server, another PPS server running at that time
ntpd. Thus both systems were withing microseconds of UTC (as given by
the PPS) and the noise was thus all network noise. 


>
> This is a topic that needs serious "instrumenting".

Agreed. 

>
> H

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

Re: [ntp:questions] NTP not syncing

[Harlan Stenn]

unruh writes:
> On 2013-12-07, Harlan Stenn  wrote:
> > unruh writes:
> >> As I said, get chrony if you want much faster convergence, if you want
> >> better control of the time offset from UTC, and if yourun Linux or
> >> BSD.
> >
> > And this begs the question of "faster convergence towards *what*?"
> 
> UTC :-)

At least you added the smiley.

> > NTP looks a a number of time sources, finds a majority clique that
> > exhibit "good" (consistent with respect to each other, as observed by
> > the local system) behavior, and steers the clock towards that time.
> 
> So does chrony, except that it takes one of those (the one with the
> smallest spread I believe) as the representative.

And this is the crux of the difference in approach, as it "shifts faith"
from the current machine to the machine being followed.

Sometimes this will be right and sometimes it will be wrong.

> > As I understand it, chrony steers the local clock towards the master
> > time source it is following.
> 
> And it figures out which source it is following by looking at all of
> the sources it is following.

Is there something other than the code where I can learn more about
this?

> > Assuming this is all true (or true enough), there are times and
> > situations where one of these approaches is better than the other, and
> > other times and situations where the converse is true.
> 
> Yes, but tests that both I and Lichvar have run show that chrony follows
> to much higher accuracy than does ntpd.

And again, it is not clear that chrony is following the better source of
time.

This is a topic that needs serious "instrumenting".

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

Re: [ntp:questions] NTP not syncing

[Magnus Danielson]

On 12/07/2013 11:39 PM, Harlan Stenn wrote:
> Magnus Danielson writes:
>> The drift-file-accelerated lock-in isn't robust. Current behavior of
>> response isn't very useful for most people experiencing it.
> I'm not sure I'd agree with the word "most".  It's certainly worked very
> well on hundreds of machines where I've run it, and the feedback I've
> had from people when I've told them about iburst and drift files has
> been positive except when they've had Linux kernels that calculate a
> different clock frequency on a reboot.
Experiencing the problem that is. When it works, it's a lovely tool.
Sorry if the wording was unclear in that aspect.
> There are at least 2 other issues here.
>
> One goes to "robust", and yes, we can do better with that.  It's not yet
> clear to me that in the wider perspective this effort will be worthwhile.
Well, you can either choose a rather simple back-out method or if you
think it is worthwhile a more elaborate method. Getting cyclic re-set of
time is a little to coarse a method. I think it is better to back-out
and one way or another recover phase and frequency.
> The other goes to the amount of time it takes to adequately determine
> the offset and drift.
>
> With a good driftfile and iburst, ntpd will sync to a handful of PPM in
> about 11 seconds' time.
>
> We've been working on a project to produce sufficiently accurate offset
> and drift measurements at startup time, and the main problem here is
> that it can take minutes to figure this out well, and there is a
> significant need to get the time in the right ballpark at startup in
> less than a minute.  These goals are mutually incompatible.  The intent
> is to find a way to "get there" as well as possible, as quickly as
> possible.
Getting the time in the right ball-park is by itself not all that hard.
However, frequency takes time to learn and getting phase errors down
quickly becomes an issue. NTP has as far as I have seen reduced loop
bandwidth and at the same time reduced the capture range, and whenever
you reduce the capture range you need to have heuristics to make sure
you back-out if things get upset. Recovery of old state is good, but one
needs to make sure that you don't loose that robustness.

As for method of locking in quickly, that can be debated on in length.

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-07, Harlan Stenn  wrote:
> unruh writes:
>> As I said, get chrony if you want much faster convergence, if you want
>> better control of the time offset from UTC, and if yourun Linux or
>> BSD.
>
> And this begs the question of "faster convergence towards *what*?"

UTC :-)

>
> NTP looks a a number of time sources, finds a majority clique that
> exhibit "good" (consistent with respect to each other, as observed by
> the local system) behavior, and steers the clock towards that time.

So does chrony, except that it takes one of those (the one with the
smallest spread I believe) as the representative.
>
> As I understand it, chrony steers the local clock towards the master
> time source it is following.
And it figures out which source it is following by looking at all of the
sources it is following.

>
> Assuming this is all true (or true enough), there are times and
> situations where one of these approaches is better than the other, and
> other times and situations where the converse is true.

Yes, but tests that both I and Lichvar have run show that chrony follows
to much higher accuracy than does ntpd.
>
> H

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

Re: [ntp:questions] NTP not syncing

[Harlan Stenn]

unruh writes:
> As I said, get chrony if you want much faster convergence, if you want
> better control of the time offset from UTC, and if yourun Linux or
> BSD.

And this begs the question of "faster convergence towards *what*?"

NTP looks a a number of time sources, finds a majority clique that
exhibit "good" (consistent with respect to each other, as observed by
the local system) behavior, and steers the clock towards that time.

As I understand it, chrony steers the local clock towards the master
time source it is following.

Assuming this is all true (or true enough), there are times and
situations where one of these approaches is better than the other, and
other times and situations where the converse is true.

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

Re: [ntp:questions] NTP not syncing

[Harlan Stenn]

Magnus Danielson writes:
> The drift-file-accelerated lock-in isn't robust. Current behavior of
> response isn't very useful for most people experiencing it.

I'm not sure I'd agree with the word "most".  It's certainly worked very
well on hundreds of machines where I've run it, and the feedback I've
had from people when I've told them about iburst and drift files has
been positive except when they've had Linux kernels that calculate a
different clock frequency on a reboot.

There are at least 2 other issues here.

One goes to "robust", and yes, we can do better with that.  It's not yet
clear to me that in the wider perspective this effort will be worthwhile.

The other goes to the amount of time it takes to adequately determine
the offset and drift.

With a good driftfile and iburst, ntpd will sync to a handful of PPM in
about 11 seconds' time.

We've been working on a project to produce sufficiently accurate offset
and drift measurements at startup time, and the main problem here is
that it can take minutes to figure this out well, and there is a
significant need to get the time in the right ballpark at startup in
less than a minute.  These goals are mutually incompatible.  The intent
is to find a way to "get there" as well as possible, as quickly as
possible.

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-07, Magnus Danielson  wrote:
> On 12/07/2013 01:17 AM, unruh wrote:
>> On 2013-12-06, Magnus Danielson  wrote:
>>> On 12/06/2013 10:53 AM, Harlan Stenn wrote:
 mike cook writes:
>> If you know the drift file is unreliable, you should delete it.  ntpd
>> will then perform a frequency calibration before entering the main
>> loop. ...
> This is what has been recommended for ages but it doesn't completely
> fix the issue. It still takes a long time to settle. Here are the
> results of a test I did using the same system and ntp config as in my
> previous reply wit h the unrepresentative drift file data.
 An "unrepresentative drift file" is not a "deleted drift file".
>>> I filed a bug to address this. If the drift file is obviously nuts,
>>> ignore it for speed-up and just work as it was not there, that is, do
>>> normal frequency lock-in.
>> How does it know that the drift file is obviously nuts? 
>>
>> If it knew that it could fix it. It does not know that. ntpd ONLY knows
>> the current offset. Now on bootup if there is not drift file, then it
>> tries to remember the past few offsets and use those to estimate a
>> drift, but if there is a drift file, it trusts the value in that drift
>> file. If you are always going to do a drift estimate for the first few
>> polls anyway, why have a drift file at all?
> Well, we can discuss which is the best way to detect it, but when you
> fail to lock and is forced to re-set the time, then you surely know you
> didn't where were you expected to be.

??? There could be all kinds of reasons for that. 

>
> The drift-file-accelerated lock-in isn't robust. Current behavior of
> response isn't very useful for most people experiencing it.

While I do not particularly want to defend the ntpd philosophy, if you
buy that then it does help. Except for those broken Linux kernels which
did a really bad job of calibrating their clocks (apparently because
that takes time during bootup).
Remember that IF you have a good drift file, (ie one that corresponds
with the computer drift) then it does speed up convergence. And people
keep complaining that ntpd is slow to converge. The boot estimate of
drift is a real kludge stuck in there because so many complained that
ntpd was so slow to converge. It completely breaks the ntpd philosophy,
but only does so on bootup so that is OK:-).

As I said, get chrony if you want much faster convergence, if you want
better control of the time offset from UTC, and if yourun Linux or BSD.


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

Re: [ntp:questions] NTP not syncing

[Magnus Danielson]

On 12/07/2013 01:17 AM, unruh wrote:
> On 2013-12-06, Magnus Danielson  wrote:
>> On 12/06/2013 10:53 AM, Harlan Stenn wrote:
>>> mike cook writes:
> If you know the drift file is unreliable, you should delete it.  ntpd
> will then perform a frequency calibration before entering the main
> loop. ...
 This is what has been recommended for ages but it doesn't completely
 fix the issue. It still takes a long time to settle. Here are the
 results of a test I did using the same system and ntp config as in my
 previous reply wit h the unrepresentative drift file data.
>>> An "unrepresentative drift file" is not a "deleted drift file".
>> I filed a bug to address this. If the drift file is obviously nuts,
>> ignore it for speed-up and just work as it was not there, that is, do
>> normal frequency lock-in.
> How does it know that the drift file is obviously nuts? 
>
> If it knew that it could fix it. It does not know that. ntpd ONLY knows
> the current offset. Now on bootup if there is not drift file, then it
> tries to remember the past few offsets and use those to estimate a
> drift, but if there is a drift file, it trusts the value in that drift
> file. If you are always going to do a drift estimate for the first few
> polls anyway, why have a drift file at all?
Well, we can discuss which is the best way to detect it, but when you
fail to lock and is forced to re-set the time, then you surely know you
didn't where were you expected to be.

The drift-file-accelerated lock-in isn't robust. Current behavior of
response isn't very useful for most people experiencing it.

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-06, Magnus Danielson  wrote:
> On 12/06/2013 10:53 AM, Harlan Stenn wrote:
>> mike cook writes:
 If you know the drift file is unreliable, you should delete it.  ntpd
 will then perform a frequency calibration before entering the main
 loop. ...
>>> This is what has been recommended for ages but it doesn't completely
>>> fix the issue. It still takes a long time to settle. Here are the
>>> results of a test I did using the same system and ntp config as in my
>>> previous reply wit h the unrepresentative drift file data.
>> An "unrepresentative drift file" is not a "deleted drift file".
> I filed a bug to address this. If the drift file is obviously nuts,
> ignore it for speed-up and just work as it was not there, that is, do
> normal frequency lock-in.

How does it know that the drift file is obviously nuts? 

If it knew that it could fix it. It does not know that. ntpd ONLY knows
the current offset. Now on bootup if there is not drift file, then it
tries to remember the past few offsets and use those to estimate a
drift, but if there is a drift file, it trusts the value in that drift
file. If you are always going to do a drift estimate for the first few
polls anyway, why have a drift file at all?


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

Re: [ntp:questions] NTP not syncing

[Magnus Danielson]

On 12/06/2013 10:53 AM, Harlan Stenn wrote:
> mike cook writes:
>>> If you know the drift file is unreliable, you should delete it.  ntpd
>>> will then perform a frequency calibration before entering the main
>>> loop. ...
>> This is what has been recommended for ages but it doesn't completely
>> fix the issue. It still takes a long time to settle. Here are the
>> results of a test I did using the same system and ntp config as in my
>> previous reply wit h the unrepresentative drift file data.
> An "unrepresentative drift file" is not a "deleted drift file".
I filed a bug to address this. If the drift file is obviously nuts,
ignore it for speed-up and just work as it was not there, that is, do
normal frequency lock-in.

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

Re: [ntp:questions] NTP not syncing

[Charles Swiger]

Hi, all--

On Dec 6, 2013, at 4:13 AM, Martin Burnicki  wrote:
> Agreed. If ntpd would do initial corrections faster we wouldn't even need a 
> drift file, and it didn't matter if an OS kernel computed slightly different 
> clock frequencies each time the system reboots.

Unless your computer's quartz crystal is completely broken (admittedly, that 
happens) or unless there is a major bug in the operating system time 
calibration (ditto) it should provide timekeeping which is stable to within a 
few PPM over a 10 C temperature range.  An OCXO should be stable to better than 
+/- 1 ppm over a 50 C range.  [1]

The point of retaining a drift file is to provide a reliable first-order 
correction to the intrinsic drift of the system so that it can retain decent 
timekeeping even if it loses connectivity with higher-stratum time sources.  It 
shouldn't need to care about the minor fluctations in frequency due to daily 
temperature changes both because those average out and because the effect upon 
decent hardware running in temperature-controlled environments (ie, a data 
center) from temp-related frequency changes ought to be very small.

If the OS mis-calibrates the clock by a factor of 200 ppm upon system boot as 
some Linux 2.x kernels with buggy calibration routines evidently have, that 
vastly outweighs the effect of a ~1ppm frequency drift from temp.  Having to 
monitor, delete, and/or manually swap around your ntp.drift files is a pretty 
sure sign that you've got unstable timekeeping due to a problem somewhere and 
not because ntpd is doing the wrong thing.

There clearly are other opinions about this-- see Unruh for an example-- but to 
my mind, if daily temperature changes are affecting your timekeeping 
significantly, then something is wrong.  Perhaps you need to check for and 
de-dust CPU/PSU fans and validate that your environment cooling is working 
properly, or perhaps you need to swap out buggy hardware or software.  Or 
perhaps you choose to run chrony instead, which seems designed to chase 
short-term changes more rapidly than ntpd was designed to do.

Regards,
-- 
-Chuck

[1] Data per fig 5 of http://tf.nist.gov/general/pdf/581.pdf

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-06, Brian Inglis  wrote:
> It would be better if ntpd used the drift file frequency for the first
> two hours, instead of 15 minutes, before coming up with its (currently
> wild assed) guesstimate, and then spending 4 hours getting back to the
> drift frequency.

I do not think you understand. ntpd has a drift value-- a rate at which
it corrects the system clock (on linux this is using the adjtimex call).
If it find an offset, it changes that drift to eliminate that offset. If
one has a system where the drift file is off, but the offset is OK, then
ntp will take a while to even notice that the offset is increasing (part
of that wait is the poll interval, part is the clock filter which throws
out 80% of the poll results, and part of it is that the wrong drift will
not show up in the offset for a while.) Once it notices there is an
offset, it will alter the drift a little bit to try to eliminate that
offset. For the first while that offset will be small, and the drift
adjustment will be small. The offset continues to grow, and ntp makes
the drift correction larger and larger, but the offset continues to be
large. The drift finally badly overshoots and now the offset starts to
get smaller, but the drift keeps being increased because the offset is
still large. That drives the clock offsets finally off in the opposite
direction. 
It is this behaviour, that it only looks at the current offset to adjust
the drift that is the problem. With even a little bit of history, it is
obvious that the drift rate is way off. But ntpd does not keep any
history. This is one of the reasons why chrony performs so much better
than ntpd does. It does keep a history (it does a linear regression on
the past 3-64 offsets to determine the current offset and drift) and
uses it. The number of history points kept is varied depending on how
well the linear model (offset plus drift) fits the data.
There are other differences as well. 

ntpd works fine in keeping the time in a situation where there is only
noise-- variable network time delays, gaussian random white noise
affecting the local clock frequency or clock reading, etc. But for large
errors (bad drift file, sudden temperature change, ...) ntpd does poorly
in the sense that it takes a long time to notice and fix.  Since one of
the key sources of noise in a computer is temperature variations, this
means that in normal use ntpd does significantly worse than chrony in
keeping the offsets small (the offsets are at least a factor of 2 and I
have heard reports of a factor of 20 higher standard deviation in ntpd
than in chrony). I do not have good figures on how its drift rate
fluctuations compare to those of ntpd-- but probably worse. 


>
> This is on Windows 7, current stable ntpd, NMEA user mode pps ref clock
> (serialpps does not work with a 64 bit PCIe serial port driver stack).
>
> I try to avoid any issues by copying the drift file daily, if it is
> within limits, and copying back before startup, if it outside limits,
> to reduce issues with wild ntpd drift estimates.
>
> Could whatever was patched in Linux be required in the Windows port?

What was patched in Linux was the kernel by the kernel developers. Ie
way outside ntpd's pervue, and impossible on Windows. 


>

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

Re: [ntp:questions] NTP not syncing

[David Taylor]

On 06/12/2013 13:15, Brian Inglis wrote:
[]

I have automated the saving and restoring of drift files with good values
to replace drift files with bad values at startup, as the calibration on
Windows is way off, and it's often quicker to restart than wait many hours
ordays.
Possibly because MS disclaims timing within 2 seconds as an unreasonable
goal under Windows, and none of the Windows timing interfaces really are
good enough for NTP.
The hardware could be if it was used properly, but what Windows does with
timers makes them unreliable black boxes.

[]

Although with a PPS source Windows can be in the hundred microsecond region:

  http://www.satsignal.eu/mrtg/performance_ntp.php#windows-stratum-1

and within a few milliseconds when using a stratum-1 reference over the LAN:

  http://www.satsignal.eu/mrtg/performance_ntp.php#windows

--
Cheers,
David
Web: http://www.satsignal.eu

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

Re: [ntp:questions] NTP not syncing

[David Taylor]

On 06/12/2013 09:42, Jos van de Ven wrote:
[]

http://www.synclab.org/?tag=raspberry%20pi

Quote:

The Raspberry Pi does not ship with a TSC or HPET counter to use as clocksource. Instead 
it relies on the STC that raspbian presents as a clocksource. Based on the source code, 
"STC: a free running counter that increments at the rate of 1MHz".


Thanks for that pointer, Jos.  It's easy to add a GPS/PPS board to the 
RPi, and then you get performance (as reported by NTP) such as seen on 
the five RPi cards here:


  http://www.satsignal.eu/mrtg/performance_ntp.php

--
Cheers,
David
Web: http://www.satsignal.eu

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

Re: [ntp:questions] NTP not syncing

[Bruce Evans]

In article <99gou.413035$ur1.286...@fx19.iad>, unruh   wrote:
>On 2013-12-06, Bruce Evans  wrote:
>> ...
>> To handle the calibration varying across reboots, under FreeBSD I just
>> blow away the system calibration using a sysctl in an etc/rc file.
>> FreeBSD never had large variance in TSC calibration across reboots,
>> but I found the ones that it has annoying.  Most versions have a jitter
>> of only a couple of parts per million (ppm), but some have a fixed
>> error of about 10 ppm due to a sloppy calibration algorithm.  When
>> switching to a test or reference version with worse of just different
>> calibration, ntpd takes noticeably longer to sync, and syncing messes
>> up the driftfile for switching back.
>
>Do you know how the system calibrates the TSC on bootup? 

Standard FreeBSD uses the following rather too simple method:

tsc1 = rdtsc();
DELAY(100);
tsc2 = rdtsc();
tsc_freq = tsc2 - tsc1;

Here rdtsc() reads the TSC (on the current core), and DELAY(1 million)
counts down the i8254 timer by 1193182 cycles, which should take about
1 second.  The inaccuracies in this are:
- any difference between the i8254's nominal frequency of 1193182 Hz and
  its actual frequency.  Typically 20 parts per million.
- any setup overheads in DELAY() that are not accounted for.  Typically
  5 microseconds = another 5 parts per million.
- any setup overheads in DELAY() that are accounted for, but incorrectly.
  DELAY() still has some code that tries to compensate for old 486 systems,
  but this makes little difference now.
- any jitter in the setup overheads in DELAY().  Typically 2 microseconds.
  (It normally takes about 5 microseconds to read the i8254, and you can't
  control the timing of when the read starts.)
- any jitter from bus contention.  This may be large (more than 100
  microseconds), but usually isn't at boot time.
- any jitter from being interrupted near the beginning or end of DELAY().
  This may be huge (milliseconds), but usually isn't at boot time.
  Interrupts and bus contention both increase the DELAY() time by an
  amount that is not measured by the above.

I use many experimental variations of this.  The simplest one is:

DELAY(1);
tscval[0] = rdtsc();
DELAY(1000);
tscval[1] = rdtsc();
DELAY(1001000);
tscval[2] = rdtsc();
tsc_freq = tscval[2] - tscval[1] - (tscval[1] - tscval[0]);

The first DELAY() warms up caches.  The second one is used to compensate
for setup overheads (assuming low jitter and that DELAY() is not too smart,
so that the overhead is fixed).  The third one works as before.  This
method works well enough in practice.  (So does the previous one, but it
gives an unnecessary error of 5-10 ppm which ntpd has to compensate for.)
For 10 times more accuracy, it is easy to wait for 10 seconds instead of 1,
but that is too long when you reboot often.  Even 1 second of busy-waiting
is too long, even at boot time (do that for lots of devices and you get
boots taking minutes).

More sophisticated versions measure the actual delay time and compensate:

tsc_freq = (tscval[1] - tscval[0]) * actual_delay_in_usec / 1000;

(This is the first verison with a scale factor of not necessarily 1.)

Even more sophisticated versions determine error bounds for the actual
delay time, and discard samples where these bounds would be higher than
necessary, and run for just long enough to get a specified error bound
on the final frequency.  It is amusing to use the TSC (disciplined by
ntpd) to calibrate itself (raw).  On a 2 year old system, it takes 13
seconds to calibrate to the specified error bound of 1 cycle (1 part
in 2.67 billion).  You can see ntpd micro-adjusting the clock and the
TSC varying due to temperature changes because ntpd takes much longer
than 13 seconds to notice them.

Bruce

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

Re: [ntp:questions] NTP not syncing

[Jos van de Ven]

Op 6 dec. 2013, om 09:47 heeft unruh  het volgende geschreven:

> On 2013-12-06, David Taylor  wrote:
>> On 04/12/2013 21:25, Terje Mathisen wrote:
>> []
>>> It is very common, IF you are running on Linux!
>>> 
>>> The base frequency is recalculated each time you restart, which means
>>> that steps of 100-200 ppm from one reboot to the next can be expected.
>>> 
>>> Terje
>> 
>> I'm surprised to hear of this problem, as I've not been aware of it in 
>> years of running FreeBSD systems, and in more than a year of running 
>> (now) five Raspberry Pi Linux systems.  Perhaps I've been lucky?  As 
>> they are mainly experimental PCs, the RPi cards are rebooted more than most.
>> 
> 
> As I said, I think that in the more recent kernels Linux has fixed this.
> Since the RPi is only about 2 years old, its linux is a recent kernel. 

http://www.synclab.org/?tag=raspberry%20pi

Quote:

The Raspberry Pi does not ship with a TSC or HPET counter to use as 
clocksource. Instead it relies on the STC that raspbian presents as a 
clocksource. Based on the source code, "STC: a free running counter that 
increments at the rate of 1MHz".
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP not syncing

[Brian Inglis]

On 2013-12-05 11:58, David Woolley wrote:

On 05/12/13 14:24, mike cook wrote:



The problem for ntp is that ntp takes a long time to recover from a bad
drift value.



This seems to have been an issue since I started using ntp, more than 10 years 
ago. I am surprised that it is not fixed.


If you know the drift file is unreliable, you should delete it.
ntpd will then perform a frequency calibration before entering the main loop.
Otherwise it starts on the basis that the drift value is good and it is seeing 
measurement errors.


I have automated the saving and restoring of drift files with good values
to replace drift files with bad values at startup, as the calibration on
Windows is way off, and it's often quicker to restart than wait many hours
ordays.
Possibly because MS disclaims timing within 2 seconds as an unreasonable
goal under Windows, and none of the Windows timing interfaces really are
good enough for NTP.
The hardware could be if it was used properly, but what Windows does with
timers makes them unreliable black boxes.

At least from current stable forwards, drift does converge reliably, whereas
previous releases has drift and offset tracking each other all over the place.

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

Re: [ntp:questions] NTP not syncing

[Brian Inglis]

It would be better if ntpd used the drift file frequency for the first
two hours, instead of 15 minutes, before coming up with its (currently
wild assed) guesstimate, and then spending 4 hours getting back to the
drift frequency.

This is on Windows 7, current stable ntpd, NMEA user mode pps ref clock
(serialpps does not work with a 64 bit PCIe serial port driver stack).

I try to avoid any issues by copying the drift file daily, if it is
within limits, and copying back before startup, if it outside limits,
to reduce issues with wild ntpd drift estimates.

Could whatever was patched in Linux be required in the Windows port?

--
Take care. Thanks, Brian Inglis

On 2013-12-06 03:27, Charles Elliott wrote:

You might be able to do better.  In QC an average of a randomly gathered
sample of a continuous variable is distributed as normal (Gaussian).
If NTPD kept a few more statistics (state), it could measure the freq
and determine if it is outside of 3 standard deviations of the grand
mean of past observations of freq.  If it is outside then gather several
more observations of freq (5 total would be best, but 2 or three might
do) and compute the average.  If that average is outside 3 stdDev of
the mean, then the probability of that result is so low (< 0.05) that
it could not have happened by chance; something has changed.  NTPD must
use the new average as the current freq and include it in the grand mean,
but the user should be warned that something is awry.  On the other hand,
if the 2 or 3 new observations of the freq are not close to the original,
then just throw away the latter.

Charles Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
unruh
Sent: Friday, December 6, 2013 3:47 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP not syncing

On 2013-12-06, David Taylor  wrote:

On 04/12/2013 21:25, Terje Mathisen wrote:
[]

It is very common, IF you are running on Linux!

The base frequency is recalculated each time you restart, which means
that steps of 100-200 ppm from one reboot to the next can be expected.

Terje


I'm surprised to hear of this problem, as I've not been aware of it in
years of running FreeBSD systems, and in more than a year of running
(now) five Raspberry Pi Linux systems.  Perhaps I've been lucky?  As
they are mainly experimental PCs, the RPi cards are rebooted more than

most.




As I said, I think that in the more recent kernels Linux has fixed this.
Since the RPi is only about 2 years old, its linux is a recent kernel.


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

Re: [ntp:questions] NTP not syncing

[Martin Burnicki]

mike cook wrote:

Le 5 déc. 2013 à 19:58, David Woolley a écrit :

If you know the drift file is unreliable, you should delete it.
ntpd will then perform a frequency calibration before entering the
main loop.  Otherwise it starts on the basis that the drift value
is good and it is seeing measurement errors.


This is what has been recommended for ages but it doesn't completely
fix the issue. It still takes a long time to settle.


Agreed. If ntpd would do initial corrections faster we wouldn't even 
need a drift file, and it didn't matter if an OS kernel computed 
slightly different clock frequencies each time the system reboots.


Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

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

Re: [ntp:questions] NTP not syncing

[Miroslav Lichvar]

On Fri, Dec 06, 2013 at 10:17:48AM +, David Taylor wrote:
> On 06/12/2013 09:36, Harlan Stenn wrote:
> []
> >The only systems we've seen that did this are Linux kernels, and it
> >would be good to get the starting and ending dates/kernel numbers for
> >this behavior.
> >
> >H
> 
> The only data points I can contribute to that are that 3.2.27 and
> 3.6.11 appear to be OK, at least on the Raspberry Pi (Debian).

The relevant commit seems to be
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=08ec0c58fb8a05d3191d5cb6f5d6f81adb419798

It was included in 2.6.38.

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

Re: [ntp:questions] NTP not syncing

[David Taylor]

On 06/12/2013 09:36, Harlan Stenn wrote:
[]

The only systems we've seen that did this are Linux kernels, and it
would be good to get the starting and ending dates/kernel numbers for
this behavior.

H


The only data points I can contribute to that are that 3.2.27 and 3.6.11 
appear to be OK, at least on the Raspberry Pi (Debian).


--
Cheers,
David
Web: http://www.satsignal.eu

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

Re: [ntp:questions] NTP not syncing

[Charles Elliott]

You might be able to do better.  In QC an average of a randomly gathered 
sample of a continuous variable is distributed as normal (Gaussian).
If NTPD kept a few more statistics (state), it could measure the freq
and determine if it is outside of 3 standard deviations of the grand
mean of past observations of freq.  If it is outside then gather several
more observations of freq (5 total would be best, but 2 or three might
do) and compute the average.  If that average is outside 3 stdDev of 
the mean, then the probability of that result is so low (< 0.05) that
it could not have happened by chance; something has changed.  NTPD must
use the new average as the current freq and include it in the grand mean,
but the user should be warned that something is awry.  On the other hand,
if the 2 or 3 new observations of the freq are not close to the original,
then just throw away the latter.

Charles Elliott

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of
unruh
Sent: Friday, December 6, 2013 3:47 AM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] NTP not syncing

On 2013-12-06, David Taylor  wrote:
> On 04/12/2013 21:25, Terje Mathisen wrote:
> []
>> It is very common, IF you are running on Linux!
>>
>> The base frequency is recalculated each time you restart, which means 
>> that steps of 100-200 ppm from one reboot to the next can be expected.
>>
>> Terje
>
> I'm surprised to hear of this problem, as I've not been aware of it in 
> years of running FreeBSD systems, and in more than a year of running
> (now) five Raspberry Pi Linux systems.  Perhaps I've been lucky?  As 
> they are mainly experimental PCs, the RPi cards are rebooted more than
most.
>

As I said, I think that in the more recent kernels Linux has fixed this.
Since the RPi is only about 2 years old, its linux is a recent kernel. 


___
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] NTP not syncing

[mike cook]

Le 6 déc. 2013 à 10:53, Harlan Stenn a écrit :

> mike cook writes:
>>> If you know the drift file is unreliable, you should delete it.  ntpd
>>> will then perform a frequency calibration before entering the main
>>> loop. ...
>> 
>> This is what has been recommended for ages but it doesn't completely
>> fix the issue. It still takes a long time to settle. Here are the
>> results of a test I did using the same system and ntp config as in my
>> previous reply wit h the unrepresentative drift file data.
> 
> An "unrepresentative drift file" is not a "deleted drift file".

 All I'm saying here is that the same config was used.


> 
>> So under 5 minutes after the start we have a first estimation of the
>> drift.  It is not that bad, being only 10ppm from normal.
>> 
>> The drift file is not updated until an hour after startup, as
>> before. This is a shame as this better approximation would help if
>> there was a restart during this time.
> 
> So you are trying to shave the sync time down from 5 minutes for the
> case where somebody reboots the box within an hour of having rebooted
> the box?

   I am not trying to do anything. Just pointing out what I think is non 
optimal behavior.

> 
>> Fri Dec  6 00:30:49 CET 2013
>> *145.238.203.14  .TS-3.   1 u   31   64  377   14.237   -1.681   0.=
>> 254
>> mintc=3D3, offset=3D-1.681362, frequency=3D-33.536, sys_jitter=3D0.253768,
>> -rw-r--r-- 1 root root 8 Dec  6 00:30 /var/lib/ntp/ntp.drift
>> -33.536
>> 
>> We don't get back to the normal stable state until around 2hrs after
>> restart.
> 
> and by then the drift file will have been written twice, the first time
> getting you to within 10ppm and the second time that gets you better
> than that, right?
> 
> So this discussion is really about convergence, and apparently in the
> situation where folks do things to specifically mess things up just to
> see how long it takes to fix them?

  Just highlighting 2 corner cases relevant to the OP. In their case, IIRC they 
had issues with cpu stepping which left crappy drift file data hanging around. 
They were not "messing things up".

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

Re: [ntp:questions] NTP not syncing

[Harlan Stenn]

mike cook writes:
>> If you know the drift file is unreliable, you should delete it.  ntpd
>> will then perform a frequency calibration before entering the main
>> loop. ...
> 
> This is what has been recommended for ages but it doesn't completely
> fix the issue. It still takes a long time to settle. Here are the
> results of a test I did using the same system and ntp config as in my
> previous reply wit h the unrepresentative drift file data.

An "unrepresentative drift file" is not a "deleted drift file".

> So under 5 minutes after the start we have a first estimation of the
> drift.  It is not that bad, being only 10ppm from normal.
> 
> The drift file is not updated until an hour after startup, as
> before. This is a shame as this better approximation would help if
> there was a restart during this time.

So you are trying to shave the sync time down from 5 minutes for the
case where somebody reboots the box within an hour of having rebooted
the box?

> Fri Dec  6 00:30:49 CET 2013
> *145.238.203.14  .TS-3.   1 u   31   64  377   14.237   -1.681   0.=
> 254
> mintc=3D3, offset=3D-1.681362, frequency=3D-33.536, sys_jitter=3D0.253768,
> -rw-r--r-- 1 root root 8 Dec  6 00:30 /var/lib/ntp/ntp.drift
> -33.536
> 
> We don't get back to the normal stable state until around 2hrs after
> restart.

and by then the drift file will have been written twice, the first time
getting you to within 10ppm and the second time that gets you better
than that, right?

So this discussion is really about convergence, and apparently in the
situation where folks do things to specifically mess things up just to
see how long it takes to fix them?

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

Re: [ntp:questions] NTP not syncing

[mike cook]

Le 5 déc. 2013 à 19:58, David Woolley a écrit :

> On 05/12/13 14:24, mike cook wrote:
>>> 
>>> 
>>> The problem for ntp is that ntp takes a long time to recover from a bad
>>> drift value.
>>> 
>> 
>> This seems to have been an issue since I started using ntp, more than 10 
>> years ago. I am surprised that it is not fixed.
> 
> If you know the drift file is unreliable, you should delete it.  ntpd will 
> then perform a frequency calibration before entering the main loop.  
> Otherwise it starts on the basis that the drift value is good and it is 
> seeing measurement errors.

  This is what has been recommended for ages but it doesn't completely fix the 
issue. It still takes a long time to settle. Here are the results of a test I 
did using the same system and ntp config as in my previous reply with the 
unrepresentative drift file data.


root@raspberrypi:/home/mike# date;ntpq -pn |grep \*
Thu Dec  5 23:27:43 CET 2013
*145.238.203.14  .TS-3.   1 u   24   64  377   12.959   -0.193   0.219
root@raspberrypi:/home/mike# cat /var/lib/ntp/ntp.drift
-36.191

  As you can see , low us offset with the same ballpark drift as the previous 
test.

 root@raspberrypi:/home/mike# /etc/init.d/ntp stop
Stopping NTP server: ntpd.
root@raspberrypi:/home/mike# rm /var/lib/ntp/ntp.drift
root@raspberrypi:/home/mike# date;/etc/init.d/ntp start
Thu Dec  5 23:30:30 CET 2013
Starting NTP server: ntpd.
root@raspberrypi:/home/mike# ntpq -c rv
associd=0 status=0614 leap_none, sync_ntp, 1 event, freq_mode,
version="ntpd 4.2.7p319@1.2483 Tue May 28 11:26:22 UTC 2013 (2)",
processor="armv6l", system="Linux/3.2.27-pps", leap=00, stratum=2,
precision=-19, rootdelay=14.359, rootdisp=203.599, refid=145.238.203.14,
reftime=d64b7d18.e970d79a  Thu, Dec  5 2013 23:30:48.911,
clock=d64b7d1a.3b9c15ed  Thu, Dec  5 2013 23:30:50.232, peer=40375, tc=6,
mintc=3, offset=-5.357144, frequency=0.000, sys_jitter=2.798376,
  
clk_jitter=4.586, clk_wander=0.000
root@raspberrypi:/home/mike# while true; do date; ntpq -pn |grep \*;ntpq -c rv 
|grep frequency; ls -l /var/lib/ntp/ntp.drift;cat /var/lib/ntp/ntp.drift; sleep 
60; done
Thu Dec  5 23:31:25 CET 2013
*145.238.203.14  .TS-3.   1 u   37   641   14.3593.940   2.798
mintc=3, offset=-5.357144, frequency=0.000, sys_jitter=2.798376,
ls: cannot access /var/lib/ntp/ntp.drift: No such file or directory
cat: /var/lib/ntp/ntp.drift: No such file or directory
Thu Dec  5 23:32:25 CET 2013
*145.238.203.14  .TS-3.   1 u   41   643   14.3773.253   2.007
mintc=3, offset=-5.357144, frequency=0.000, sys_jitter=2.007095,
ls: cannot access /var/lib/ntp/ntp.drift: No such file or directory
cat: /var/lib/ntp/ntp.drift: No such file or directory
Thu Dec  5 23:33:26 CET 2013
*145.238.203.14  .TS-3.   1 u   36   647   14.3060.784   1.818
mintc=3, offset=-5.357144, frequency=0.000, sys_jitter=1.817799,
ls: cannot access /var/lib/ntp/ntp.drift: No such file or directory
cat: /var/lib/ntp/ntp.drift: No such file or directory
Thu Dec  5 23:34:26 CET 2013
*145.238.203.14  .TS-3.   1 u   30   64   17   14.373   -1.636   3.908
mintc=3, offset=-5.357144, frequency=0.000, sys_jitter=3.907557,
ls: cannot access /var/lib/ntp/ntp.drift: No such file or directory
cat: /var/lib/ntp/ntp.drift: No such file or directory
Thu Dec  5 23:35:26 CET 2013
*145.238.203.14  .TS-3.   1 u   24   64   37   14.405   -4.091   6.132
mintc=3, offset=-5.357144, frequency=0.000, sys_jitter=6.132177,
ls: cannot access /var/lib/ntp/ntp.drift: No such file or directory
cat: /var/lib/ntp/ntp.drift: No such file or directory
Thu Dec  5 23:36:27 CET 2013
*145.238.203.14  .TS-3.   1 u   18   64   77   12.958   -7.275   8.750
mintc=3, offset=-7.275249, frequency=-22.113, sys_jitter=8.750094,
ls: cannot access /var/lib/ntp/ntp.drift: No such file or directory
cat: /var/lib/ntp/ntp.drift: No such file or directory

So under 5 minutes after the start we have a first estimation of the drift. It 
is not that bad, being  only 10ppm from normal.

The drift file is not updated until an hour after startup, as before. This is a 
shame as this better approximation would help if there was a restart during 
this time.

Fri Dec  6 00:28:48 CET 2013
*145.238.203.14  .TS-3.   1 u   45   64  377   14.237   -1.681   0.320
mintc=3, offset=-1.681362, frequency=-33.536, sys_jitter=0.320081,
ls: cannot access /var/lib/ntp/ntp.drift: No such file or directory
cat: /var/lib/ntp/ntp.drift: No such file or directory
Fri Dec  6 00:29:48 CET 2013
*145.238.203.14  .TS-3.   1 u   37   64  377   14.237   -1.681   0.297
mintc=3, offset=-1.681362, frequency=-33.536, sys_jitter=0.296960,
ls: cannot access /var/lib/ntp/ntp.drift: No such file or directory
cat: /var/lib/ntp/ntp.drift: No such file or directory
Fri Dec  6 00:30:49 CET 2013
*145.238.203.14  .TS-3.   1 u   31   64  377   14.237   -1.681   0.254
mintc=3, offset=-1.

Re: [ntp:questions] NTP not syncing

[Harlan Stenn]

David Taylor writes:
> On 06/12/2013 08:47, unruh wrote:
> []
> > As I said, I think that in the more recent kernels Linux has fixed this.
> > Since the RPi is only about 2 years old, its linux is a recent kernel.
> 
> The one I've used are Linux 3.2.27 or 3.6.11.  However, one poster also 
> mentioned the problem is FreeBSD, although those servers have been 
> rebooted very infrequently.

We've been using FreeBSD for nearly 20 years' time and have not seen
this problem.  I've heard of no reports like this, either.

The only systems we've seen that did this are Linux kernels, and it
would be good to get the starting and ending dates/kernel numbers for
this behavior.

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

Re: [ntp:questions] NTP not syncing

[David Taylor]

On 06/12/2013 08:47, unruh wrote:
[]

As I said, I think that in the more recent kernels Linux has fixed this.
Since the RPi is only about 2 years old, its linux is a recent kernel.


The one I've used are Linux 3.2.27 or 3.6.11.  However, one poster also 
mentioned the problem is FreeBSD, although those servers have been 
rebooted very infrequently.


One other issue was that the PPS support in at least the 3.6.11 kernel 
was not optimised, see: http://bugs.ntp.org/show_bug.cgi?id=2314

--
Cheers,
David
Web: http://www.satsignal.eu

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-06, Bruce Evans  wrote:
> In article , unruh   
> wrote:
>>On 2013-12-05, antonio.marchese...@gmail.com
>> wrote:
>>>
>>> I understand and I apologise but I'm with a small netbook at the
>>moment and I can't do better. I'm trying to clean the posts before
>>posting them back.
>>>
>>> I'll see if I can fine an alternative. Thanks for your understanding
>>in the meantime.
 
 -258 IS pretty high. On what kind of machine? What operating system?
>>>
>>> Same machine that was before! Supermicro motherboard, debian 5.0.7
 
 The computer has to calibrate the timer interrupts on bootup. That
 calibration can be variable. For older versions of the Linux kernel that
 calibration was very variable, of the order that  you are seeing. That
 seems to have been fixed on the more recent kernels. 
>>>
>>> But I only restarted the ntp service, I did not reboot the server.
>>>
>>> As it's been said, I'm concerned that if the calibration can drift by
>>200ppm I may end up over the 500ppm boundary.
>>>
>>> But I understand that the drift file will change between reboots, but
>>it will then stabilise. Now the power saving is disabled I don't see the
>>drift changing over time, which should be good?
>>
>>Yes, power saving is definitely a problem if your system clock is using
>>tsc as the clock. The number of instructin cycles per secong changes
>>under powersaving and thus the system clock rate changes by huge
>>amounts. ( the powersaving could cause the cpu to go half as fast). The
>>only thing to do is to use some other counter as the system clock (HPET
>>should be better shouldn't it?-- I donot know how it behaves under
>>powersaving).
>
> Starting 5-10 years ago, many x86 systems have a TSC that isn't affected
> by power saving.  I don't have such a system, but the only problems that
> I know of on such systems are:
> - the hardware to implements such invariance makes reading the TSC much
>   slower (up from about 10 cycles on old Athlons to 50-70 cycles).  This
>   is still several times faster than reading an HPET and almost 100 times
>   faster than reading the ACPI timer.
> - There may be problems with keeping the TSCs of several cores in sync.
>   The hardware doesn't do this so transparently, and if the software
>   handles it then it makes reading the TSC even slower.
>
> To handle the calibration varying across reboots, under FreeBSD I just
> blow away the system calibration using a sysctl in an etc/rc file.
> FreeBSD never had large variance in TSC calibration across reboots,
> but I found the ones that it has annoying.  Most versions have a jitter
> of only a couple of parts per million (ppm), but some have a fixed
> error of about 10 ppm due to a sloppy calibration algorithm.  When
> switching to a test or reference version with worse of just different
> calibration, ntpd takes noticeably longer to sync, and syncing messes
> up the driftfile for switching back.

Do you know how the system calibrates the TSC on bootup? 

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-06, David Taylor  wrote:
> On 04/12/2013 21:25, Terje Mathisen wrote:
> []
>> It is very common, IF you are running on Linux!
>>
>> The base frequency is recalculated each time you restart, which means
>> that steps of 100-200 ppm from one reboot to the next can be expected.
>>
>> Terje
>
> I'm surprised to hear of this problem, as I've not been aware of it in 
> years of running FreeBSD systems, and in more than a year of running 
> (now) five Raspberry Pi Linux systems.  Perhaps I've been lucky?  As 
> they are mainly experimental PCs, the RPi cards are rebooted more than most.
>

As I said, I think that in the more recent kernels Linux has fixed this.
Since the RPi is only about 2 years old, its linux is a recent kernel. 


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

Re: [ntp:questions] NTP not syncing

[David Taylor]

On 04/12/2013 21:25, Terje Mathisen wrote:
[]

It is very common, IF you are running on Linux!

The base frequency is recalculated each time you restart, which means
that steps of 100-200 ppm from one reboot to the next can be expected.

Terje


I'm surprised to hear of this problem, as I've not been aware of it in 
years of running FreeBSD systems, and in more than a year of running 
(now) five Raspberry Pi Linux systems.  Perhaps I've been lucky?  As 
they are mainly experimental PCs, the RPi cards are rebooted more than most.


--
Cheers,
David
Web: http://www.satsignal.eu

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

Re: [ntp:questions] NTP not syncing

[Bruce Evans]

In article , unruh   wrote:
>On 2013-12-05, antonio.marchese...@gmail.com
> wrote:
>>
>> I understand and I apologise but I'm with a small netbook at the
>moment and I can't do better. I'm trying to clean the posts before
>posting them back.
>>
>> I'll see if I can fine an alternative. Thanks for your understanding
>in the meantime.
>>> 
>>> -258 IS pretty high. On what kind of machine? What operating system?
>>
>> Same machine that was before! Supermicro motherboard, debian 5.0.7
>>> 
>>> The computer has to calibrate the timer interrupts on bootup. That
>>> calibration can be variable. For older versions of the Linux kernel that
>>> calibration was very variable, of the order that  you are seeing. That
>>> seems to have been fixed on the more recent kernels. 
>>
>> But I only restarted the ntp service, I did not reboot the server.
>>
>> As it's been said, I'm concerned that if the calibration can drift by
>200ppm I may end up over the 500ppm boundary.
>>
>> But I understand that the drift file will change between reboots, but
>it will then stabilise. Now the power saving is disabled I don't see the
>drift changing over time, which should be good?
>
>Yes, power saving is definitely a problem if your system clock is using
>tsc as the clock. The number of instructin cycles per secong changes
>under powersaving and thus the system clock rate changes by huge
>amounts. ( the powersaving could cause the cpu to go half as fast). The
>only thing to do is to use some other counter as the system clock (HPET
>should be better shouldn't it?-- I donot know how it behaves under
>powersaving).

Starting 5-10 years ago, many x86 systems have a TSC that isn't affected
by power saving.  I don't have such a system, but the only problems that
I know of on such systems are:
- the hardware to implements such invariance makes reading the TSC much
  slower (up from about 10 cycles on old Athlons to 50-70 cycles).  This
  is still several times faster than reading an HPET and almost 100 times
  faster than reading the ACPI timer.
- There may be problems with keeping the TSCs of several cores in sync.
  The hardware doesn't do this so transparently, and if the software
  handles it then it makes reading the TSC even slower.

To handle the calibration varying across reboots, under FreeBSD I just
blow away the system calibration using a sysctl in an etc/rc file.
FreeBSD never had large variance in TSC calibration across reboots,
but I found the ones that it has annoying.  Most versions have a jitter
of only a couple of parts per million (ppm), but some have a fixed
error of about 10 ppm due to a sloppy calibration algorithm.  When
switching to a test or reference version with worse of just different
calibration, ntpd takes noticeably longer to sync, and syncing messes
up the driftfile for switching back.

I use a complicated rc file to support the following variations:
- switching the system version
- switching the frequency in the BIOS
- switching the CPU.  I have a system with 2 CPUs running at different
  frequencies.  I usually only use 1 (when this old system was used).
  The one used is random and switching it gives the same calibration
  changes as switching the frequency in the BIOS.
On most of my systems, the TSC frequency is a rational multiple of the
i8254 frequency.  Apparently, there is some master clock driving both
through a PLL to get multiples.  It is possible to determint the exact
(relative) multiple by looking at a continued fraction expansion of the
ratio of the frequencies, after determining this ratio very accurately.
On 1 system:

% # Multipliers 1783+5/13 @ 2127.9MHz, 1863+0 @ .9MHz (Barton 2800)
% # Goal: 1193182 -> 1193199, 2127902422 -> 2127932819, 898066 -> 929602
%   freq=$(sysctl -n machdep.tsc_freq)
%   if test $freq -ge 212750 -a $freq -lt 212850; then
%   multiplier=1783.384615385
%   fi
%   if test $freq -ge 50 -a $freq -lt 222350; then
%   multiplier=1863
%   fi
%   scale=1.14187

Each choice (in BIOS configuration) if o nominal freqency give a different
multiplier.  Only 2 are supported here.  The initial 'freq' variable is
the kernel calibration.  It may have a large error, but it only has to be
less than several thousand ppm for the above to map it correctly to the
exact multiplier.

Then there is a scale factor to map the frequency (multiplier * 1193182)
to the actual frequency.  1193182 is the nominal frequency of the i8254.
The scale factor is what is needed to convert this to the actual frequency.
Here the scale factor gives an adjustment by 14 ppm.  It is an average
determined over years of running this system.  The correct factor varies
by a few ppm with the season (due to variation of the average temperature),
and I used to sometimes adjust it with the season.  I never got around to
doing temperature adjustments in real time.

Most configurations don't need this complexity.  The adjustment in 'scale'
is a

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-05, antonio.marchese...@gmail.com  
wrote:
>
>> The problem with google groups is a) Many have filtered it out because
>> of spam so your audience is smaller, and b) it inserts a blank line
>> between every line of text it quotes, making threads raplidly unreadable
>> for everyone else. It may hide this from you, I donot know.
>
>
> Hi.
>
> I understand and I apologise but I'm with a small netbook at the moment and I 
> can't do better. I'm trying to clean the posts before posting them back.
>
> I'll see if I can fine an alternative. Thanks for your understanding in the 
> meantime.
>> 
>> -258 IS pretty high. On what kind of machine? What operating system?
>
> Same machine that was before! Supermicro motherboard, debian 5.0.7
>
>> 
>> The computer has to calibrate the timer interrupts on bootup. That
>> calibration can be variable. For older versions of the Linux kernel that
>> calibration was very variable, of the order that  you are seeing. That
>> seems to have been fixed on the more recent kernels. 
>
> But I only restarted the ntp service, I did not reboot the server.
>
> As it's been said, I'm concerned that if the calibration can drift by 200ppm 
> I may end up over the 500ppm boundary.
>
> But I understand that the drift file will change between reboots, but it will 
> then stabilise. Now the power saving is disabled I don't see the drift 
> changing over time, which should be good?

Yes, power saving is definitely a problem if your system clock is using
tsc as the clock. The number of instructin cycles per secong changes
under powersaving and thus the system clock rate changes by huge
amounts. ( the powersaving could cause the cpu to go half as fast). The
only thing to do is to use some other counter as the system clock (HPET
should be better shouldn't it?-- I donot know how it behaves under
powersaving).


>
> Thanks

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

Re: [ntp:questions] NTP not syncing

[antonio . marcheselli]

> The problem with google groups is a) Many have filtered it out because
> of spam so your audience is smaller, and b) it inserts a blank line
> between every line of text it quotes, making threads raplidly unreadable
> for everyone else. It may hide this from you, I donot know.


Hi.

I understand and I apologise but I'm with a small netbook at the moment and I 
can't do better. I'm trying to clean the posts before posting them back.

I'll see if I can fine an alternative. Thanks for your understanding in the 
meantime.
> 
> -258 IS pretty high. On what kind of machine? What operating system?

Same machine that was before! Supermicro motherboard, debian 5.0.7

> 
> The computer has to calibrate the timer interrupts on bootup. That
> calibration can be variable. For older versions of the Linux kernel that
> calibration was very variable, of the order that  you are seeing. That
> seems to have been fixed on the more recent kernels. 

But I only restarted the ntp service, I did not reboot the server.

As it's been said, I'm concerned that if the calibration can drift by 200ppm I 
may end up over the 500ppm boundary.

But I understand that the drift file will change between reboots, but it will 
then stabilise. Now the power saving is disabled I don't see the drift changing 
over time, which should be good?

Thanks

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-05, mike cook  wrote:
>> 
>> 
>> The problem for ntp is that ntp takes a long time to recover from a bad
>> drift value. 
>> 
>
> This seems to have been an issue since I started using ntp, more than 10 
> years ago. I am surprised that it is not fixed.

Because David Mills has no interest at all in fixing it. He has a model
for the operation of ntpd, and that model does not include rapid
correction of errors. It is designed for long term stability first and
foremost.

>
> A simple test on linux with a modern version of ntp:   Here is the normal 
> state of this R-PI
>
> Thu Dec  5 09:34:13 CET 2013
> mike@raspberrypi ~ $ sudo cat /var/lib/ntp/ntp.drift
> -36.772
> mike@raspberrypi ~ $ ls -l /var/lib/ntp/ntp.drift
> -rw-r--r-- 1 root root 8 Dec  5 08:51 /var/lib/ntp/ntp.drift
> mike@raspberrypi ~ $ ntpq  -pn |grep \*
> mintc=3, offset=-0.169517, frequency=-37.191, sys_jitter=0.333279,
>
>  offset with this server is  fairly stable at 1-300  microseconds, sometimes 
> better.
>
> So now stop ntpd , stick a silly value in the drift file and restart.
>
> root@raspberrypi:/home/mike# echo "-256.666" > /var/lib/ntp/ntp.drift
> root@raspberrypi:/home/mike# cat /var/lib/ntp/ntp.drift
> -256.666
> root@raspberrypi:/home/mike# /etc/init.d/ntp start
> Starting NTP server: ntpd.
> root@raspberrypi:/home/mike# ntpq -c rv
> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
> version="ntpd 4.2.7p319@1.2483 Tue May 28 11:26:22 UTC 2013 (2)",
> processor="armv6l", system="Linux/3.2.27-pps", leap=00, stratum=2,
> precision=-19, rootdelay=14.258, rootdisp=202.121, refid=145.238.203.14,
> reftime=d64aba43.dfdbb690  Thu, Dec  5 2013  9:39:31.874,
> clock=d64aba54.494fd9c7  Thu, Dec  5 2013  9:39:48.286, peer=2675, tc=6,
> mintc=3, offset=3.357234, frequency=-256.666, sys_jitter=1.622350,
> clk_jitter=2.342, clk_wander=0.000
>
> So we have picked up the drift and are using it as is, no verification.
>
> root@raspberrypi:/home/mike# ntpq -pn
> ...
> *145.238.203.14  .TS-3.   1 u   44   641   14.2583.357   1.622
> ...
> So iburst got us a reasonable start point. Now lets see how it evolves:
>
> oot@raspberrypi:/home/mike# while true; do date; ntpq -pn |grep \*;ntpq -c rv 
> |grep frequency; ls -l /var/lib/ntp/ntp.drift;cat /var/lib/ntp/ntp.drift; 
> sleep 60; done
> Thu Dec  5 09:46:00 CET 2013
> *145.238.203.14  .TS-3.   1 u   62   64   77   14.2583.357  11.413
> mintc=3, offset=16.974005, frequency=-256.666, sys_jitter=11.412631,
> -rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
> -256.666
>
> three samples later , 
>
> Thu Dec  5 09:49:01 CET 2013
> *145.238.203.14  .TS-3.   1 u   39   64  377   14.270   13.392  
> 25.459   the offset multiplies by three
> mintc=3, offset=16.974005, frequency=-256.666, sys_jitter=25.458613,
> -rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
> -256.666
> Thu Dec  5 09:50:02 CET 2013
> *145.238.203.14  .TS-3.   1 u   32   64  377   14.272   64.913  
> 38.415   then more than 20 times
> mintc=3, offset=64.912586, frequency=-224.970, sys_jitter=38.415064,
> -rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
> -256.666
> Thu Dec  5 09:51:02 CET 2013
> *145.238.203.14  .TS-3.   1 u   25   64  377   14.272   64.913  34.083
> mintc=3, offset=64.912586, frequency=-224.970, sys_jitter=34.083058,
> -rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
> -256.666
> Thu Dec  5 09:52:02 CET 2013
> *145.238.203.14  .TS-3.   1 u   19   64  377   14.242   78.513  
> 37.945   and it gets worse  - note that we still think this is a 
> good source
> mintc=3, offset=78.512782, frequency=-214.937, sys_jitter=37.944744,
> -rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
> -256.666
> Thu Dec  5 09:53:03 CET 2013
> *145.238.203.14  .TS-3.   1 u   10   64  377   14.242   78.513  30.074
> mintc=3, offset=78.512782, frequency=-214.937, sys_jitter=30.073729,
> -rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
> -256.666
>
> Our worst state is at 10:03, 30 minutes after the start up.  The real time 
> frequency value is decreasing but not reflected to the file. This is an issue 
> as an admin blindly restarting ntp after noticing crappy offsets will hit the 
> same wall again.
>
> The file gets updated after 1Hr, at 
>
> Thu Dec  5 10:39:21 CET 2013
> *145.238.203.14  .TS-3.   1 u   25   64  377   12.834   37.836   8.350
> mintc=3, offset=37.835862, frequency=-88.963, sys_jitter=8.349705,
> -rw-r--r-- 1 root root 8 Dec  5 10:39 /var/lib/ntp/ntp.drift
> -88.963
>
> The rate of convergence is getting quicker but we don't get back to a good 
> state until nearly 3Hrs:
>
> Thu Dec  5 12:20:02 CET 2013
> *145.238.203.14  .TS-3.   1 u   28   64  377   12.9790.287   0.693
> mintc=3, offset=0.287015, frequency=-38.180, sys_jitter=0.693195,
> -rw-r--r-- 1 root root 8 Dec  5 11:39 /var/lib/ntp/ntp.drift
> -41.923
>
> And 

Re: [ntp:questions] NTP not syncing

[David Woolley]

On 05/12/13 14:24, mike cook wrote:



The problem for ntp is that ntp takes a long time to recover from a bad
drift value.



This seems to have been an issue since I started using ntp, more than 10 years 
ago. I am surprised that it is not fixed.


If you know the drift file is unreliable, you should delete it.  ntpd 
will then perform a frequency calibration before entering the main loop. 
 Otherwise it starts on the basis that the drift value is good and it 
is seeing measurement errors.


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

Re: [ntp:questions] NTP not syncing

[mike cook]

> 
> 
> The problem for ntp is that ntp takes a long time to recover from a bad
> drift value. 
> 

This seems to have been an issue since I started using ntp, more than 10 years 
ago. I am surprised that it is not fixed.

A simple test on linux with a modern version of ntp:   Here is the normal state 
of this R-PI

Thu Dec  5 09:34:13 CET 2013
mike@raspberrypi ~ $ sudo cat /var/lib/ntp/ntp.drift
-36.772
mike@raspberrypi ~ $ ls -l /var/lib/ntp/ntp.drift
-rw-r--r-- 1 root root 8 Dec  5 08:51 /var/lib/ntp/ntp.drift
mike@raspberrypi ~ $ ntpq  -pn |grep \*
mintc=3, offset=-0.169517, frequency=-37.191, sys_jitter=0.333279,

 offset with this server is  fairly stable at 1-300  microseconds, sometimes 
better.

So now stop ntpd , stick a silly value in the drift file and restart.

root@raspberrypi:/home/mike# echo "-256.666" > /var/lib/ntp/ntp.drift
root@raspberrypi:/home/mike# cat /var/lib/ntp/ntp.drift
-256.666
root@raspberrypi:/home/mike# /etc/init.d/ntp start
Starting NTP server: ntpd.
root@raspberrypi:/home/mike# ntpq -c rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.7p319@1.2483 Tue May 28 11:26:22 UTC 2013 (2)",
processor="armv6l", system="Linux/3.2.27-pps", leap=00, stratum=2,
precision=-19, rootdelay=14.258, rootdisp=202.121, refid=145.238.203.14,
reftime=d64aba43.dfdbb690  Thu, Dec  5 2013  9:39:31.874,
clock=d64aba54.494fd9c7  Thu, Dec  5 2013  9:39:48.286, peer=2675, tc=6,
mintc=3, offset=3.357234, frequency=-256.666, sys_jitter=1.622350,
clk_jitter=2.342, clk_wander=0.000

So we have picked up the drift and are using it as is, no verification.

root@raspberrypi:/home/mike# ntpq -pn
...
*145.238.203.14  .TS-3.   1 u   44   641   14.2583.357   1.622
...
So iburst got us a reasonable start point. Now lets see how it evolves:

oot@raspberrypi:/home/mike# while true; do date; ntpq -pn |grep \*;ntpq -c rv 
|grep frequency; ls -l /var/lib/ntp/ntp.drift;cat /var/lib/ntp/ntp.drift; sleep 
60; done
Thu Dec  5 09:46:00 CET 2013
*145.238.203.14  .TS-3.   1 u   62   64   77   14.2583.357  11.413
mintc=3, offset=16.974005, frequency=-256.666, sys_jitter=11.412631,
-rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
-256.666

three samples later , 

Thu Dec  5 09:49:01 CET 2013
*145.238.203.14  .TS-3.   1 u   39   64  377   14.270   13.392  25.459  
 the offset multiplies by three
mintc=3, offset=16.974005, frequency=-256.666, sys_jitter=25.458613,
-rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
-256.666
Thu Dec  5 09:50:02 CET 2013
*145.238.203.14  .TS-3.   1 u   32   64  377   14.272   64.913  38.415  
 then more than 20 times
mintc=3, offset=64.912586, frequency=-224.970, sys_jitter=38.415064,
-rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
-256.666
Thu Dec  5 09:51:02 CET 2013
*145.238.203.14  .TS-3.   1 u   25   64  377   14.272   64.913  34.083
mintc=3, offset=64.912586, frequency=-224.970, sys_jitter=34.083058,
-rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
-256.666
Thu Dec  5 09:52:02 CET 2013
*145.238.203.14  .TS-3.   1 u   19   64  377   14.242   78.513  37.945  
 and it gets worse  - note that we still think this is a good source
mintc=3, offset=78.512782, frequency=-214.937, sys_jitter=37.944744,
-rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
-256.666
Thu Dec  5 09:53:03 CET 2013
*145.238.203.14  .TS-3.   1 u   10   64  377   14.242   78.513  30.074
mintc=3, offset=78.512782, frequency=-214.937, sys_jitter=30.073729,
-rw-r--r-- 1 root root 9 Dec  5 09:38 /var/lib/ntp/ntp.drift
-256.666

Our worst state is at 10:03, 30 minutes after the start up.  The real time 
frequency value is decreasing but not reflected to the file. This is an issue 
as an admin blindly restarting ntp after noticing crappy offsets will hit the 
same wall again.

The file gets updated after 1Hr, at 

Thu Dec  5 10:39:21 CET 2013
*145.238.203.14  .TS-3.   1 u   25   64  377   12.834   37.836   8.350
mintc=3, offset=37.835862, frequency=-88.963, sys_jitter=8.349705,
-rw-r--r-- 1 root root 8 Dec  5 10:39 /var/lib/ntp/ntp.drift
-88.963

The rate of convergence is getting quicker but we don't get back to a good 
state until nearly 3Hrs:

Thu Dec  5 12:20:02 CET 2013
*145.238.203.14  .TS-3.   1 u   28   64  377   12.9790.287   0.693
mintc=3, offset=0.287015, frequency=-38.180, sys_jitter=0.693195,
-rw-r--r-- 1 root root 8 Dec  5 11:39 /var/lib/ntp/ntp.drift
-41.923

And the "normal" drift is reached around 4hrs after the restart.

Thu Dec  5 13:30:30 CET 2013
*145.238.203.14  .TS-3.   1 u   60   64  377   12.8820.134   0.058
mintc=3, offset=0.134499, frequency=-37.307, sys_jitter=0.057602,
-rw-r--r-- 1 root root 8 Dec  5 12:39 /var/lib/ntp/ntp.drift
-37.928

I am sure that a much faster convergence could be achieved with a little 
thought, even if it meant a little ringing.


__

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-05, Harlan Stenn  wrote:
> unruh writes:
>> On 2013-12-05, mike cook  wrote:
>> >
>> > Le 4 d?c. 2013 ? 22:41, antonio.marchese...@gmail.com a ?crit :
>> >
>> >> 
>> >>> 
>>  I kept monitoring the drift file, but it was stable.
>> >> 
>> >>> Were you monitoring the modification times as well as the contents? As th
>> e logs were not being updated, maybe they were not being changed either?
>> >> 
>> >> Hi,
>> >> I'm not sure what you mean.
>> >> I was monitoring the status of the ntp using ntpd and the "o" option to se
>> e the offset and the status of the sources.
>> >> 
>> >> I was also reading the ntp.drift file to check the drift value.
>> >
>> >   Unfortunately there is no history for the drift file contents and the tim
>> es between updates seems irregular. looking around my systems I see
>> > OSX   >1hr
>> > FreeBSD   >5hr
>> > FreeBSD   >2hr40
>> > FreeBSD   >15m
>> > linux >1hr:50  
>> > Windows 7 > 2h
>> >
>> 
>> Once it has settled down ntp polls the server every 20 min (approx). But
>> it then sends that poll through a clock filter algorithm which throws
>> away roughly 7/8 of the results. (it keeps only that poll item whose
>> delay is smaller than any of the other delays of the last 8 polls),
>> which brings you up to roughly 2.5hr. between updates. 
>
> Bill, you say this a lot.

I say it because that is how ntpd acts. If I have misunderstood the
source code please correct me. 


>
> The experience we have is that the longer the delay the larger the
> error, and ntpd does its best to set the time based on the
> highest-quality time samples it can find.

Well, yes, but in the process it throws away data which could be used to
improve the evaluation of the time.
Is the improvement in error  obtained by averaging the 8 samples better or worse
than the error in taking the sample with the shortest round trip? The
answer will clearly depend on the exact type of noise. For example, if
we assume that the noise is dominated by random fluctuations in the
remote clock, then clearly averaging the 8 samples will give a better
estimate of the true ntp time than will taking the one sample with the
shortest delay. If the error is dominated by random errors in the travel
time, and the remote clock error is negligible, then the shortest round
trip might well provide the best estimate. Now, if you are concerned by
that clock synchronization in the Philipenes in the 1980s, and the time
is coming from the US Navel observatory, then the latter might well be a
good assumption. If however you are using a stratum 4 server in
someone's home from the pool, then the former would almost certainly be
a far better model for the noise, and the elimination of the 7 bits of
data with longer delay makes the errors in the ntp time on your machine
much worse than they could be. 

>
>>> I haven't looked at the source, but it may mean that ntpd updates the
>>> file only when there is a change in frequency, say due to temperature
>>> variations, but this is not systematic as if you check the frequency
>>> with ntpq -rv, you get data that can differ from the value in the
>>> file . There must be some time factor as well.
>> 
>> ntpd changes the offset ONLY by changing the frequency. Thus if there is
>> a non-zero offset, the frequency is changed ( and the offset is "never"
>> zero). Ie, anytime a new poll result makes it through the filter, it
>> changes the frequency. 
>
> This has nothing to do with the author's question about the drift file,
> which is updated once an hour iff there has been a significant change
> since the last time it was written.  See the code around line 259 of
> ntp_util.c in ntp-dev.

That you. I was not sure what the time scale was for the writing of the
drift file. Do you happen to remember what the definition of
"significant change" is? greater than SD of the drift?



>
>> > example:
>> > mike@raspberrypi ~ $ sudo ls -l /var/lib/ntp/ntp.drift
>> > -rw-r--r-- 1 root root 8 Dec  5 00:51 /var/lib/ntp/ntp.drift
>> 
>> AIUI, it does not write out the drift file every time it changes the
>> frequency.
>> The drift file is there to give an approximate value for the drift of
>> the system for next bootup. Since the new drift will certainly be
>> different from the present drift (temperature, recalibration of the
>> system clock, wear on the crystal, ) it is pointless to have the
>> file follow the current drift to closely.
>
> And the system clock recalibration of what used to be the "tick" value
> pretty much only happens on Linux kernels (and this may have been fixed
> recently).  The drift file value is tightly-coupled to that "tick"
> value.  That value was a constant most everywhere until [some version of
> the linux kernel] when somebody had the idea that the frequency needed
> to be calculated at each boot.  This means that from one linux boot to
> the next the tick value can change by about 200ppm (as I understand it),
> and these changes mess up the stored drift c

Re: [ntp:questions] NTP not syncing

[Harlan Stenn]

unruh writes:
> On 2013-12-05, mike cook  wrote:
> >
> > Le 4 d?c. 2013 ? 22:41, antonio.marchese...@gmail.com a ?crit :
> >
> >> 
> >>> 
>  I kept monitoring the drift file, but it was stable.
> >> 
> >>> Were you monitoring the modification times as well as the contents? As th
> e logs were not being updated, maybe they were not being changed either?
> >> 
> >> Hi,
> >> I'm not sure what you mean.
> >> I was monitoring the status of the ntp using ntpd and the "o" option to se
> e the offset and the status of the sources.
> >> 
> >> I was also reading the ntp.drift file to check the drift value.
> >
> >   Unfortunately there is no history for the drift file contents and the tim
> es between updates seems irregular. looking around my systems I see
> > OSX   >1hr
> > FreeBSD   >5hr
> > FreeBSD   >2hr40
> > FreeBSD   >15m
> > linux  >1hr:50  
> > Windows 7 > 2h
> >
> 
> Once it has settled down ntp polls the server every 20 min (approx). But
> it then sends that poll through a clock filter algorithm which throws
> away roughly 7/8 of the results. (it keeps only that poll item whose
> delay is smaller than any of the other delays of the last 8 polls),
> which brings you up to roughly 2.5hr. between updates. 

Bill, you say this a lot.

The experience we have is that the longer the delay the larger the
error, and ntpd does its best to set the time based on the
highest-quality time samples it can find.

>> I haven't looked at the source, but it may mean that ntpd updates the
>> file only when there is a change in frequency, say due to temperature
>> variations, but this is not systematic as if you check the frequency
>> with ntpq -rv, you get data that can differ from the value in the
>> file . There must be some time factor as well.
> 
> ntpd changes the offset ONLY by changing the frequency. Thus if there is
> a non-zero offset, the frequency is changed ( and the offset is "never"
> zero). Ie, anytime a new poll result makes it through the filter, it
> changes the frequency. 

This has nothing to do with the author's question about the drift file,
which is updated once an hour iff there has been a significant change
since the last time it was written.  See the code around line 259 of
ntp_util.c in ntp-dev.

> > example:
> > mike@raspberrypi ~ $ sudo ls -l /var/lib/ntp/ntp.drift
> > -rw-r--r-- 1 root root 8 Dec  5 00:51 /var/lib/ntp/ntp.drift
> 
> AIUI, it does not write out the drift file every time it changes the
> frequency.
> The drift file is there to give an approximate value for the drift of
> the system for next bootup. Since the new drift will certainly be
> different from the present drift (temperature, recalibration of the
> system clock, wear on the crystal, ) it is pointless to have the
> file follow the current drift to closely.

And the system clock recalibration of what used to be the "tick" value
pretty much only happens on Linux kernels (and this may have been fixed
recently).  The drift file value is tightly-coupled to that "tick"
value.  That value was a constant most everywhere until [some version of
the linux kernel] when somebody had the idea that the frequency needed
to be calculated at each boot.  This means that from one linux boot to
the next the tick value can change by about 200ppm (as I understand it),
and these changes mess up the stored drift calculation.  Yes, we could
do something about this, but nobody has volunteered to do this work.

H


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

Re: [ntp:questions] NTP not syncing

[Harlan Stenn]

mike cook writes:

> Unfortunately there is no history for the drift file contents and the
> times between updates seems irregular. looking around my systems I see
> OSX   >1hr
> FreeBSD   >5hr
> FreeBSD   >2hr40
> FreeBSD   >15m
> linux >1hr:50
> 
> Windows 7 > 2h
> 
>  I haven't looked at the source, but it may mean  that ntpd updates
the file only when there is a change in frequency, ...

Yes.  See prev_drift_comp in ntp_util.c.

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-05, mike cook  wrote:
>
> Le 4 d?c. 2013 ? 22:41, antonio.marchese...@gmail.com a ?crit :
>
>> 
>>> 
 I kept monitoring the drift file, but it was stable.
>> 
>>> Were you monitoring the modification times as well as the contents? As the 
>>> logs were not being updated, maybe they were not being changed either?
>> 
>> Hi,
>> I'm not sure what you mean.
>> I was monitoring the status of the ntp using ntpd and the "o" option to see 
>> the offset and the status of the sources.
>> 
>> I was also reading the ntp.drift file to check the drift value.
>
>   Unfortunately there is no history for the drift file contents and the times 
> between updates seems irregular. looking around my systems I see
> OSX   >1hr
> FreeBSD   >5hr
> FreeBSD   >2hr40
> FreeBSD   >15m
> linux>1hr:50  
> Windows 7 > 2h
>

Once it has settled down ntp polls the server every 20 min (approx). But
it then sends that poll through a clock filter algorithm which throws
away roughly 7/8 of the results. (it keeps only that poll item whose
delay is smaller than any of the other delays of the last 8 polls),
which brings you up to roughly 2.5hr. between updates. 


>  I haven't looked at the source, but it may mean  that ntpd updates the file 
> only when there is a change in frequency, say due to temperature variations, 
> but this is not systematic as if you check the frequency with ntpq -rv, you 
> get data that can differ from the value in the file . There must be some time 
> factor as well.

ntpd changes the offset ONLY by changing the frequency. Thus if there is
a non-zero offset, the frequency is changed ( and the offset is "never"
zero). Ie, anytime a new poll result makes it through the filter, it
changes the frequency. 


> example:
> mike@raspberrypi ~ $ sudo ls -l /var/lib/ntp/ntp.drift
> -rw-r--r-- 1 root root 8 Dec  5 00:51 /var/lib/ntp/ntp.drift

AIUI, it does not write out the drift file every time it changes the
frequency.
The drift file is there to give an approximate value for the drift of
the system for next bootup. Since the new drift will certainly be
different from the present drift (temperature, recalibration of the
system clock, wear on the crystal, ) it is pointless to have the
file follow the current drift to closely.


> mike@raspberrypi ~ $ sudo cat /var/lib/ntp/ntp.drift
> -36.656
> mike@raspberrypi ~ $ ntpq -c rv
> associd=0 status=061d leap_none, sync_ntp, 1 event, kern,
> version="ntpd 4.2.7p319@1.2483 Tue May 28 11:26:22 UTC 2013 (2)",
> processor="armv6l", system="Linux/3.2.27-pps", leap=00, stratum=2,
> precision=-19, rootdelay=12.702, rootdisp=15.447, refid=145.238.203.14,
> reftime=d64a40a8.49108193  Thu, Dec  5 2013  1:00:40.285,
> clock=d64a41e9.897ae5b9  Thu, Dec  5 2013  1:06:01.537, peer=45162, tc=6,
> mintc=3, offset=-0.172132, frequency=-36.748, sys_jitter=0.069766,
> clk_jitter=0.000, clk_wander=0.549
>
>  If you don't check the file modification times with ls or whatever as well 
> as the contents you may not know whether it is being updated or not.
>   

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

Re: [ntp:questions] NTP not syncing

[mike cook]

Le 4 déc. 2013 à 22:41, antonio.marchese...@gmail.com a écrit :

> 
>> 
>>> I kept monitoring the drift file, but it was stable.
> 
>> Were you monitoring the modification times as well as the contents? As the 
>> logs were not being updated, maybe they were not being changed either?
> 
> Hi,
> I'm not sure what you mean.
> I was monitoring the status of the ntp using ntpd and the "o" option to see 
> the offset and the status of the sources.
> 
> I was also reading the ntp.drift file to check the drift value.

  Unfortunately there is no history for the drift file contents and the times 
between updates seems irregular. looking around my systems I see
OSX   >1hr
FreeBSD   >5hr
FreeBSD   >2hr40
FreeBSD   >15m
linux  >1hr:50  
Windows 7 > 2h

 I haven't looked at the source, but it may mean  that ntpd updates the file 
only when there is a change in frequency, say due to temperature variations, 
but this is not systematic as if you check the frequency with ntpq -rv, you get 
data that can differ from the value in the file . There must be some time 
factor as well.
example:
mike@raspberrypi ~ $ sudo ls -l /var/lib/ntp/ntp.drift
-rw-r--r-- 1 root root 8 Dec  5 00:51 /var/lib/ntp/ntp.drift
mike@raspberrypi ~ $ sudo cat /var/lib/ntp/ntp.drift
-36.656
mike@raspberrypi ~ $ ntpq -c rv
associd=0 status=061d leap_none, sync_ntp, 1 event, kern,
version="ntpd 4.2.7p319@1.2483 Tue May 28 11:26:22 UTC 2013 (2)",
processor="armv6l", system="Linux/3.2.27-pps", leap=00, stratum=2,
precision=-19, rootdelay=12.702, rootdisp=15.447, refid=145.238.203.14,
reftime=d64a40a8.49108193  Thu, Dec  5 2013  1:00:40.285,
clock=d64a41e9.897ae5b9  Thu, Dec  5 2013  1:06:01.537, peer=45162, tc=6,
mintc=3, offset=-0.172132, frequency=-36.748, sys_jitter=0.069766,
clk_jitter=0.000, clk_wander=0.549

 If you don't check the file modification times with ls or whatever as well as 
the contents you may not know whether it is being updated or not.
  

> 
> Thanks
> Antonio
> 
> ___
> 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] NTP not syncing

[unruh]

On 2013-12-04, antonio.marchese...@gmail.com  
wrote:
> Hi All,
>
> I'm posting using google groups, hope this is not causing trouble (haven't 
> got my main PC now).

The problem with google groups is a) Many have filtered it out because
of spam so your audience is smaller, and b) it inserts a blank line
between every line of text it quotes, making threads raplidly unreadable
for everyone else. It may hide this from you, I donot know.

>
> Something strange is happening. Since I disabled power saving the two servers 
> which were not syncing have been ok, always synced and the drift file was 
> stable even though a little high on one server (-258 on one server, -58 on 
> another).

-258 IS pretty high. On what kind of machine? What operating system?

>
> I kept monitoring the drift file, but it was stable.
>
> The other day I restarted the service because the log file was not being 
> updated anymore.
>
> Now all three servers are properly syncing as before, and the logs are back. 
> But the server which had a drift file of -258 is now showing -1 and the one 
> which was showing -58 is now showing -2. The third server has not changed its 
> drift file, it's still around 21.
> I restarted the service 3-4 days ago, so the drift file should have 
> stabilised by now.

The computer has to calibrate the timer interrupts on bootup. That
calibration can be variable. For older versions of the Linux kernel that
calibration was very variable, of the order that  you are seeing. That
seems to have been fixed on the more recent kernels. 


>
> How is that possible?
>
> Ta
> Antonio

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-12-04, antonio.marchese...@gmail.com  
wrote:
>> 
>> It is very common, IF you are running on Linux!
>> 
>> 
>> 
>> The base frequency is recalculated each time you restart, which means 
>> that steps of 100-200 ppm from one reboot to the next can be expected.
>
> Hi,
>
> Yes, it's Linux.
> But I did not reboot the server, only the service.
> Anyway, I thought the drift was showing how much the BIOS clock was faster or 
> slower than the reference clock.

No. The bios clock is ONLY used on startup to set the intial time of the
system clock on bootup. It is never used thereafter. The system clock is
a counter (eg counting the number of processor instruction cycles,
counting the number of HPET cycles etc) but those counts have to be
calbrated to time. You have to know how many of those counts correspond
to a second. The computer does that at bootup (probablyusing the bios
clock, but I was never clear exactly how that calibration was done), and
on linux that used to be flakey (older Linux were fine, and then
something got broken) I think it is now fixed, but am not sure. 


>
> What do you mean when you say that the base frequency is recalculated?
>
> I must be very slow here, I've been asking about the drift but it seems I 
> still haven't grasped the meaning of it...

The drift is the difference between how many seconds the computer says
has elapsed vs the number of seconds that UTC says have elapsed
expressed as PPM ( (#computer seconds/#UTC seconds -1)*100)


>
> Thanks
> Antonio

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

Re: [ntp:questions] NTP not syncing

[antonio . marcheselli]

> 
> It is very common, IF you are running on Linux!
> 
> 
> 
> The base frequency is recalculated each time you restart, which means 
> that steps of 100-200 ppm from one reboot to the next can be expected.

Hi,

Yes, it's Linux.
But I did not reboot the server, only the service.
Anyway, I thought the drift was showing how much the BIOS clock was faster or 
slower than the reference clock.

What do you mean when you say that the base frequency is recalculated?

I must be very slow here, I've been asking about the drift but it seems I still 
haven't grasped the meaning of it...

Thanks
Antonio

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

Re: [ntp:questions] NTP not syncing

[antonio . marcheselli]

> 
> > I kept monitoring the drift file, but it was stable.
 
> Were you monitoring the modification times as well as the contents? As the 
> logs were not being updated, maybe they were not being changed either?

Hi,
I'm not sure what you mean.
I was monitoring the status of the ntp using ntpd and the "o" option to see the 
offset and the status of the sources.

I was also reading the ntp.drift file to check the drift value.

Thanks
Antonio

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

Re: [ntp:questions] NTP not syncing

[Terje Mathisen]

antonio.marchese...@gmail.com wrote:

Hi All,

I'm posting using google groups, hope this is not causing trouble
(haven't got my main PC now).

Something strange is happening. Since I disabled power saving the two
servers which were not syncing have been ok, always synced and the
drift file was stable even though a little high on one server (-258
on one server, -58 on another).

I kept monitoring the drift file, but it was stable.

The other day I restarted the service because the log file was not
being updated anymore.

Now all three servers are properly syncing as before, and the logs
are back. But the server which had a drift file of -258 is now
showing -1 and the one which was showing -58 is now showing -2. The
third server has not changed its drift file, it's still around 21. I
restarted the service 3-4 days ago, so the drift file should have
stabilised by now.

How is that possible?


It is very common, IF you are running on Linux!

The base frequency is recalculated each time you restart, which means 
that steps of 100-200 ppm from one reboot to the next can be expected.


Terje

--
- 
"almost all programming can be viewed as an exercise in caching"

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

Re: [ntp:questions] NTP not syncing

[mike cook]

Le 4 déc. 2013 à 20:32, antonio.marchese...@gmail.com a écrit :

> Hi All,
> 
> I'm posting using google groups, hope this is not causing trouble (haven't 
> got my main PC now).
> 
> Something strange is happening. Since I disabled power saving the two servers 
> which were not syncing have been ok, always synced and the drift file was 
> stable even though a little high on one server (-258 on one server, -58 on 
> another).
> 
> I kept monitoring the drift file, but it was stable.

Were you monitoring the modification times as well as the contents? As the logs 
were not being updated, maybe they were not being changed either?

> 
> The other day I restarted the service because the log file was not being 
> updated anymore.
> 
> Now all three servers are properly syncing as before, and the logs are back. 
> But the server which had a drift file of -258 is now showing -1 and the one 
> which was showing -58 is now showing -2. The third server has not changed its 
> drift file, it's still around 21.
> I restarted the service 3-4 days ago, so the drift file should have 
> stabilised by now.
> 
> How is that possible?
> 
> Ta
> Antonio
> 
> ___
> 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] NTP not syncing

[antonio . marcheselli]

Hi All,

I'm posting using google groups, hope this is not causing trouble (haven't got 
my main PC now).

Something strange is happening. Since I disabled power saving the two servers 
which were not syncing have been ok, always synced and the drift file was 
stable even though a little high on one server (-258 on one server, -58 on 
another).

I kept monitoring the drift file, but it was stable.

The other day I restarted the service because the log file was not being 
updated anymore.

Now all three servers are properly syncing as before, and the logs are back. 
But the server which had a drift file of -258 is now showing -1 and the one 
which was showing -58 is now showing -2. The third server has not changed its 
drift file, it's still around 21.
I restarted the service 3-4 days ago, so the drift file should have stabilised 
by now.

How is that possible?

Ta
Antonio

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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

On 25/11/2013 22:37, David Woolley wrote:

On 25/11/13 12:14, Antonio Marcheselli wrote:

On 25/11/2013 07:50, David Woolley wrote:

On 25/11/13 00:55, Antonio Marcheselli wrote:


restrict 130.1.1.1 mask 255.255.255.0 nomodify



That's an invalid combination.  You can't have a bit set in the pattern
which is not set in the mask.  That's basic TCP/IP stuff.



Hope I won't look too dumb here but I'm not following you, sorry. .1 is
within the 0 mask, isn't it?


You replied three times.   0 has no bits set.


Apologies, my server was giving time out, I did not realise the message 
was going through anyway.


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

Re: [ntp:questions] NTP not syncing

[Brian Inglis]

On 2013-11-24 18:05, Antonio Marcheselli wrote:


'restrict 192.168.1.10' sets a null restriction set for that address.
IOW it removes all restrictions.


Thanks Steve.

I had a look at the 'restrict' parameters; the line I have is

restrict 130.1.1.1 mask 255.255.255.0 nomodify


As David implied earlier - if a bit is zero in the mask it must be zero in the 
address!
Mask is for unrestricting a subnet - in this case 130.1.1.0 => .0-.255.
If you want to change restrictions for a single address do not use any mask,
so it defaults to the mask 255.255.255.255 for a single address.


which I understand prevents 130.1.1.1 from modifying the NTP configuration, is 
that correct?


You need to start by blocking everything:
restrict default kod limited nomodify notrap nopeer noquery
to block most stuff from most places, as the default is allow everything from 
everywhere,
equivalent to:
restrict 0.0.0.0 mask 0.0.0.0   # notice no restrictions!!!
for other NTP servers add:
restrict name kod limited nomodify notrap
then allow the localhost to change anything:
restrict 127.0.0.1  # allow ipv4 localhost
restrict ::1# allow ipv6 localhost6
and if you have other admin servers you can add similar statements with their 
DNS names.

I look forward to others correcting any bad assumptions I picked up from old 
releases. ;^>
--
Take care. Thanks, Brian Inglis
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP not syncing

[David Woolley]

On 25/11/13 12:14, Antonio Marcheselli wrote:

On 25/11/2013 07:50, David Woolley wrote:

On 25/11/13 00:55, Antonio Marcheselli wrote:


restrict 130.1.1.1 mask 255.255.255.0 nomodify



That's an invalid combination.  You can't have a bit set in the pattern
which is not set in the mask.  That's basic TCP/IP stuff.



Hope I won't look too dumb here but I'm not following you, sorry. .1 is
within the 0 mask, isn't it?


You replied three times.   0 has no bits set.

a & 0xff00 can never equal 0x82010101.

(Many implementations allow for this sort of error by actually 
evaluating this as (a & 0xff00)  == (0x82010101 & 0xff00).)


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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

On 25/11/2013 07:50, David Woolley wrote:

On 25/11/13 00:55, Antonio Marcheselli wrote:


restrict 130.1.1.1 mask 255.255.255.0 nomodify



That's an invalid combination.  You can't have a bit set in the pattern
which is not set in the mask.  That's basic TCP/IP stuff.



Hope I won't look too dumb here but I'm not following you, sorry. .1 is 
within the 0 mask, isn't it?


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

Re: [ntp:questions] NTP not syncing

[Steve Kostecke]

On 2013-11-25, Antonio Marcheselli  wrote:

>> 'restrict 192.168.1.10' sets a null restriction set for that address.
>> IOW it removes all restrictions.
>
> I had a look at the 'restrict' parameters; the line I have is
>
> restrict 130.1.1.1 mask 255.255.255.0 nomodify
>
> which I understand prevents 130.1.1.1 from modifying the NTP 
> configuration, is that correct?

'nomodify' blocks the use of ntpq / ntpdc remote configuration commands.
'nomodify' does not prevent someone sending the time to your ntpd. 

'restrict 130.1.1.1 nomodify' replaces the default restriction with
'nomodify' for 130.1.1.1

FWIW ... NTP remote configuration is not possible unless one of the
following conditions are met:

1. ntpd is started with the command-line option which disabled
authentication

or

2. ntp.conf contains the configuration directive to disable authenticate

or

3. the non-trivial symmetric key configuration is correctly completed
_and_ the remote user possesses the correct authentication credentials

-- 
Steve Kostecke 
NTP Public Services Project - http://support.ntp.org/

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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

On 25/11/2013 07:50, David Woolley wrote:

On 25/11/13 00:55, Antonio Marcheselli wrote:


restrict 130.1.1.1 mask 255.255.255.0 nomodify



That's an invalid combination.  You can't have a bit set in the pattern
which is not set in the mask.  That's basic TCP/IP stuff.



Hope I won't look too dumb here but I'm not following you, sorry. .1 is 
within the 0 mask, isn't it?


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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

On 25/11/2013 07:50, David Woolley wrote:

On 25/11/13 00:55, Antonio Marcheselli wrote:


restrict 130.1.1.1 mask 255.255.255.0 nomodify



That's an invalid combination.  You can't have a bit set in the pattern
which is not set in the mask.  That's basic TCP/IP stuff.



Hope I won't look too dumb here but I'm not following you, sorry. .1 is 
within the 0 mask, isn't it?


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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

'restrict 192.168.1.10' sets a null restriction set for that address.
IOW it removes all restrictions.


Thanks Steve.

I had a look at the 'restrict' parameters; the line I have is

restrict 130.1.1.1 mask 255.255.255.0 nomodify

which I understand prevents 130.1.1.1 from modifying the NTP 
configuration, is that correct?


Thanks
Antonio

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

Re: [ntp:questions] NTP not syncing

[David Woolley]

On 25/11/13 00:55, Antonio Marcheselli wrote:


restrict 130.1.1.1 mask 255.255.255.0 nomodify



That's an invalid combination.  You can't have a bit set in the pattern 
which is not set in the mask.  That's basic TCP/IP stuff.


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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

'restrict 192.168.1.10' sets a null restriction set for that address.
IOW it removes all restrictions.


Thanks Steve.

I had a look at the 'restrict' parameters; the line I have is

restrict 130.1.1.1 mask 255.255.255.0 nomodify

which I understand prevents 130.1.1.1 from modifying the NTP 
configuration, is that correct?


Thanks
Antonio

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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

'restrict 192.168.1.10' sets a null restriction set for that address.
IOW it removes all restrictions.


Thanks Steve.

I had a look at the 'restrict' parameters; the line I have is

restrict 130.1.1.1 mask 255.255.255.0 nomodify

which I understand prevents 130.1.1.1 from modifying the NTP 
configuration, is that correct?


Thanks
Antonio

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

Re: [ntp:questions] NTP not syncing

[Steve Kostecke]

On 2013-11-23, Antonio Marcheselli  wrote:

> Another quick question: does the "restrict" parameter prevent any other 
> server from using the server's NTP as a source?
>
> If I use "restrict 192.168.1.10" does that mean that only 192.168.1.10 
> can use that NTP as a source?

'restrict 192.168.1.10' sets a null restriction set for that address.
IOW it removes all restrictions.

'restrict some.address ignore' tells ntpd to ignore all packets from
that address.

'restrict some.address noquery' tells ntpd to ignore ntpq/ntpc queries
from that address.

'restrict some.address noserve' tells ntpd to ignore time polls from
that address.

'restrict some.address notrust' tells ntpd to ignore all unauthenticated
packets from that address.

Restriction lines for specific hosts / subnets make sense when they're
used with a default restriction.

'restrict default ...' applies to all addresses/netblocks which don't
have an explicit restrict line.

-- 
Steve Kostecke 
NTP Public Services Project - http://support.ntp.org/

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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

You might check whether the system boards do power saving by changing cpu clock 
frequencies. That throws ntpd.





  Some more info in the same vein. This issue has been seen with Supermicro 
boards as far back as 2006.
Check out the following to see if your linux is configured to manage cpu 
stepping. If you don't see it there, disable it in the BIOS.


Hello,

Well, I have great news.
I happened to be on site and found that both servers with NTP problems 
had the Intel CPU stepping enabled in the BIOS.
I disabled it and it now works, the drift file is steady - even though 
on some large amount, 250 on one and 160 on another.


The third server which always worked does not have any power saving 
features (older motherboard) and the drift is stable at around 21.


So far so good then. I must thank you all for the massive help received 
on this forum, it's been a honour to talk with you guys.


I'll post an update to confirm that all is good!

Another quick question: does the "restrict" parameter prevent any other 
server from using the server's NTP as a source?


If I use "restrict 192.168.1.10" does that mean that only 192.168.1.10 
can use that NTP as a source?


Thanks again

Tony

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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

On 10/11/2013 17:14, Steve Kostecke wrote:

On 2013-11-08, Antonio Marcheselli  wrote:


Question related to this topic. I am told that I can enable the HPET on
the motherboard and I can tell linux to use it.

The file I am trying to amend is
/sys/devices/system/clocksource/clocksource0/available_clocksource

I have a I/O error when I try to save. The folder and the file have RW
permissions, any idea on why I can't amend it?


Sysfs (/sys/*) is a virtual file system provided by Linux. Sysfs exports
information about devices and drivers from the kernel device model to
user space, and is also used for configuration. It is similar to the
sysctl mechanism found in BSD systems, but implemented as a file system
instead of a separate mechanism.


Thanks Steve,

I'll go through the documentation and find out more.

Cheers
Antonio

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

Re: [ntp:questions] NTP not syncing

[Steve Kostecke]

On 2013-11-08, Antonio Marcheselli  wrote:

> Question related to this topic. I am told that I can enable the HPET on 
> the motherboard and I can tell linux to use it.
>
> The file I am trying to amend is 
> /sys/devices/system/clocksource/clocksource0/available_clocksource
>
> I have a I/O error when I try to save. The folder and the file have RW 
> permissions, any idea on why I can't amend it?

Sysfs (/sys/*) is a virtual file system provided by Linux. Sysfs exports
information about devices and drivers from the kernel device model to
user space, and is also used for configuration. It is similar to the
sysctl mechanism found in BSD systems, but implemented as a file system
instead of a separate mechanism.

Sysfs documentation is available at
https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt

/sys/devices/system/clocksource/clocksource0/available_clocksource is
the Sysfs interface for listing the available clock sources.

/sys/devices/system/clocksource/clocksource0/current_clocksource is the
Sysfs interface for listing _or_ setting the current clock source.

e.g.

# cd /sys/devices/system/clocksource/clocksource0/
# ls -l
total 0
-r--r--r-- 1 root root 4096 Jul 18 07:48 available_clocksource
-rw-r--r-- 1 root root 4096 Nov  9 14:28 current_clocksource
# cat available_clocksource 
tsc hpet acpi_pm 
# cat current_clocksource 
tsc
# echo hpet > current_clocksource
# cat current_clocksource
hpet

-- 
Steve Kostecke 
NTP Public Services Project - http://support.ntp.org/

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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

On 03/11/2013 01:24, Antonio Marcheselli wrote:

   That's about it. One of the assumptions made by NTP is that it is
running at a fixed clock speed (or rather that the system 'clock
source' is). So when that sources frequency is altered for power
saving or performance enhancement (you can configure both) , it will
be seen as slowing or speeding up  when compared with the configured
servers timestamps. If for instance, after booting and ntp startup the
cpu goes idle, then the frequency could be lowered, causing the clock
source to slow down, causing your problem. In older implementations I
believe that the cpu frequency lowering also caused the clock source
to slow (ex. the TSC was directly linked to the cpu frequency) but I
believe that some newer cpus keep the clock source running at a
constant frequency and just modify the execution units frequency to
avoid this issue.


Cheers for that, I'll have a look.


The server with the drift file at 450 was rebooted and the drift went to 
500+. Restarting the NTP is not helping.

I definitely need to look at the hardware.

I'd like to thank you all, I have investigated on NTP for some time now 
and nobody was able to explain things clearly as you did.


Thank you guys!

Question related to this topic. I am told that I can enable the HPET on 
the motherboard and I can tell linux to use it.


The file I am trying to amend is 
/sys/devices/system/clocksource/clocksource0/available_clocksource


I have a I/O error when I try to save. The folder and the file have RW 
permissions, any idea on why I can't amend it?


Thanks
Antonio

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

Re: [ntp:questions] NTP not syncing

[Magnus Danielson]

Antonio,

On 11/04/2013 06:40 PM, Antonio Marcheselli wrote:
>> If the oscillator drifts from last drift-file write, outside of +/- 15
>> ppm if I recall it, it fails to lock in again.
>> It would be good if it could bail out and do normal frequency
>> acquisition if that occurs.
>>
>> That particular "feature" have bitten hard, and was a side-consequence
>> of other faults, but none-the-less.
>
> Thanks Magnus, I saw the bug report you filed.
>
> Would it be wiser to delete the drift file at boot - by script - and
> let ntpd resync and recreate a new drift file?
>
> As mentioned, I don't really need my system to be synced down to the
> millisecond, if ntpd takes a few hours to settle and the time is off
> up to a few seconds during that time it's perfectly fine with me.
If you don't want the bootstrap feature of drift-file, don't specify it
in the configuration is much wiser than deleting it.

It's good to have this acceleration, if we can make it to be fool-proof.
This is an attempt to get in that direction.

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

Re: [ntp:questions] NTP not syncing

[unruh]

On 2013-11-04, Charles Swiger  wrote:
> Hi--
>
> On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli  wrote:
>> Would it be wiser to delete the drift file at boot - by script - and let 
>> ntpd resync and recreate a new drift file?
>
> Normally, no.
>
> The drift file lets ntpd perform a first-order correction of the average 
> intrinsic drift of the local clock even if ntpd can't get time from any other 
> sources.  However, if the drift can't be computed correctly because of some 
> unusual problem-- and a systemic drift of over 500ppm is fairly unusual-- 
> then deleting the drift file might help.

It used to be on older version of linux, that the calibration of the
computer clock on boot was off. Thus the calibration would mean that the
clock rate would vary by 50-100PPM on successive reboots. This would
make the drift file pretty useless. 
>
>> As mentioned, I don't really need my system to be synced down to the 
>> millisecond, if ntpd takes a few hours to settle and the time is off up to a 
>> few seconds during that time it's perfectly fine with me.
>
> Gracious.  In that case, run ntpdate via cron every hour or so and you'll 
> probably stay within that tolerance even if ntpd itself can't manage to stay 
> in sync.  However, if switching your system's clock source from whatever you 
> are using now to HPET, ACPI, etc improves matters so that ntpd remains 
> stable, that would obviously provide much better timekeeping.
>
> Regards,

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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

On 04/11/2013 19:50, Charles Swiger wrote:

On Nov 4, 2013, at 11:36 AM, Harlan Stenn  wrote:

Running ntpdate every hour instead of running ntpd won't work if there
are database servers or dovecot or other apps that require monotonic
time.


Did you somehow know whether the existing 500+ ppm drift is stable?


I'm monitoring the drift files of the three servers.

The server which got stuck on -500.000 is now on -62, stable.
Another server which gave "frequency error" is now on -430, stable - I 
guess when the server is rebooted it's likely to give frequency error 
again while ntpd locks on the frequency?


So it looks like that the first server has no clock issues and the 
initial problem was NTP related.

The second server has a clock issue, which I'll try to look into.

Thanks
Antonio

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

Re: [ntp:questions] NTP not syncing

[Steve Kostecke]

On 2013-11-04, Antonio Marcheselli  wrote:

> That is being considered. The server runs a maintenance procedure every 
> 24hours when all the services are stopped momentarily. It could be the 
> right time for an ntpdate to run.

ntpd continuously disciplines the system clock (i.e. attempts to steer
it towards the aparent correct time).

ntpdate (or sntp) merely adjusts the system clock once each time the
utility is run. The system clock will then drift until the next
correction.

When faced with a system clock which is drifting monotonically at > 400
to 500PPM the best course of action is to bite the bullet and determine
a sane tick value. In virtually all cases this will allow ntpd to
control your clock.

-- 
Steve Kostecke 
NTP Public Services Project - http://support.ntp.org/

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

Re: [ntp:questions] NTP not syncing

[Charles Swiger]

On Nov 4, 2013, at 11:36 AM, Harlan Stenn  wrote:
> Running ntpdate every hour instead of running ntpd won't work if there
> are database servers or dovecot or other apps that require monotonic
> time.

Did you somehow know whether the existing 500+ ppm drift is stable?

> But if the system clock is always running slow this *probably* won't be
> an issue, and it also again points to lost clock interrupts.  Better to
> solve the underlying problem.

Yes, it's best to solve the underlying problem.  Lost interrupts, a flaky XO,
operating system bugs, etc are all possible.  Some of these might be easy to
fix though, ie, by choosing a different system clock source...

Regards,
-- 
-Chuck

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

Re: [ntp:questions] NTP not syncing

[Steve Kostecke]

On 2013-11-03, Antonio Marcheselli  wrote:
> On 03/11/2013 05:55, David Taylor wrote:
>> On 02/11/2013 20:41, unruh wrote:
>>> On 2013-11-02, antonio.marchese...@gmail.com
>>>  wrote:
>> []
 How can I verify if the stepping has been disabled or not?
 ntp.drift at the moment is -500.000
>>>
>>> Which is way out of spec and cannot be corrected by ntpd.
>>
>> Yes, it can be corrected.  There are ways of offsetting NTP to allow for
>> clocks which are more than 500 ppm off nominal.  Likely it's
>> OS-dependant, but for Windows I documented the method here:
>>
>>http://www.satsignal.eu/ntp/setup.html#broken-clock

There is information about fixing this issue in the NTP Community
Supported Documentation at
https://support.ntp.org/bin/view/Support/KnownHardwareIssues#Section_9.1.6.

-- 
Steve Kostecke 
NTP Public Services Project - http://support.ntp.org/

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

Re: [ntp:questions] NTP not syncing

[Harlan Stenn]

Running ntpdate every hour instead of running ntpd won't work if there
are database servers or dovecot or other apps that require monotonic
time.

But if the system clock is always running slow this *probably* won't be
an issue, and it also again points to lost clock interrupts.  Better to
solve the underlying problem.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

On 04/11/2013 18:49, Charles Swiger wrote:

Hi--

On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli  wrote:

Would it be wiser to delete the drift file at boot - by script - and let ntpd 
resync and recreate a new drift file?


Normally, no.

The drift file lets ntpd perform a first-order correction of the average 
intrinsic drift of the local clock even if ntpd can't get time from any other 
sources.  However, if the drift can't be computed correctly because of some 
unusual problem-- and a systemic drift of over 500ppm is fairly unusual-- then 
deleting the drift file might help.


Understood. I'll do some tests to find out whether with a better 
configuration the drift file still gets stuck to 500. In that case I'll 
have it deleted at each startup to see if things improve



As mentioned, I don't really need my system to be synced down to the 
millisecond, if ntpd takes a few hours to settle and the time is off up to a 
few seconds during that time it's perfectly fine with me.


Gracious.  In that case, run ntpdate via cron every hour or so and you'll 
probably stay within that tolerance even if ntpd itself can't manage to stay in 
sync.  However, if switching your system's clock source from whatever you are 
using now to HPET, ACPI, etc improves matters so that ntpd remains stable, that 
would obviously provide much better timekeeping.


That is being considered. The server runs a maintenance procedure every 
24hours when all the services are stopped momentarily. It could be the 
right time for an ntpdate to run.


Thanks
Antonio

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

Re: [ntp:questions] NTP not syncing

[Charles Swiger]

Hi--

On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli  wrote:
> Would it be wiser to delete the drift file at boot - by script - and let ntpd 
> resync and recreate a new drift file?

Normally, no.

The drift file lets ntpd perform a first-order correction of the average 
intrinsic drift of the local clock even if ntpd can't get time from any other 
sources.  However, if the drift can't be computed correctly because of some 
unusual problem-- and a systemic drift of over 500ppm is fairly unusual-- then 
deleting the drift file might help.

> As mentioned, I don't really need my system to be synced down to the 
> millisecond, if ntpd takes a few hours to settle and the time is off up to a 
> few seconds during that time it's perfectly fine with me.

Gracious.  In that case, run ntpdate via cron every hour or so and you'll 
probably stay within that tolerance even if ntpd itself can't manage to stay in 
sync.  However, if switching your system's clock source from whatever you are 
using now to HPET, ACPI, etc improves matters so that ntpd remains stable, that 
would obviously provide much better timekeeping.

Regards,
-- 
-Chuck

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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

If the oscillator drifts from last drift-file write, outside of +/- 15
ppm if I recall it, it fails to lock in again.
It would be good if it could bail out and do normal frequency
acquisition if that occurs.

That particular "feature" have bitten hard, and was a side-consequence
of other faults, but none-the-less.


Thanks Magnus, I saw the bug report you filed.

Would it be wiser to delete the drift file at boot - by script - and let 
ntpd resync and recreate a new drift file?


As mentioned, I don't really need my system to be synced down to the 
millisecond, if ntpd takes a few hours to settle and the time is off up 
to a few seconds during that time it's perfectly fine with me.


Thanks
Antonio

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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

Today drift is 60 and offsets are around 8. Looks good.


You know what's good?

from: ntp3.lordynet.org NetBSD-6.1, i386, ntpd 4.2.6p5:
$ cat /var/db/ntp/ntpd.drift
-9.722

from ntpq -crv
offset=-0.061

Your ntpd 4.2.4 is from 2008 through 2009 and offsets with
that version might not have been much worse than from 4.2.6p5
but correction of drift above 50 ppm was not good or even
impossible. Ntpd 4.2.6p5 also converges to a reasonable low
offset much faster after ntpd is restarted. I have an idea
that ntpd 4.2.8 is very near to release.


That's great to know, thanks.
I will speak with the manufacturer and see if a newer version can be 
adopted. It's good to know that it may well be a limitation of the NTP 
version being used.


Today I've been told that on newer machines I can enable the HPET (high 
precision event time) in the BIOS if available and that should give a 
better clock to begin with.



Your problem may not be with the setup of ntpd and you really
need to know what cpu optimisations, if any, are enabled. Some
optimisations for energy consumption are incompatible with
running an ntpd service. I can't help you with bios settings
or diagnostics for your motherboard settings. You might find
some information in dmesg but again that requires familiarity
with your hardware.


I will check the CPU optimisation as soon as I'm in front of one of 
these servers.


Thanks for your help David

Antonio

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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

4.2.4 is way way old.  (ntp releases are infrequent to begin with and
the current version is 4.2.6 and that is already quite old.)

Besides, the problem went away when you deleted the drift file and
restarted ntpd.  So I'd say that was likely to be your problem.


Looks like the general consensus is that the NTP version I am using is 
likely to be a major cause of trouble.

That helps a lot, would explain quite a lot of random issues I've seen.

Thanks guys, you've been great, your help is greatly appreciated!

Antonio

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

Re: [ntp:questions] NTP not syncing

[Magnus Danielson]

On 11/03/2013 06:26 PM, Magnus Danielson wrote:
> On 11/03/2013 12:43 AM, David Woolley wrote:
>> On 02/11/13 21:48, David Lord wrote:
>>
>>> Ntpd writes to its drift file and also ntp.log. The drift file
>>> is critical and is used and updated at intervals by ntpd.
>>>
>> The drift file is an optimisation.  ntpd should work without it, but
>> will take longer to acquire lock after a restart.
>>
>> What would cause more problems would be a drift file that was present,
>> but read-only, as ntpd would skip its frequency calibration and trust
>> the frozen value in that file, then suffer wild swings as it begins to
>> discover the value was wildly wrong.
> If the oscillator drifts from last drift-file write, outside of +/- 15
> ppm if I recall it, it fails to lock in again.
> It would be good if it could bail out and do normal frequency
> acquisition if that occurs.
>
> That particular "feature" have bitten hard, and was a side-consequence
> of other faults, but none-the-less.
By request from Harlan, I put this into a bug-report:
http://bugs.ntp.org/show_bug.cgi?id=2500

Hope it was clear enough.

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

Re: [ntp:questions] NTP not syncing

[David Lord]

Antonio Marcheselli wrote:

Same server, same network, what happened??


Ntpd is intended to run continuously, here I've seen uptimes
of +200 days. Older releases of ntpd don't behave at all well
if repeatedly restarted so above method is same as I use when
restarting after an outage, especially if the battery backed
RTC is not keeping good time during the outage.


The clock is synced to an NTP server at boot using NTPDATE, before ntpd 
starts.


Today drift is 60 and offsets are around 8. Looks good.


You know what's good?

from: ntp3.lordynet.org NetBSD-6.1, i386, ntpd 4.2.6p5:
$ cat /var/db/ntp/ntpd.drift
-9.722

from ntpq -crv
offset=-0.061

Your ntpd 4.2.4 is from 2008 through 2009 and offsets with
that version might not have been much worse than from 4.2.6p5
but correction of drift above 50 ppm was not good or even
impossible. Ntpd 4.2.6p5 also converges to a reasonable low
offset much faster after ntpd is restarted. I have an idea
that ntpd 4.2.8 is very near to release.

Your problem may not be with the setup of ntpd and you really
need to know what cpu optimisations, if any, are enabled. Some
optimisations for energy consumption are incompatible with
running an ntpd service. I can't help you with bios settings
or diagnostics for your motherboard settings. You might find
some information in dmesg but again that requires familiarity
with your hardware.


David



Thanks
Antonio


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

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

On 03/11/2013 22:30, Harlan Stenn wrote:

Antonio Marcheselli writes:

Interesting. My ntpd version is 4.2.4p4
Do you reckon it could be my case?


Verey possibly so.  4.2.4 was EOL'd in December of 2009, when 4.2.6 was
released.  As soon as we can fix some IPv6 and broadcast/multicast bugs,
4.2.8 will be released, and at that time 4.2.6 will be EOL'd.



Thanks Harlan. I'll try and do some more tests.

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

Re: [ntp:questions] NTP not syncing

[Harlan Stenn]

Antonio Marcheselli writes:
> Interesting. My ntpd version is 4.2.4p4
> Do you reckon it could be my case?

Verey possibly so.  4.2.4 was EOL'd in December of 2009, when 4.2.6 was
released.  As soon as we can fix some IPv6 and broadcast/multicast bugs,
4.2.8 will be released, and at that time 4.2.6 will be EOL'd.

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP not syncing

[Antonio Marcheselli]

What would cause more problems would be a drift file that was present,
but read-only, as ntpd would skip its frequency calibration and trust
the frozen value in that file, then suffer wild swings as it begins to
discover the value was wildly wrong.


No worries, the RO partition is only for storing some scripts, ntp.drift 
is NOT on read only partition and it's NOT amended by anything but ntpd.






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