IETF mailing list, I'm wondering if you'd like to comment on this as it seems to be a real implementation issue - using TFRC on local lans (100 Mbits/sec, < 2 ms rtt) seems to cause high CPU load when doing testing using tools such as iperf.
Is it worth considering having a minimum no feedback timer for the spec as checking things this often is not so good and would definitely hinder uptake on local boxes if we were being RFC compliant. Thanks Gerrit for raising this. Regards, Ian ---------- Forwarded message ---------- From: Gerrit Renker <[EMAIL PROTECTED]> Date: Dec 1, 2006 2:18 AM Subject: [PATCH] [DCCP]: Use higher timeout value for nofeedback timer To: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>, Ian McDonald <[EMAIL PROTECTED]> Cc: DCCP Mailing List <[email protected]>, Leandro Melo de Sales <[EMAIL PROTECTED]>, Burak Gorkemli <[EMAIL PROTECTED]> This is the patch which stops the nofeedback timer from spinning every couple of microseconds, triggered by small RTTs. However, there are a few more bugs in CCID 3; this is work in progress. -----------------> Commit Message <----------------------------------- [DCCP]: Use higher RTO default for CCID3 The TFRC nofeedback timer normally expires after the maximum of 4 RTTs and twice the current send interval (RFC 3448, 4.3). On LANs with a small RTT this can mean a high processing load and reduced performance, since then the nofeedback timer is triggered very frequently. As a result, the sending rate quickly converges towards zero. This patch provides a configuration option to set the bound for the nofeedback timer, using as default the TCP RTO timeout of 1 second. By setting the configuration option to 0, RFC 3448 behaviour can be enforced for the nofeedback timer. Has been tested to compile and work. Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]> -- Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group - 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
