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: <[EMAIL PROTECTED]> >> 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. _______________________________________________ questions mailing list [EMAIL PROTECTED] https://lists.ntp.isc.org/mailman/listinfo/questions
