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

[Spoon]

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? ;-)

Regards.