[ntp:questions] Re: Ntp-4.1.2: tinker step 0; always slew andkernel time discipline

David L. Mills mills at udel.edu
Fri Feb 18 23:11:48 UTC 2005


Nikolaev,

The difference in outbound and inbound delays would have to be over 256 
ms for the indicated offset to be over 128 ms and that's a lot. If you 
have some confidence that the delays can be capped, tinker the step 
threshold to something higher, but don't set it to zero.

Dave

Nikolaev, Sergey wrote:

> Dave,
> 
> Not running NTP is not an option. At least on one type of Sun systems we
> had this problem where a system clock
> would jump 2 seconds. After long efforts of talking to Sun support, this
> explanation was given by Sun.
> The system has 2 clocks: TOD (hardware) and the system clock
> (hardware/software combination). 
> If the 2 clocks drift to 2 seconds apart, the system clock is set to the
> time of the TOD. 
> Actually, according to my tests, this correction is done over span of 30
> seconds at a rate of 70ms/s.
> This "jump" was freaking out one of our time sensitive applications.
> When the system clock is set by software (i.e. NTP), TOD is set too, so
> they are synced. So, if NTP is running,
> it adjusts the system clock relatively frequently, reseting both the
> system clock and TOD, so they never have 
> enough time to drift apart 2 seconds and NTP does not even need to react
> to the 2 second jump.
> 
> The only reason we are considering the option of always slewing is
> because we had the problem where NTP itself 
> would introduce a jump, step the clock, because of perceived ofset
> greater than 128ms due asymmetric network delays.
> Our applications usually disconnect clients in this case and this is
> bad.
> To avoid this we have been thinking about forcing NTP to always slew.
> But it looks like this approach has drawbacks too.
> 
> Regards,
> Sergey
> 
> 
> -----Original Message-----
> From: questions-bounces at lists.ntp.isc.org
> [mailto:questions-bounces at lists.ntp.isc.org] On Behalf Of David L. Mills
> Sent: Friday, February 18, 2005 10:29 AM
> To: questions at lists.ntp.isc.org
> Subject: Re: [ntp:questions] Re: Ntp-4.1.2: tinker step 0;always slew
> andkernel time discipline
> 
> 
> Nikolaev,
> 
> As I said in my response to your message in my inbox, all claims on 
> stability are cancelled in the configuration you selected. I am not 
> surprised that you see large overshoots, instability and incorrect 
> behavior. There are all kinds of reasons for this, including violations 
> of the expected Unix behavior, unexpected transients between the kernel 
> and daemon feedback loops and who knows what else. The engineered 
> parameters are not designed for your application. The best choice, as I 
> said in my reply to your message, is to forget ntpd altogether and use 
> your wristwatch. You will have to analyze each and every case on your
> own.
> 
> Dave
> 
> Nikolaev, Sergey wrote:
> 
> 
>>Dave,
>>
>>Thanks for your replies. Actually, I have just got data from my tests 
>>and this is what I am observing. If "tinker step 0" but the "kernel" 
>>is not disabled explicitly, a 20-second offset
>>(set manually via the date command) is corrected at a rate of about
> 
> 0.5
> 
>>millisecond/s as expected, 
>>but overshoots the right time by about the same absolute value of
>>offset. This happens repeatedly. 
>>For example, from -20 sec it goes all the way to 20 sec offset and
> 
> then
> 
>>back to -20 and so on many times. 
>>I did not wait for it to settle down. 
>>
>>When the "kernel" is disabled, it overshooted only by less than 0.5s 
>>and then slowly settled to the correct time. Actually, it settled to 
>>the range of +-120ms around the peer's time.
>>
>>It looks to me that "disable kernel" offers a saner behavior in this 
>>case. Any comments?
>>
>>Regards,
>>Sergey
>>
>>-----Original Message-----
>>From: questions-bounces at lists.ntp.isc.org
>>[mailto:questions-bounces at lists.ntp.isc.org] On Behalf Of David L. 
>>Mills
>>Sent: Thursday, February 17, 2005 9:24 PM
>>To: questions at lists.ntp.isc.org
>>Subject: [ntp:questions] Re: Ntp-4.1.2: tinker step 0;always slew and
>>kernel time discipline
>>
>>
>>Nikolaev,
>>
>>In truth, the kernel is disabled only if the actual correction is
>>greater than 0.5 s no matter what the tinker. However, there could be 
>>grief if the discipline switches from one to the other. There are a 
>>rather large number of untested and probably dangerous things that
> 
> might
> 
>>happen with uncharted combinations of tinkers and I'm not thrilled 
>>when
>>spending lots of time fixing the broken combinations. You are on your 
>>own, but a "diable kernel" command might be appropriate.
>>
>>Dave
>>
>>Nikolaev, Sergey wrote:
>>
>>
>>>We have a requirement to always slew the clock even if it means long
>>>periods of time to correct the offset.
>>>
>>>The NTP documentation mentions this tinker option:
>>>
>>>step step
>>>The argument is the step threshold, by default 0.128 s. It can be set
>>
>>to any positive number in seconds. If set to zero, step adjustments 
>>will never occur.
>>
>>
>>>Note: The kernel time discipline is disabled if the step threshold is
>>
>>set to zero or greater than the default.
>>
>>
>>>However when I set "tinker step 0" and restart ntpd, I see in "ntpdc
>>>-c sysinfo" that the kernel flag is still enabled. Obviously, it is 
>>>not disabled automaticly just by setting "tinker step 0".
>>>
>>>Do I need to disable it explicitly?
>>>
>>>Thanks in advance,
>>>Sergey
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>The information contained in this e-mail is confidential. This e-mail 
>>is intended only for the stated addressee.  If you are not an 
>>addressee, you must not disclose, copy, circulate or in any other way 
>>use or rely on the information contained in this e-mail. if you have 
>>received this e-mail in error, please inform us immediately and delete
> 
> 
>>it and all copies from your system.
>>
>>EBS Dealing Resources International Limited. Registered address: 10 
>>Paternoster Square, London EC4M 7DY, United Kingdom. Registered number
> 
> 
>>2669861.
>>
>>EBS Dealing Resources, Inc, registered in Delaware. Address: 535 
>>Madison Avenue, 24th Floor, New York, NY 10022, USA, and One upper 
>>Pond road, Building F - Floor 3, Parsippany, NJ 07054, USA.
>>
>>EBS Dealing Resources Japan Limited, a Japanese Corporation. Address: 
>>Asteer Kayabacho Bldg, 6th Floor, 1-6-1, Shinkawa, Chuo-Ku,  Tokyo 
>>104-0033, Japan.
>>
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions



More information about the questions mailing list