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. 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. - 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
