Offset is always increasing

[Riccardo Castellani]

I'm using n. 1 ntp server (XNTPD daemon on HP-UX, called FORCLIENTS,

192.168.1.240) for my clients and I'm obtaining the message
"synchronization
lost" about every 20 minutes.
Source time is another server (MASTER) on my lan
which updates its time
directly from Internet servers.


MASTER is OK

FORCLIENTS has a high offset !


ntp.conf of FORCLIENTS (192.168.1.240):


restrict default ignore
server 10.2.3.5
driftfile /etc/ntp.drift
restrict
127.0.0.1
restrict 127.127.1.1
restrict 10.2.3.5
restrict 192.168.1.240

restrict 192.168.0.0 mask 255.255.0.0 nomodify noquery
server 127.127.1.1
fudge
127.127.1.1 stratum 10 # show poor quality



ntp.conf of MASTER (10.2.3.5):


restrict default ignore
restrict 127.0.0.1
restrict 192.168.1.240 mask
255.255.255.255 nomodify
restrict ntp1.inrim.it mask 255.255.255.255 nomodify
noquery notrap nopeer
restrict ntp2.inrim.it mask 255.255.255.255 nomodify
noquery notrap nopeer
restrict ntp1.fau.de mask 255.255.255.255 nomodify
noquery notrap nopeer
restrict ntp2.nl.net mask 255.255.255.255 nomodify
noquery notrap nopeer
restrict 127.127.1.0 mask 255.255.255.255
server ntp1.
inrim.it
server ntp2.inrim.it
server ntp1.fau.de
server ntp2.nl.net
server
127.127.1.0
fudge 127.127.1.0
driftfile /var/lib/ntp/drift







My server log
shows:


20 May 14:38:20 xntpd[19386]: synchronized to LOCAL(1), stratum=10
20
May 14:39:23 xntpd[19386]: synchronized to 10.2.3.5, stratum=2
20 May 14:54:18
xntpd[19386]: time reset (step) -1.014343 s
20 May 14:54:18 xntpd[19386]:
synchronisation lost
20 May 14:58:35 xntpd[19386]: synchronized to LOCAL(1),
stratum=10
20 May 14:59:38 xntpd[19386]: synchronized to 10.2.3.5, stratum=2
20
May 15:14:33 xntpd[19386]: time reset (step) -1.010761 s
20 May 15:14:33 xntpd
[19386]: synchronisation lost
20 May 15:16:08 xntpd[13208]: logging to file
/var/adm/syslog/ntp.log
20 May 15:16:08 xntpd[13208]: tickadj = 625, tick =
10000, tvu_maxslew =
61875
20 May 15:16:08 xntpd[13208]: precision = 6 usec
20
May 15:17:29 xntpd[14031]: logging to file /var/adm/syslog/ntp.log
20 May 15:17:
29 xntpd[14031]: tickadj = 625, tick = 10000, tvu_maxslew =
61875
20 May 15:17:
29 xntpd[14031]: precision = 10 usec
20 May 15:21:46 xntpd[14031]: synchronized
to 10.2.3.5, stratum=2
20 May 15:21:46 xntpd[14031]: time reset (step)
-0.216182 s
20 May 15:21:46 xntpd[14031]: synchronisation lost
20 May 15:26:03
xntpd[14031]: synchronized to LOCAL(1), stratum=10
20 May 15:27:06 xntpd
[14031]: synchronized to 10.2.3.5, stratum=2
20 May 15:42:01 xntpd[14031]: time
reset (step) -1.005840 s
20 May 15:42:01 xntpd[14031]: synchronisation lost
20
May 15:46:18 xntpd[14031]: synchronized to LOCAL(1), stratum=10
20 May 15:47:21
xntpd[14031]: synchronized to 10.2.3.5, stratum=2
20 May 16:02:16 xntpd[14031]:
time reset (step) -1.009925 s
20 May 16:02:16 xntpd[14031]: synchronisation
lost
20 May 16:06:33 xntpd[14031]: synchronized to LOCAL(1), stratum=10
20 May
16:07:36 xntpd[14031]: synchronized to 10.2.3.5, stratum=2



nptd -qn shows:




remote refid st t when poll reach delay offset
disp

============================================================================
==

10.2.3.5 193.204.114.232 2 u 16 64 7 1.92 -158.96 3927.72
127.127.1.1
127.127.1.1 10 l 15 64 17 0.00 0.000
1885.01



My time source server is ok
(10.2.3.5) and I can exclude problems into my
lan.



remote local st poll
reach delay offset disp

=======================================================================
=ntp1.
nl.uu.net 10.2.3.5 1 1024 377 0.04411 -0.003625 0.12183
=ntp1.inrim.it 10.2.3.5
1 1024 377 0.01971 -0.000409 0.12172
*ntp2.inrim.it 10.2.3.5 1 1024 377 0.01923
-0.000046 0.12175
=LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03072
=ntp1.
rrze.uni-e 10.2.3.5 1 1024 377 0.05191 -0.009084 0.12178





Can you indicate
suggestions please ? The problem is Offset bigger 128 ms
?!?! Offset is
increasing until to 700-800 ms.

I run ntpdate to update immediately clock and
I can see small offset but
after few minutes grows again until to exceed 128
ms.

How can I solve it ?

[Mischanko, Edward T]

Why are you doing this?

restrict 10.2.3.5

This is the server you want your clients to sync to, isn't it?

Regards,
Ed

> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

[Brian Utterback]

FORCLIENTS clock has a huge frequency problem, way beyond what NTP can
correct.

Do this. Disable NTP on FORCLIENTS, then run ntpdate every minute (cron
would be good here) with "-q" and "-s". You will probably see an
increasing offset. Check to see if it is monotonically increasing. If it
occasionally resets or goes backward, then you probably have resync to
TOD chip and that may be part of the problem. Otherwise, take the offset
at the end and subtract the offset at the beginning then divide by the
time between the start and the end. That will give you the drift rate.
If that rate is larger than 500 parts per million, then NTP cannot
correct the clock.

> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

--
blu

Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
-----------------------------------------------------------------------|
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.u...@oracle.com

[Brian Utterback]

In an amazingly counter-intuitive manner, a restrict keyword with just
an IP address means that the IP address should have no restrictions. It
is therefore very common to see a line like:

restrict default ignore

Which says to ignore all packets from everywhere, and then to see a
series of lines like

restrict IP1
restrict IP2
etc.

which removes all restrictions from those hosts.

[Riccardo Castellani]

Yes this is the server (192.168.1.140) which my clients will use.
I want to allow "unrestricted access" by 10.2.3.5 host (my private 'source
time server' ), because Server 10.2.3.5 will drive my server (192.168.1.140)
Do you think it's unnecessary option ?



NTP documents says:

1- Add the following line to allow unrestricted access by a specific host
(e.g. the sysadmin's workstation):
IPv4: restrict w.x.y.z

2- restrict numeric_address [mask numeric_mask] [flag ...]
The numeric_address argument, expressed in dotted-quad form, is the address
of a host or network. The mask, also expressed in dotted-quad form,
defaults to 255.255.255.255, meaning that the numeric_address is treated as
the address of an individual host.
A default entry (address 0.0.0.0, mask 0.0.0.0) is always included and,
given the sort algorithm, is always the first entry in the list.
Note that, while numeric_address is normally given in dotted-quad format,
the text string `default', with no mask option, may be used to indicate the
default entry. In the current implementation, flag always restricts access,
i.e., AN ENTRY WITH NO FLAGS INDICATES THAT FREE ACCESS TO THE SERVER IS TO
BE GIVEN. ....

[Riccardo Castellani]

thanks, you act before myself !

[David Woolley]

Riccardo Castellani wrote:

> server 127.127.1.1
> fudge
> 127.127.1.1 stratum 10 # show poor quality

Remove these until you get it working, and then only re-add them if the
system is serving time to downstream systems and you really understand
why you are using them. Leaf systems never need it and most
intermediate ones don't. It can sometimes cause problems on the server
on which is configured.

>
> 20 May 14:38:20 xntpd[19386]: synchronized to LOCAL(1), stratum=10
> 20

What version of ntpd are you using. Some vendors failed to track the
renaming back to ntpd, but, otherwise, you have an extremely obsolete
version.

>
> How can I solve it ?

If the offset smoothly ramps up, you have a broken clock. If it
suddenly jumps, especially if there is fixed interval between jumps, you
have something else trying to discipline the clock, usually a cron job
that copies the time from the RTC.

[Riccardo Castellani]

>>Remove these until you get it working, and then only re-add them if the
>>system is serving time to downstream systems and you really understand why
>>you are using them. Leaf systems never need it and most intermediate ones
>>don't.
>> It can sometimes cause problems on the server on which is configured.

Doy you think these 3 rows can create problems ?
Server will give time to my clients and I'd like clients continue to sync to
this server even if master source clock is unavailable, these 3 rows permit
this behaviour.
Why you syas: " Leaf systems never need it and most intermediate ones don't
" .... I' don't understand.

> What version of ntpd are you using. Some vendors failed to track the
> renaming back to ntpd, but, otherwise,
>> you have an extremely obsolete version

My xntpd daemon is version 3, as defined by RFC-1305 but also retains
compatibility with version 1 and 2 servers as defined by RFC-1059 and
RFC-1119, respectively.
OS is HP-UX B.11.31 U ia64

>> If the offset smoothly ramps up, you have a broken clock. If it suddenly
>> jumps, especially if there is fixed interval between jumps, >> you have
>> something else trying to discipline the clock, usually a cron job that
>> copies the time from the RTC.

I can see usually offset increases until 700 or 800 and it keeps this value,
log shows every 20 minute 'synchronisation lost' while drift value is about
855. Problem could be "local clock high frequeny", what do you think ?!
What means 'a cron job that copies the time from the RTC' ? I tested other 2
identical servers and behaviour is the same, it's very strange broken clock
for 3 servers.... I think.


thanks

----- Original Message -----
From: "David Woolley" <da...@ex.djwhome.demon.invalid>
Newsgroups: comp.protocols.time.ntp
To: <ques...@lists.ntp.org>
Sent: Tuesday, May 21, 2013 10:52 PM
Subject: Re: Offset is always increasing

[Riccardo Castellani]

I thank you very much for your precious answer but I'm very happy to know my
configuration is good ;)

>> Do this. Disable NTP on FORCLIENTS, then run ntpdate every minute (cron
>> would be good here) with "-q" and "-s". You will probably see an
>> increasing offset.

With this command, I will save 'offset' value but without adjusting the
local clock, it's right ?

>>Check to see if it is monotonically increasing. If it occasionally resets
>>or goes backward, then you probably have resync to TOD chip and that may
>>be part of the problem.

What means to resync TOD chip ?! To replace hardware clock ?! How is it
possible to resync !? In HP-UX I know 'date' command sets both the hardware
clock and the system clock.
My hardware is blade HP BL860c with 2 CPU, where each one is DualCore Intel
Itanium 2 - 1666 MHz.

>> Otherwise, take the offset at the end and subtract the offset at the
>> beginning then divide by the time between the start and the end. That
>> will give you the drift rate.

This one represents the average of drift rate about my hardware clock ? It's
all right ?
How long this cron task do you suggest to run to be meaningful ? 30 minutes
?

>>> If that rate is larger than 500 parts per million, then NTP cannot
>>> correct the clock.

Acoording test you suggested me by 'ntpdate', if this drift average is
bigger 500 ppm ... ntpd cannot adjust local clock, where can I find
documents to find out reason ?
I don't know if it's can be useful but now 'drift rate' value, which ntpd
saves automatically in its file, is about 855 !
My local clock overstepped 10 minutes forward, I don't understand because
clock was not adjusted step by step without to collect over 10 minutes !
How do you know where I can find info about it ?

thanks again

----- Original Message -----
From: "Brian Utterback" <brian.u...@oracle.com>
To: <ques...@lists.ntp.org>
Sent: Tuesday, May 21, 2013 3:02 PM
Subject: Re: Offset is always increasing

[Harlan Stenn]

Riccardo,

I have not read many of the threads here.

I recommend you have your tier 1 and tier 2 machines talk to each other
and to a useful number of outside servers if at all possible. It is also
inexpensive and useful to get a local GPS receiver.

There is no reason I can see to use old versions of ntpd. ntp-dev works
just fine with recent HP-UX and I would recommend using that instead of
anything older.

H

[Steve Kostecke]

On 2013-05-22, Riccardo Castellani <ric.cas...@alice.it> wrote:

>> ATTRIBUTION MISSING said:
>>
>>> Do this. Disable NTP on FORCLIENTS, then run ntpdate every minute
>>> (cron would be good here) with "-q" and "-s". You will probably see
>>> an increasing offset.
>
> With this command, I will save 'offset' value but without adjusting
> the local clock, it's right ?

In cases where your clock is drifting faster than NTP can correct it you
may need to "adjust your tick". This procedure has been documented in
our Wiki since 2005:

https://support.ntp.org/bin/view/Support/KnownHardwareIssues#Section_9.1.6.


--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/

[Rob]

Did you wait a day after making changes?
In my experience, the "offset is increasing, time is wandering AWAY
from correct time" phenomenon often occurs when you have been tinkering
with the config file and have stopped and started ntpd many times in
succession.
It will only stabilize when you don't mess with it for several hours
after your last restart.

[Riccardo Castellani]

I tested 3 identical server with the same hardware, after one day offset is
the same value.
I have to reset drift file ? Now is 855.

----- Original Message -----
From: "Rob" <nom...@example.com>
Newsgroups: comp.protocols.time.ntp
To: <ques...@lists.ntp.org>

Sent: Wednesday, May 22, 2013 6:15 PM
Subject: Re: Offset is always increasing

[Rob]

Riccardo Castellani <ric.cas...@alice.it> wrote:
> I tested 3 identical server with the same hardware, after one day offset is
> the same value.
> I have to reset drift file ? Now is 855.

That is not good. It typically is below 100 (absolute value).

I would try to stop ntpd, put 0 in the drift file, and start it again.

But it may not help. Maybe your clock accuracy *is* terrible.

[Harlan Stenn]

"Riccardo Castellani" writes:
> I tested 3 identical server with the same hardware, after one day offset is
> the same value.
> I have to reset drift file ? Now is 855.

Steve Kostecke already pointed you at one resource, and I'll point you
at scripts/hpadjtime.sh (not sure what it is for, but it may be of some
help in getting your problem solved) and scripts/calc_tickadj .

I've already mentioned that you probably want to be running a much more
recent version of ntpd than the V3 code.

H

[David Woolley]

Riccardo Castellani wrote:
>>> Remove these until you get it working, and then only re-add them if the
>>> system is serving time to downstream systems and you really
>>> understand why
>>> you are using them. Leaf systems never need it and most intermediate
>>> ones
>>> don't.
>>> It can sometimes cause problems on the server on which is configured.
> Doy you think these 3 rows can create problems ?

There are some cases where the local clock appears to be able to outvote
external servers when those servers give a significantly different time.

> Server will give time to my clients and I'd like clients continue to
> sync to
> this server even if master source clock is unavailable, these 3 rows permit
> this behaviour.

There are some cases where this may be valid, but if the server is
drifting badly, it would be better to let them free run, with the last
correction value. The big disadvantage when service other systems is
that they never get to know that the upstream time source has failed.

In any case, current versions will take around a day before they give up
on the uptream server.

> Why you syas: " Leaf systems never need it and most intermediate ones don't
> " .... I' don't understand.

Leaf systems (ones that don't serve anything else) will free run when
they loose all sources, using the last frequency correction. Defining
the local clock will not change that. Non-leaf systems will free and
won't diverge greatly for a significant amount of time. They will know
that they are free running.

>
>> What version of ntpd are you using. Some vendors failed to track the
>> renaming back to ntpd, but, otherwise,
>>> you have an extremely obsolete version
> My xntpd daemon is version 3, as defined by RFC-1305 but also retains
> compatibility with version 1 and 2 servers as defined by RFC-1059 and
> RFC-1119, respectively.

Obsolete. Version 4 has been current for many years now.

> OS is HP-UX B.11.31 U ia64

I am pretty sure that version 4 pre-dates ia64. There is no good reason
for running anything else on ia64 (even if w32time is version 3!)

>
>>> If the offset smoothly ramps up, you have a broken clock. If it
>>> suddenly
>>> jumps, especially if there is fixed interval between jumps, >> you have
>>> something else trying to discipline the clock, usually a cron job that
>>> copies the time from the RTC.
> I can see usually offset increases until 700 or 800 and it keeps this
> value,

Please explain "keeps this value".

> log shows every 20 minute 'synchronisation lost' while drift value is about
> 855. Problem could be "local clock high frequeny", what do you think ?!
> What means 'a cron job that copies the time from the RTC' ? I tested

"cron job" has the normal Unix meaning.

On some Unix system, e.g, SunOS 4, and at least some versions of SCO
Open Server, the system periodically copies the value in the "CMOS" real
time clock, to the software maintained clock use by the OS. This could
be a cron job, it could be a user space daemon, or it could be a
function in the kernel itself.

This normally results in the time tracking the server relatively
accurately for some time, then suddenly jumping to a different time,
which differs from the server time by about the same amount each time.

> other 2
> identical servers and behaviour is the same, it's very strange broken clock
> for 3 servers.... I think.

That suggests a software bug, in the OS, or a configuration problem.
>
>

[Rick Jones]

Harlan Stenn <st...@ntp.org> wrote:
> There is no reason I can see to use old versions of ntpd. ntp-dev
> works just fine with recent HP-UX and I would recommend using that
> instead of anything older.

Likely as not, that is probably what HP still ships with HP-UX and
"supports," though I've not checked in quite some time. If the OP is
on a support contract, running the ntp-dev code means he will not be
able to get Response Center support for NTP. Of course, I suspect
that if he did have a support contract, he would have already gone to
the Response Center :)

If the OP *does* have a support contract, if nothing else, exercising
it to request that HP update the ntp in HP-UX would be worthwhile.

rick jones
--
"You can't do a damn thing in this house without having to do three
other things first!" - my father (It seems universally applicable :)
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[Riccardo Castellani]

>>>>> I can see usually offset increases until 700 or 800 and it keeps this
>>>>> value,

It keeps this value means it's stable for many months, it's doesnt change

----- Original Message -----
From: "David Woolley" <da...@ex.djwhome.demon.invalid>
Newsgroups: comp.protocols.time.ntp
To: <ques...@lists.ntp.org>
Sent: Wednesday, May 22, 2013 10:50 PM
Subject: Re: Offset is always increasing

[Harlan Stenn]

"Riccardo Castellani" writes:
> >>>>> I can see usually offset increases until 700 or 800 and it keeps this
> >>>>> value,
>
> It keeps this value means it's stable for many months, it's doesnt change

That's kinda good that it doesn't change, and NTP is designed to handle
500PPM of drift. That value was at least 2x the worst clock normally
seen.

So if you can look at the tickadj program and calc_tickadj, you might be
able to adjust the system clock to be moch more stable. Ideally the
drift value should be the smallest possible positive number, and that's
what calc_tickadj tries to do.

H

[David Woolley]

Riccardo Castellani wrote:
>>>>>> I can see usually offset increases until 700 or 800 and it keeps
>>>>>> this value,
>
> It keeps this value means it's stable for many months, it's doesnt change
>

I thought you said xntpd reset it about every 20 minutes. How can it
then have been stable for several months?

(If ntpd weren't correcting it, but only measuring it, I would suspect
that you had some other time discipline software that was doing a slow
adjustment to the clock and which thought the time was 700 to 800ms out.)

[Riccardo Castellani]

You thought right, xntpd says "synchronisation lost" every 20 minutes, drift
file is about 855, xntpd daemon is running from about 1 year.
In these days I
made several days and I restarted daemon and I waited a day to analyze offset.

When I says "stable" I'm refering to value into drift file because I see always
the same value, that is about 855.

Do you suggest me to measure specific drift
of my hardware clock by script as documented into ntp.org, Known Hardware
Issues, 9.1.6 (Mac Mini and other machines having poor TICK settings) ?
I test
identical server (which has same problems) I delete the drift file and I
restart daemon, after 2 hours :


ntpq -pn

remote refid st
t when poll reach delay offset disp

==============================================================================

*10.2.3.5 193.204.114.233 2 u 9 64 377 0.61 -0.350 0.11

127.127.1.1 127.127.1.1 10 l 8 64 377 0.00 0.000 10.01


I'm worried because after many months I wouldn't like to find the same
behaviour.
I have no other software to discipline time.

[Riccardo Castellani]

What do you think if I set drift file to '0' value ?
Do you think this ntp
behaviour happens again ?

I'm able not to understand if my problem is hardware
clock frequency which ntp cannot deal !

"Riccardo Castellani" writes:
> I
can see usually offset increases until 700 or 800 and it keeps this value,
>
>
It keeps this value means it's stable for many months, it's doesnt change

[unruh]

On 2013-05-23, Riccardo Castellani <ric.cas...@alice.it> wrote:
>>>>>> I can see usually offset increases until 700 or 800 and it keeps this
>>>>>> value,
>
> It keeps this value means it's stable for many months, it's doesnt change

800 what? if the offset is greater that 125 ms, ntpd will step.

And you talk about offset of 800 and then drift of 835. Which is it?
ntpd cannot drift faster than 500PPM, so 800 or so is not possible if
that means ppm.
Units are extremely important in conveying information.

[David Lord]

Riccardo Castellani wrote:
> You thought right, xntpd says "synchronisation lost" every 20 minutes, drift
> file is about 855, xntpd daemon is running from about 1 year.
> In these days I
> made several days and I restarted daemon and I waited a day to analyze offset.
>
> When I says "stable" I'm refering to value into drift file because I see always
> the same value, that is about 855.
>
> Do you suggest me to measure specific drift
> of my hardware clock by script as documented into ntp.org, Known Hardware
> Issues, 9.1.6 (Mac Mini and other machines having poor TICK settings) ?
> I test
> identical server (which has same problems) I delete the drift file and I
> restart daemon, after 2 hours :
>
>
> ntpq -pn
>
> remote refid st
> t when poll reach delay offset disp
>
> ==============================================================================
>
> *10.2.3.5 193.204.114.233 2 u 9 64 377 0.61 -0.350 0.11
>
> 127.127.1.1 127.127.1.1 10 l 8 64 377 0.00 0.000 10.01
>

My guess is that your problem is because you have only two
sources, one that has offset 0 ms but stratum 10 and a second
with an offset that can increase because ntpd can't discard
the value from the local clock but will discard the stratum 1
source when its offset is large.

Are you able to use one or preferably more good time sources,
ntp, gps or radio?


David

[Riccardo Castellani]

Excuse me for lack of precision, I'll try to be more thorough.
I have 3 servers HP blade BL860c (n.2 CPU, DualCore Intel Itanium 2 - 1666
MHz) with HP-UX B.11.31 U ia64
I brought into focus only one server but problem is about all three servers.
My xntpd daemon is running from about 1 year and only this week I found
problems about clients time, I verified value of drift file which now is
855 (on all 3 servers) ; I'm not able to say about ntpd behaviour before one
week ago.
In these days when I run 'ntpq -pn' command more times on 3 all server, I
got the offset value between from 700 to 800.

This afternoon I set value of drift file to zero and I restart xntpd on 3
all servers, now I can see:

file drift valure server1: -6.206
file drift valure server2: -13.030
file drift valure server3: 10.385

npqd -pn

server1:

remote refid st t when poll reach delay offset
disp

==============================================================================
*10.2.3.5 193.204.114.233 2 u 40 64 377 0.37 -0.787
0.37
127.127.1.1 127.127.1.1 10 l 39 64 377 0.00 0.000
10.01

server2:

remote refid st t when poll reach delay offset
disp

==============================================================================
*10.2.3.5 193.204.114.233 2 u 53 64 377 0.41 -0.681
0.34
LOCAL(1) LOCAL(1) 10 l 52 64 377 0.00 0.000
10.01

server3:

remote refid st t when poll reach delay offset
disp

==============================================================================
*10.2.3.5 193.204.114.233 2 u 44 64 377 0.41 -0.674
0.38
LOCAL(1) LOCAL(1) 10 l 43 64 377 0.00 0.000
10.01


Now it likes right but I cannot understand what happens and espacially if it
will occur again.

Thank you for your patience

[Rob]

Please remove the 127.127.1.1 server line. It only causes confusion
and trouble.

[Riccardo Castellani]

My thought this NTP architecture :
- n.1 server Linux (both on public and on private network) and It contains
n. 4 NTP servers having stratum 1. This server gives time only to following
servers:
- n.3 server blade HP-UX where each server points to NTP server Linux. These
3 servers give time to clients

Client configuration contains always these 3 servers so I have redundance;
I'd like to avoid to present my 3 servers directly on public network because
they host db and other services.
My Linux server has no problems and its time clock is all right.

> ----- Original Message -----
> From: "David Lord" <sn...@lordynet.org>
> Newsgroups: comp.protocols.time.ntp
> To: <ques...@lists.ntp.org>

[Riccardo Castellani]

Ok, but I want to remove all 3 following lines from my HP-UX server ?

server 127.127.1.0
fudge 127.127.1.0
restrict 127.127.1.0 mask 255.255.255.255

----- Original Message -----
From: "Rob" <nom...@example.com>
Newsgroups: comp.protocols.time.ntp
To: <ques...@lists.ntp.org>
Sent: Thursday, May 23, 2013 8:20 PM
Subject: Re: Offset is always increasing

> Please remove the 127.127.1.1 server line. It only causes confusion
> and trouble.
>

[Rob]

Riccardo Castellani <ric.cas...@alice.it> wrote:
> Ok, but I want to remove all 3 following lines from my HP-UX server ?
>
> server 127.127.1.0
> fudge 127.127.1.0
> restrict 127.127.1.0 mask 255.255.255.255

Yes. Never put those lines in any ntp config outside of some test
environment in a lab.
(unfortunately many manufacturers put those lines in example configs)

[unruh]

On 2013-05-23, Riccardo Castellani <ric.cas...@alice.it> wrote:

> You thought right, xntpd says "synchronisation lost" every 20 minutes, drift
> file is about 855, xntpd daemon is running from about 1 year.
> In these days I
> made several days and I restarted daemon and I waited a day to analyze offset.
>
> When I says "stable" I'm refering to value into drift file because I see always
> the same value, that is about 855.

ntpd probably never touches it. What is the time on the file
ls -lga <driftfile>

>
> Do you suggest me to measure specific drift
> of my hardware clock by script as documented into ntp.org, Known Hardware
> Issues, 9.1.6 (Mac Mini and other machines having poor TICK settings) ?
> I test
> identical server (which has same problems) I delete the drift file and I
> restart daemon, after 2 hours :

You can tell almost nothing in 2 hrs.
Did you see me suggesting that you plot the stuff from your log files?

Look at /var/log/ntp/loopstats and peerstats.
from the forvmer get the drift correction. From the latter the offsets
Plot them to see what is happening. History is important, despite the
design philosophy of ntpd.

[David Woolley]

unruh wrote:

> And you talk about offset of 800 and then drift of 835. Which is it?
> ntpd cannot drift faster than 500PPM, so 800 or so is not possible if
> that means ppm.

I don't think the 500ppm limit existed on some of the older versions of
nptd. I'm not sure it it came in with version 3 or version 4. Before
that the OS tickadj rate determined the limit.

[Riccardo Castellani]

OK I'll do it immediately...
I also have to remove these lines from my Linux server (10.2.3.? 5) It's
both on internal and external network and It represents ntp source for my
hp-ux server.

----- Original Message -----
From: "Rob" <nom...@example.com>
Newsgroups: comp.protocols.time.ntp
To: <ques...@lists.ntp.org>
Sent: Thursday, May 23, 2013 9:44 PM
Subject: Re: Offset is always increasing

[Riccardo Castellani]

> ntpd probably never touches it. What is the time on the file ls -lga
> <driftfile>

I think it's impossible, yesterday I reset file content.

> Did you see me suggesting that you plot the stuff from your log files?
> Look at /var/log/ntp/loopstats and peerstats.
> from the forvmer get the drift correction. From the latter the offsets
> Plot them to see what is happening. History is important, despite the
> design philosophy of ntpd.

I'm using HP-UX so I cannot see /var/log/ntp/loopstats and peerstats,
I can see only log file which I defined into ntp.conf.
Does it exist tool which read log and plot it ?


What do you think to remove these 3 lines from all ntp servers how other ntp
technicians are suggesting me ?

server 127.127.1.0
fudge 127.127.1.0
restrict 127.127.1.0 mask 255.255.255.255

----- Original Message -----
From: "unruh" <un...@invalid.ca>
Newsgroups: comp.protocols.time.ntp
To: <ques...@lists.ntp.org>
Sent: Thursday, May 23, 2013 10:36 PM
Subject: Re: Offset is always increasing

[Mischanko, Edward T]

> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelorm...@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelorm...@lists.ntp.org] On Behalf Of
> Riccardo Castellani
> Sent: Thursday, May 23, 2013 11:03 PM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] Offset is always increasing
>

> > ntpd probably never touches it. What is the time on the file ls -lga
> > <driftfile>
> I think it's impossible, yesterday I reset file content.
>
> > Did you see me suggesting that you plot the stuff from your log files?
> > Look at /var/log/ntp/loopstats and peerstats.
> > from the forvmer get the drift correction. From the latter the offsets
> > Plot them to see what is happening. History is important, despite the
> > design philosophy of ntpd.
>
> I'm using HP-UX so I cannot see /var/log/ntp/loopstats and peerstats,
> I can see only log file which I defined into ntp.conf.
> Does it exist tool which read log and plot it ?
>
>

[Mischanko, Edward T]

Yes, Try removing these 3 lines or putting ## at the beginning of them for
testing. Ntpd ignores lines in the configuration that begin with #.

[Rob]

Riccardo Castellani <ric.cas...@alice.it> wrote:
> OK I'll do it immediately...
> I also have to remove these lines from my Linux server (10.2.3.? 5) It's
> both on internal and external network and It represents ntp source for my
> hp-ux server.

I advise you to delete those lines on any system that you administer.
It is better to add some more external servers when you want to serve
reliable time, and/or to add a local clock receiver that receives
GPS or some longwave time transmission. The LOCAL clock implementation
in ntpd has some problems that make it very difficult to predict what
happens when things fail.

[unruh]

On 2013-05-24, Riccardo Castellani <ric.cas...@alice.it> wrote:
>> ntpd probably never touches it. What is the time on the file ls -lga
>> <driftfile>
> I think it's impossible, yesterday I reset file content.
>
>> Did you see me suggesting that you plot the stuff from your log files?
>> Look at /var/log/ntp/loopstats and peerstats.
>> from the forvmer get the drift correction. From the latter the offsets
>> Plot them to see what is happening. History is important, despite the
>> design philosophy of ntpd.
>
> I'm using HP-UX so I cannot see /var/log/ntp/loopstats and peerstats,
> I can see only log file which I defined into ntp.conf.

And which did you define in ntp.conf? why not define those?

> Does it exist tool which read log and plot it ?
>

Plotting data I leave to you. Sorry. I have my own tool but it would
mean you would have tto install and leavn super mongo, which is probably
not on.

>
> What do you think to remove these 3 lines from all ntp servers how other ntp
> technicians are suggesting me ?

O
DEFINITELY remove them.
They are lunatic.