[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?
http://en.wikipedia.org/wiki/Voltage-controlled_oscillator
Are they available on PCI boards with Linux 2.6 drivers?
Regards.
More information about the questions
mailing list