On 10/21/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.
Lets see if I can grok 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. you mean using select or poll? Or doing a recvmsg with some timeout? > This is on a 40 Kb/second network emulation using a freebsd system as > the router, with a queue size of 2 packets. I have network traces, > as well as the DCCP stats from the application perspective. > > I'm not sure how to test this using a simple test case, > or how to find ways to better diagnose the problem. > > I did select the "low latency" kernel option when I built the kernel. > Using net-2.6.14-git. I'd encourage you to use the latest Linus tree, that has some DCCP patches merged, just as a way to have everybody testing on the same codebase. - Arnaldo - 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
