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

Spoon root at localhost.invalid
Thu Apr 5 19:53:16 UTC 2007


Hans Jørgen Jakobsen wrote:

> Spoon wrote:
>
>> 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.

This is easier said than done. When there is a lot of jitter on the link 
between A and B, it is actually quite hard to even tell whether the 
buffer is shrinking or expanding. The problem becomes a digital signal 
processing exercise. I didn't find an appropriate filter.

The people in comp.dsp told me to take a look at NTP.

> The master(A) send packets out at its rate.
> B answers trying to have N in the buffer.

This was my original implementation. It did not work well.

> Could you change the protocol and allow to flag that a packet is going
> to be dropped or send a dummy answer?

Could you expand on this suggestion?
What is the purpose of the flag?

> Sending packet at a smooth rate of 1000 Hz requires a fairly accurate
> scheduling.

I'm running a soft real-time OS with high-resolution timers.
A frequency of 1 kHz is easy to achieve.

> (In telecom they have the same problem. Their solution involves systems
> of frequency synchronized clocks)

What is a frequency synchronized clock?

Regards.




More information about the questions mailing list