On 22/10/05, Bruce Barnett <[EMAIL PROTECTED]> wrote: > > We found a problem using DCCP where the OS while using DCCP adds > additional application latency (not packet latency). > > Let me see if I can explain it. > > Our application is checking the network connection for available > packets, and if nothing is there, and there is nothing else for our app > to do, it reads from the audio input. This is a blocking read. > > Because of the nature of the hardware, and the buffer size, the > application returns either 16 msecs or 32 msecs after the last audio > read (+/- a millisecond). > > This works fine using UDP as a transport mechanism. > > However, when we select DCCP (a command line option), and when we > expect to be blocked for 16 milliseconds, there are times when we end > up being blocked for 20-24 milliseconds. This happens several times in > a row, and this makes the audio sound very choppy. > What size packets are you running. Remember that time between packets is based on packet size and transmit rate. Have a look at the t_ipi code or the CCID3/TFRC spec but basically time between packets is size/speed. So you would get 25 msec on a 40 kb link if running 1000 byte packets. If you are getting some variation on smaller packets you could quite easily get 25 msec.
This is a large part of the reason for the proposed VoIP CCID which specifies 10 msec between packets. This may well suit your needs better... -- Ian McDonald http://wand.net.nz/~iam4 WAND Network Research Group University of Waikato New Zealand - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
