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

Hal Murray hal-usenet at ip-64-139-1-69.sjc.megapath.net
Sat Apr 14 20:32:05 UTC 2007


>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.

Then your goal is not to synchronize B's clock to A's clock, you need
to synchronize B's clock to the source of your CBR data.  How good is
that clock?  Is it synchronized to UCT?  (syncrhonized in frequency,
I don't think you care about the time)

In any case, you have to figure out what you are going to do
if your buffer overflows or underflows.

What happens if B sends a little to fast for a while and then
a little to slow for a while to get back in sync?  Something
like that is going to happen.  You only get to discuss the
value of "little".  How close do you have to get?

How stable is the temperature at B and the source of the CBR data?

If both clocks are reasonably stable (needs stable temperature) then
you can probably build a pseudo clock on B by building a PLL on
the buffer fullness.  The time constant on the PLL needs to be
slow enough to filter out the network jitter and fast enough
to track the changes in the crystal drift due to temperature.
An hour is probably the right ballpark.

You need to make the buffer big enough so that it doesn't
over/underflow too often.  It doesn't have to never underflow,
it just has to do that rarely relative to how often the network
breaks.

I'd probably start with a super big buffer and add lots of instrumentation
until I was pretty sure I knew what was going on, say log the high/low
every minute or hour

-- 
These are my opinions, not necessarily my employer's.  I hate spam.




More information about the questions mailing list