Hi, On Wed, 19 Dec 2007, Ilpo Järvinen wrote:
> Isn't it also much better this way in a case where ACK losses happened, > taking the longest RTT in that case is clearly questionable as it > may over-estimate considerably. Quite so. > However, another thing to consider is the possibility of this value being > used in "timeout-like" fashion in ca modules (I haven't read enough ca > modules code to know if any of them does that), on contrary to > determinating just rtt or packet's delay in which case this change seems > appropriate (most modules do the latter). I'm not aware of any, but I haven't read them all either. I would have thought tp->srtt was the value to use in this instance, but perhaps the individual timestamps including delack delay are useful. > Therefore, if timeout-like module exists one should also add > TCP_CONG_RTT_STAMP_LONGEST for that particular module and keep using > seq_rtt for it like previously and use ca_seq_rtt only for others. Seems reasonable. I'll add this. > This part doesn't exists anymore in development tree. Please base this > patch (and anything in future) you intend to get included to mainline > onto net-2.6.25 unless there's a very good reason to not do so or > whatever 2.6.xx is the correct net development tree at that time (if > one exists). Thanks. Will do. I gather I should use the latest net- tree in future when submitting patches. Thanks for the helpful comments, Gavin -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
