Hans Jørgen Jakobsen wrote: > Spoon wrote: > >> 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. > > If the problem is to not have overflow or underflow then why not steer on > how full the buffer are.
This is easier said than done. When there is a lot of jitter on the link between A and B, it is actually quite hard to even tell whether the buffer is shrinking or expanding. The problem becomes a digital signal processing exercise. I didn't find an appropriate filter. The people in comp.dsp told me to take a look at NTP. > The master(A) send packets out at its rate. > B answers trying to have N in the buffer. This was my original implementation. It did not work well. > Could you change the protocol and allow to flag that a packet is going > to be dropped or send a dummy answer? Could you expand on this suggestion? What is the purpose of the flag? > Sending packet at a smooth rate of 1000 Hz requires a fairly accurate > scheduling. I'm running a soft real-time OS with high-resolution timers. A frequency of 1 kHz is easy to achieve. > (In telecom they have the same problem. Their solution involves systems > of frequency synchronized clocks) What is a frequency synchronized clock? Regards. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
