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