[ntp:questions] Getting NTP to correct only the clock skew
Spoon
devnull at ntp.isc.org
Sun Apr 15 08:41:17 UTC 2007
David Woolley wrote:
> Hal Murray wrote:
>
>> 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.
>
> No. He wants to synchronize B's clock to that of the machine that
> is adding time stamps to the data stream.
Exactly.
> The basic problem is to re-time
> the data so that the network jitter is removed from the stream being
> re-broadcast by B.
Exactly.
> Either A is the original source, or A is connected
> to the original source over a low jitter path.
The data stream is provided by a PCI board connected to A. The jitter
between the board and A is small enough to be negligible.
> If A accurately time
> stamps the packets and B re-transmits them at the time stamp time plus
> at least the maximum network latency, the packets out of B will have the
> same timing relationship as those out of A, subject only to clock errors.
Exactly.
> I'm afraid he has been failing to understand that his application is
> rather unusual and therefore failing to recognize when people are
> solving the wrong problem, and more clearly explain what he is trying
> to do.
I did try to detail the situation in
Message-ID: <4610e30a$0$12301$426a74cc at news.free.fr>
>> How good is that clock? Is it synchronized to UTC?
>> (synchronized in frequency, I don't think you care about the time)
The PCI board features a temperature-compensated VCXO which ticks at
27 MHz +/- 2 ppm. It is not synchronized to UTC.
I don't think it's possible to "discipline" this oscillator.
> I think the original presumption was that it was not. More precisely,
> unless he can get a low jitter UTC source at B, other than by synchronizing
> to A, it doesn't really matter whether or not A is on true time.
>
>> In any case, you have to figure out what you are going to do
>> if your buffer overflows or underflows.
>
> What he will get when the system fails through network effects, other than
> those affecting time synchronization, is that a positive spike in network
> latency will cause a packet to arrive after its due time for retransmission.
> Either there is some theoretical reason why the network latency is bounded, in
> which case he makes sure that he delays transmission by more than the
> maximum latency, or he is just going to have to retransmit the packet
> as soon as it arrives.
Correct. Except that stale packets are discarded. If a packet is not
available when it is supposed to be sent, B inserts stuffing instead.
> I think he is assuming that access latency to the
> local network at B is negligible, so there will be no transmission queue.
B buffers X milliseconds worth of data (X is specified by the user).
B sends the data stream to a PCI board connected to B.
> That's the underflow case. I imagine that it is easy to dimension the
> system so that overflow is impossible.
>
>> 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?
>
> I think what he was actually asking for is that B should correct the
> frequency error, dead beat, without overshooting to correct the phase
> error. Unfortunately, that ignores that the NTP algorithm is a phase
> locked loop, so tries to maintain frequency lock by maintaing phase
> lock. Most hardware solutions to locking two frequencies also do so by
> locking the phases, as it is easier to measure phase error than to directly
> measure frequency error.
Point taken.
Anyway, thanks to Hal Murray, I located the origin of a nasty problem in
my OS. Once fixed, ntpd works *much* better.
>> If both clocks are reasonably stable (needs stable temperature) then
>> you can probably build a pseudo clock on B by building a PLL on
>
> Once you've introduced the phase lock, you've introduced part of the
> problem with NTP! NTP is going to have better implemented phase locking
> than a one off implementation. I suspect the changes he wants to NTP
> are really:
>
> 1) set the step out limit based on the actual network jitter in his case;
> 2) when a step occurs, do it by adjusting a correction between the local
> clock and NTP's idea of the local clock, so that the actual local clock
> never steps.
I don't want to reinvent the wheel.
If ntpd works well, I'll just use that.
>> the buffer fullness. The time constant on the PLL needs to be
>
> That does actually point out that you must use the full phase locking
> and must over correct the frequency. Otherwise, over time, you could
> suffer an underflow.
>
>> slow enough to filter out the network jitter and fast enough
>> to track the changes in the crystal drift due to temperature.
>
> I think this is what is called the Allen intercept.
>
>> An hour is probably the right ballpark.
>
> I presume that maxpoll in NTP is based on empirical measurements, in
> which case the figure you want is more like 20 minutes. However, if
> the latest NTP algorithms work as well as Dr Mills claims, their
> adaptive time constanst are going to do better than this (I'm still
> not convinced that it really centres phase and frequency as fast as it
> might when they both start outside their respective noise bands).
>
>> 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 think he has a never underflow requirement. Really, for anything like
> this you should always specify a percentile compliance level, but managers
> often don't understand that they are dealing with statistics. I think there
> is a good chance, here, that he can actually bound the jitter such that
> underflow essentially never happens. (He would be better using ATM
> reserved bandwidth, than a statistical packet network, of course.) We
> don't really even know if this is a commercial or military application.
This is a commercial app.
Reserved bandwidth does not necessarily mean "no jitter" though.
>> 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
>
> I don't think his problem is buffer size, it is accurately retiming the
> transmissions. If there is a buffer size problem it is in the final
> consumers, and I think he only has a one way path to them.
Buffer size is the user's responsibility.
> Incidentally, I suspect he has a requirement to maintain timing to a higher
> standard than the final consumer. The final consumer may well be just
> crystal stabilised, so he may be trying to improve that by a factor of
> about 10.
I don't understand this paragraph. Could you explain?
Regards.
More information about the questions
mailing list