[ntp:hackers] Re: ntp time with 10000 HZ value in linux kernel

David L. Mills mills at udel.edu
Wed Jul 12 22:27:55 UTC 2006


Hairan,

Glad to help.

Dave

hz2116 at columbia.edu wrote:

> Professor Mills,
>
> I just want to thank you for your help. Your suggestions of shaving
> 7 bits off SHIFT_SCALE and modification in the tickadj()[
> update_wall_time_one_tick() linux] helped to solve our timing
> problem. Now our systems are running 10k HZ kernel with our
> internal ntp server are sync up within 1 ms.
>
> Regards,
> hairan
>
> Quoting "David L. Mills" <mills at udel.edu>:
>
>> Hairan,
>>
>> There is no SHIFT_SCALE define in the nanokernel sources that
>> leave here. Linux might be using an older microkernel version,
>> which was deprecated several years ago. I've asked all
>> kernelmongers who use the code to avoid changing any parameters,
>> as the code is a component of a second-order hybrid
>> time/frequency feedback loop with very unforgiving time
>> constants.
>>
>> Changing the frequency or its reciprocal tick interval requires
>> changing the gain factor in the tick interrupt code. This is
>> ordinarily done automatically by inspecting the kernel variable
>> hz, which is the timer interrupt frequency. Very likely Linux
>> folks have changed something in that area and the gain factor is
>> wrong. However, the presence of the SHIFT_SCALE tells me the
>> automatic feature is not used. If they are using SHIFT_SCALE as a
>> gain constant and it works at 100 Hz and you are at 10000 Hz, try
>> shaving 7 bits off that 22 bit value.
>>
>> I'm sure you realize what you are asking the kernel to do with hz
>> = 10000. The Unix routine tickadj() is expected to slew the clock
>> frequency at 500 microseconds per second, which amounts to 5
>> microseconds per tick interrupt at 100 Hz or 50 nanoseconds per
>> tick at 10000 Hz. That will result in underflow, even with the
>> current code that leaves here. The highest frequency tested here
>> is 1024 Hz as used in the Tru64 Alpha. If that is the case with
>> your code, you have a failed agenda. Very likely you will have to
>> redesign the tick increment code in the timer() routine in
>> kern_clock.c, but I bet Linux has shredded the standard Unix
>> code.
>>
>> Dave
>>
>> hz2116 at columbia.edu wrote:
>>
>>> Hi Professor Mills,
>>>
>>> Thanks for the recommendation, however, I think we're stuck
>>
>> with
>>
>>> linux and we're facing ntp timing problem with HZ set to 10000.
>>
>> I
>>
>>> have one more question. What was the reason to choose
>>
>> SHIFT_SCALE
>>
>>> to be 22 in the linux kernel (defined in timex.h)? I think that
>>
>> may
>>
>>> have created some problems...
>>>
>>> Thanks a bunch,
>>>
>>> hairan
>>>
>>> Quoting "David L. Mills" <mills at udel.edu>:
>>>
>>>> Hairan,
>>>>
>>>> This is a well known problem. The Linux kernel has broken
>>>> something in the adjtime() system call. From past experience,
>>>
>> I
>>
>>>> don't expect they will fix it. You are strongly recommended to
>>>> switch to FreeBSD. We have done that with great success.
>>>>
>>>> Prof. Mills
>>>>
>>>> hz2116 at columbia.edu wrote:
>>>>
>>>>> Dear Professor Mills,
>>>>>
>>>>> My name is Hairan, a student at Columbia University. We have
>>>>> increased the linux kernel HZ value to 10000 on one of the
>>>>
>>>> systems
>>>>
>>>>> here in our lab. The system is running 2.6.16.19 kernel.
>>>>
>>>> However,
>>>>
>>>>> we are experiencing ntp time problem (constantly off by
>>>>
>> seconds
>>
>>>> to
>>>>
>>>>> minutes). I noticed the second_flow() function in
>>>>
>>>> kernel/timer.c,
>>>>
>>>>> which was written by you, is depending on the HZ value.
>>>>
>> Things
>>
>>>>> like time_adj. There is not logic in this module which I dont
>>>>> quite undersatnd, I hope you can give me some comments and
>>>>> directions.
>>>>>
>>>>> Is this line of still a valid statement when HZ = 10000 ?
>>>>>
>>>>> time_adj = -ltemp << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
>>>>
>> ?
>>
>>>>> and the follow:
>>>>>
>>>>> #if HZ == 1000
>>>>> /*
>>>>> * Compensate for (HZ==1000) != (1 << SHIFT_HZ). Add 1.5625%
>>>>
>> and
>>
>>>>> * 0.78125% to get 1023.4375; => only 0.05% error (p. 14)
>>>>> */
>>>>> time_adj += shift_right(time_adj, 6) + shift_right(time_adj,
>>>>
>>>> 7);
>>>>
>>>>> #endif
>>>>>
>>>>> what would the time_adj be if HZ == 10000 ?
>>>>>
>>>>> Your help, comments, insights are very much appreciated.
>>>>>
>>>>> thank you,
>>>>>
>>>>> sincerely,
>>>>>
>>>>> Hairan
>>>>
>>>>
>>>>
>>>
>>
>
>



More information about the hackers mailing list