The delays dealt with in your paper might actually help a highly loaded server with lots of sockets and threads trying to communicate.
The packet processing delays caused by the scheduling delay paces the TCP sender by controlling the rate at which ACKs go back to that sender. Those ACKs will go out paced to the rate at which the sleeping TCP receiver gets back onto the cpu, and this will cause the TCP sender to naturally adjust to the overall processing rate of the receiver system, on a per-connection basis. Perhaps try a system with hundreds of processes and potentially hundreds of thousands of TCP sockets, with thousands of unique sender sites, and see what happens. This is a similar topic like TSO, where we are trying to balance the gains from batching work from the losses of gaps in the communication stream. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
