Hans Jørgen Jakobsen wrote: > Spoon wrote: > >> Hans Jørgen Jakobsen wrote: >> >>> 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. > > Did you have a buffer large enough to take care of jitter.
Of course I did. Why do you ask? I buffered 500 ms worth of data. I used a network emulator to add 0-50 ms random delays. >>> 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? > > When buffer full drop an answer to A. > To be kind to A, B tell A that a packet will be missing. Either > piggyback in previous packet or as separate packet. (In the current implementation, B never sends anything to A.) 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. > When buffer is empty. Send packet with no or dummy data. The buffer must never be empty. Adding packets will break the timestamps embedded inside the data. > As mentioned by others this looks as a flow control problem. I don't think so. It's a DSP problem. > What are the requirements between A and B. Do there have to be a 1:1 > number of packets. How do you handle dropped packet (You did use UDP!) B just relays packets. It never(*) inserts or deletes packets. (*) When B detects a lost packet, it inserts a stuffing packet. > How important is timing? Its important to A? to B? to A and B? B feeds a local device which must be told the play-out rate. Once that play-out rate is set, it can only be changed by 1 bit/s every 90 MB, i.e. veeery slowly. > Is the rate that packets flow important? to A? to B? to A and B? It is constant. >>> 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. > > Also schedule something to happen every 1.001 milisecond? I don't understand what you mean. My process is a real-time process. If it wants the CPU, it gets it. > Sorry, didnt use the right words. Should be "frequency disciplined > oscillator". How do I get a "frequency disciplined oscillator" in a standard industrial PC? Is this related to voltage-controlled crystal oscillators? http://en.wikipedia.org/wiki/Voltage-controlled_oscillator Are they available on PCI boards with Linux 2.6 drivers? Regards. _______________________________________________ questions mailing list [EMAIL PROTECTED] https://lists.ntp.isc.org/mailman/listinfo/questions
