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

Spoon devnull at ntp.isc.org
Sat Apr 14 11:28:42 UTC 2007

Hans Jørgen Jakobsen wrote:

> Spoon wrote:
>> Hans Jørgen Jakobsen wrote:
>>> 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.
> Did you have a buffer large enough to take care of jitter.

Of course I did. Why do you ask?
I buffered 500 ms worth of data.
I used a network emulator to add 0-50 ms random delays.

>>> 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?
> When buffer full drop an answer to A.
> To be kind to A, B tell A that a packet will be missing. Either
> piggyback in previous packet or as separate packet.

(In the current implementation, B never sends anything to A.)

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. B is not allowed to discard any packet.

> When buffer is empty. Send packet with no or dummy data.

The buffer must never be empty.

Adding packets will break the timestamps embedded inside the data.

> As mentioned by others this looks as a flow control problem.

I don't think so. It's a DSP problem.

> What are the requirements between A and B. Do there have to be a 1:1
> number of packets. How do you handle dropped packet (You did use UDP!)

B just relays packets. It never(*) inserts or deletes packets.
(*) When B detects a lost packet, it inserts a stuffing packet.

> How important is timing? Its important to A? to B? to A and B?

B feeds a local device which must be told the play-out rate. Once that 
play-out rate is set, it can only be changed by 1 bit/s every 90 MB, 
i.e. veeery slowly.

> Is the rate that packets flow important? to A? to B? to A and B?

It is constant.

>>> 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.
> Also schedule something to happen every 1.001 milisecond?

I don't understand what you mean.
My process is a real-time process. If it wants the CPU, it gets it.

> Sorry, didnt use the right words. Should be "frequency disciplined oscillator".

How do I get a "frequency disciplined oscillator" in a standard 
industrial PC?

Is this related to voltage-controlled crystal oscillators?

Are they available on PCI boards with Linux 2.6 drivers?


More information about the questions mailing list