# [ntp:questions] Setting the maximum rate of change

Spoon devnull at localhost.com
Tue Mar 20 08:50:24 UTC 2007

```Harlan Stenn wrote:

> Spoon wrote:
>
>> Is there a run-time parameter in NTP that defines the
>> maximum rate at which the clock can be adjusted (slewed?).
>
> There is probably a "tinker" variable to do this.  Be amazingly careful
> when messing with these.

The documented tinker options are:
http://www.eecis.udel.edu/~mills/ntp/html/miscopt.html
allan | dispersion | freq | huffpuff | panic | step | stepout
I don't think any of these are appropriate.

> But I don't think you will need to - see below.

OK.

>>
>> I'm working with a standard that deals with 27 MHz clocks, and that
>> standard states that the frequency must not change faster than 75 mHz
>> per second.
>
> If ntpd has the correct drift adjustment, you should be in good shape.

drift or skew?

> Under what exact conditions must the "don't change faster than 75mHz/sec"
> be met?

Consider two systems A and B. At initialization, B's clock is set to A's
clock (offset = 0 initially). After 30-60 seconds, it is acceptable to
make a large correction to compensate for the average skew. From then
on, B's skew correction parameter should not be changed faster than 75
mHz per second.

>> I'll try and think aloud, in case someone can see through my
>> confusion.
>>
>> Consider H : a 26,999,900 Hz clock.
>>
>> Thus H has an offset of 100 Hz = 3.7 ppm

I am talking about a frequency offset, i.e. what NTP calls skew AFAIU.

>> In other words, H "misses" 100 ticks every second.
>
> If left uncorrected, yes.

So far, so good.

>> I'd have to add 100 / 27e6 = 3.7 µs every second to keep H from
>> drifting away from the correct time.
>
> Once ntpd has achieved "state 4", ntpd will calculate the drift and will
> automatically handle this.

According to the definition's page you've mentionned, drift is the
variation in skew, I think you meant ntpd will calculate the skew?

>> But I can't make that change all of a sudden, I can only change 0.075
>> Hz more (2.78 ns) every second.
>
> ntpd will apply the correction on a per-tick basis, not all at once, once a
> second.

I know. I did not mean 2.78 ns added every second, I meant a rate of
2.78 ns per second, i.e. 2.78 ppb.

> Are you comfortable that the specs of the machines you are using will keep
> time well enough that their clocks can be kept in-sync by limiting

I'm still testing this. Basically, the two machines will remain at
constant temperature. I'm hoping that clock drift on either machine will
be very small, i.e. skew between the two clocks should remain almost
constant. Thus, once ntpd has computed the correct skew, everything
should be OK.

>> Would I improve precision if I changed HZ from 100 to 250?
>
> Exactly what do you mean by "precision"?

Good question. I'll have to think about it ;-)

> Have you seen http://ntp.isc.org/Support/NTPRelatedDefinitions ?

Thanks.

> And have you read about the problems you can cause by having HZ at a value
> other than 100?  Particularly with Linux kernels?

No. Where is that?

Regards.

```