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

Nikolaev, Sergey snikolaev at ebs.com
Fri Feb 18 16:05:37 UTC 2005


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