Date: Thu, 12 May 2005 11:38:59 +0200 From: "Daniel Eriksson" <daniel_k_eriksson@telia.com> To: <freebsd-current@FreeBSD.org> Cc: 'Paul Saab' <ps@FreeBSD.org> Subject: RE: cvs commit: src/sys/netinet tcp_input.c tcp_output.c tcp_sack.c tcp_var.h Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAtAB4icwmbUydEt2AO/Ka2AEAAAAA@telia.com> In-Reply-To: <200505112137.j4BLbhs9011153@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Saab wrote: > ps 2005-05-11 21:37:43 UTC > > FreeBSD src repository > > Modified files: > sys/netinet tcp_input.c tcp_output.c tcp_sack.c > tcp_var.h > Log: > When looking for the next hole to retransmit from the scoreboard, > or to compute the total retransmitted bytes in this sack recovery > episode, the scoreboard is traversed. While in sack recovery, this > traversal occurs on every call to tcp_output(), every dupack and > every partial ack. The scoreboard could potentially get quite large, > making this traversal expensive. > > This change optimizes this by storing hints (for the next hole to > retransmit and the total retransmitted bytes in this sack recovery > episode) reducing the complexity to find these values from O(n) to > constant time. > > The debug code that sanity checks the hints against the computed > value will be removed eventually. After upgrading one of my servers this morning (dual Athlon MP) I'm getting a fair amount of these on the console: tcp_sack_output: Computed sack hole not the same as cached value So far I have ~50 such lines in the log after ~3 hours of uptime. No users have reported any problems though. /Daniel Eriksson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAtAB4icwmbUydEt2AO/Ka2AEAAAAA>