[ntp:questions] Offset is always increasing

Riccardo Castellani ric.castellani at alice.it
Thu May 23 17:49:32 UTC 2013


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



----- Original Message ----- 
From: "unruh" <unruh at invalid.ca>
Newsgroups: comp.protocols.time.ntp
To: <questions at lists.ntp.org>
Sent: Thursday, May 23, 2013 5:25 PM
Subject: Re: [ntp:questions] Offset is always increasing


> On 2013-05-23, Riccardo Castellani <ric.castellani at 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.
>
>
>>
>>
>>
>> ----- Original Message ----- 
>> From: "David Woolley" <david at ex.djwhome.demon.invalid>
>> Newsgroups: comp.protocols.time.ntp
>> To: <questions at lists.ntp.org>
>> Sent: Wednesday, May 22, 2013 10:50 PM
>> Subject: Re: Offset is always increasing
>>
>>
>>> 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.
>>>>
>>>>
>>>
>>> _______________________________________________
>>> questions mailing list
>>> questions at lists.ntp.org
>>> http://lists.ntp.org/listinfo/questions
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions 



More information about the questions mailing list