>I'll try to explain my situation in detail. > >Consider two systems, A and B. > >A sends ~1000 UDP packets per second to B. > >A timestamps each packet. > >These packets travel over an IP network, and suffer delay and jitter. > >B is supposed to re-send the packets it receives at the rate they >were originally sent by A. > >B buffers N packets. Then it sends the first packet in the queue, >computes the departure time of the next packet using the timestamps >provided by A, and sleeps until that departure time. > >If the clocks on A and B do not tick at the same rate, the buffer used >by B will either overflow or underflow.
>This is why I need A's clock and B's clock to tick at the same rate. You can turn things inside out. Make B's clock be the master. Every n packets, B asks A for more. A doesn't care what time it is. It just sends packets when B asks for them. Of course, that may not work for your problem. If you have something like speech with gaps that can be stretched or squished, you may be able to write not too complicated code on B that will track A's clock. If you have something like music with no (or few) gaps, then making B track A is roughly reinventing ntp. In any case, you have to figure out what will happen if B runs out of data or the queue overflows. Maybe that will be good enough to cover the startup transient. -- 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
