From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 8 May 2015 21:24:13 +0200 From: David du Colombier <0intro@gmail.com> To: 9fans@9fans.net Message-ID: <20150508212413.7466429d@zinc.9fans.fr> In-Reply-To: <20150508191612.2f080829@zinc.9fans.fr> References: <87C61423-7C13-4516-88B5-C2ABA7D32AA9@me.com> <20150508191612.2f080829@zinc.9fans.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [9fans] fossil+venti performance question Topicbox-Message-UUID: 502d42b8-ead9-11e9-9d60-3106f5b1d025 I've finally figured out the issue. The slowness issue only appears on the loopback, because it provides a 16384 MTU. There is an old bug in the Plan 9 TCP stack, were the TCP MSS doesn't take account the MTU for incoming connections. I originally fixed this issue in January 2015 for the Plan 9 port on Google Compute Engine. On GCE, there is an unusual 1460 MTU. The Plan 9 TCP stack defines a default 1460 MSS corresponding to a 1500 MTU. Then, the MSS is fixed according to the MTU for outgoing connections, but not incoming connections. On GCE, this issue leads to IP fragmentation, but GCE didn't handle IP fragmentation properly, so the connections were dropped. On the loopback medium, I suppose this is the opposite issue. Since the TCP stack didn't fix the MSS in the incoming connection, the programs sent multiple small 1500 bytes IP packets instead of large 16384 IP packets, but I don't know why it leads to such a slowdown. Here is the patch for the Plan 9 kernel: http://9legacy.org/9legacy/patch/9-tcp-mss.diff And Charles' 9k kernel: http://9legacy.org/9legacy/patch/9k-tcp-mss.diff -- David du Colombier