[ntp:questions] Getting NTP to correct only the clock skew
devnull at ntp.isc.org
Sat Apr 14 10:48:32 UTC 2007
Hal Murray wrote:
> Spoon wrote:
>> 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.
>> This is why I need A's clock and B's clock to tick at the same rate.
> You can turn things inside out. Make B's clock be the master.
Why do you think making B the master is better than making A the master?
All I need is for both clocks to tick at the same speed.
> Every n packets, B asks A for more. A doesn't care what time it
> is. It just sends packets when B asks for them.
I can't do that.
A has no control over the rate of the data stream: A receives a CBR data
stream from a local device, stuffs the data into packets, and sends them
over the network.
> If you have something like speech with gaps that can be
> stretched or squished, you may be able to write not too
> complicated code on B that will track A's clock.
The data is compressed video (MPEG Transport Stream).
> If you have something like music with no (or few) gaps,
> then making B track A is roughly reinventing ntp.
MPEG TS does have "stuffing packets" but adding or removing them breaks
the embedded timestamps (program clock reference).
> In any case, you have to figure out what will happen if
> B runs out of data or the queue overflows. Maybe that
> will be good enough to cover the startup transient.
I lose my job? ;-)
More information about the questions