Re: Getting NTP to correct only the clock skew

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@xxxxxxxxxxxx>

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

Relevant Pages

  • Re: Getting NTP to correct only the clock skew
    ... to synchronize B's clock to the source of your CBR data. ... at least the maximum network latency, the packets out of B will have the ... that ignores that the NTP algorithm is a phase ...
    (comp.protocols.time.ntp)
  • Time synchronization on an autonomous isolated network
    ... I have a network from 4 to 8 PC's of which the time needs to be ... the wall clock time before being connected on the network. ... PC's they want to synchronize the time. ... reasonable timeframe. ...
    (comp.protocols.time.ntp)
  • Time synchronization on an autonomous isolated network
    ... I have a network from 4 to 8 PC's of which the time needs to be ... the wall clock time before being connected on the network. ... PC's they want to synchronize the time. ... reasonable timeframe. ...
    (comp.protocols.time.ntp)
  • Re: "The Observational Collapse of Einsteinian Physics"
    ... > |> You are still not fooling anyone, ... > | If at the point A of space there is a clock, ... Clocks do not synchronize without infinite time. ... Whoever gave you the idea that *I* was the peer in ...
    (sci.physics)
  • Re: Time clock on SBS 2003
    ... give your laptop an ip one number higher than the time clock. ... If the device was on the network and it was getting an ip using the ... guess that I would have to find the device in the server first to make it ... In the end we had to install the user interface on the server and RDP ...
    (microsoft.public.windows.server.sbs)