[ntp:questions] Getting NTP to correct only the clock skew

Hans Jørgen Jakobsen hjj at wheel.dk
Mon Apr 2 14:20:22 UTC 2007


On Mon, 02 Apr 2007 13:02:40 +0200, Spoon wrote:
> Richard B. gilbert wrote:
>
>> Spoon wrote:
>>
>>> I've read this page:
>>> http://ntp.isc.org/bin/view/Support/HowToCalibrateSystemClockUsingNTP
>>> which explains how to let NTP determine the frequency offset (skew).
>>>
>>> I have a strange request:
>>>
>>> Is it possible to run NTP in a mode where it does not try to correct
>>> the time offset, but only correct the frequency offset (skew)?
>>>
>>> In other words, assume my clock says it is some time last year, and
>>> gains 1 second every day (11.6 ppm). I don't want NTP to either slew
>>> or step my clock to the correct time, but I still would want it to fix
>>> this 1 s per day (11.6 ppm) frequency offset.
>>>
>>> Has this ever been considered?
>> 
>> I doubt it very much!
>> 
>>> Is there a variable I could tinker with? :-)
>> 
>> I don't know of any.
>> 
>> What problem are you trying to solve?
>> 
>> Most people want the correct time rather than simply a clock keeping the
>> wrong time but one that ticks at one second per second.
>
> I'll try to explain my situation in detail.
>
> Consider two systems, A and B.
>
> A sends ~1000 UDP packets per second to B.
>
> A timestamps each packet.
>
> These packets travel over an IP network, and suffer delay and jitter.
>
> B is supposed to re-send the packets it receives at the rate they
> were originally sent by A.
>
> B buffers N packets. Then it sends the first packet in the queue, 
> computes the departure time of the next packet using the timestamps 
> provided by A, and sleeps until that departure time.
>
> If the clocks on A and B do not tick at the same rate, the buffer used 
> by B will either overflow or underflow.
>
If the problem is to not have overflow or underflow then why not steer on
how full the buffer are. The master(A) send packets out at its rate.
B answers trying to have N in the buffer.
Could you change the protocol and allow to flag that a packet is going
to be dropped or send a dummmy answer?
Sending packet at a smooth rate of 1000Hz requires a fairly accurate
scheduling.

(In telecom they have the same problem. Their solution involves systems
of frequency syncronized clocks)
/hjj




More information about the questions mailing list