Richard B. gilbert wrote: > Spoon wrote: > >> 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. > > This seems to me to resemble a very simple flow control problem solved > many years go by the simple expedient of having B tell A to stop sending > or to resume sending depending on the fullness of B's buffer pool; e.g. > the Xon/Xoff protocol used in things like Xmodem and Kermit.
Flow control is not an option. 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. Regards. _______________________________________________ questions mailing list [EMAIL PROTECTED] https://lists.ntp.isc.org/mailman/listinfo/questions
