From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 20 Feb 2016 18:45:48 +0100 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20160220174548.GA1630@polynum.com> References: <20160218113017.GB2756@polynum.com> <49010da5-9c4e-4399-8fbe-e4dae715063f@email.android.com> <20160219125246.GA345@polynum.com> <7cdd0c6898558feb7648d8d0bd356157@lilly.quanstro.net> <20160220103225.GA42@polynum.com> <901BC05C-A1C3-43F2-88F1-C96B28C00CD5@gmail.com> <20160220121147.GA515@polynum.com> <20160220140149.GA1093@polynum.com> <36a7a43105da0ea05fcec8fe089d37ac@mule> MIME-Version: 1.0 In-Reply-To: <36a7a43105da0ea05fcec8fe089d37ac@mule> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [9fans] rtl8169 gbe slow Topicbox-Message-UUID: 86d11c7c-ead9-11e9-9d60-3106f5b1d025 On Sat, Feb 20, 2016 at 09:20:52AM -0800, erik quanstrom wrote: > On Sat Feb 20 06:04:02 PST 2016, tlaronde@polynum.com wrote: > > On Sat, Feb 20, 2016 at 02:31:54PM +0100, hiro wrote: > > > what is the latency on WAN? > > > > When using traceroute, I have 42.6ms for a roundtrip > > (cf. with LAN: 0.23ms). > > > > But the very same machine, under NetBSD, with the very same ip address, > > downloads the very same file from the very same external server > > (downloads.kergis.com) in 17s, while hget(1) spends 6 minutes doing > > it. > > > > I wondered if the unsupported same chip integrated network card would > > be a problem. But disabling it via the BIOS doesn't change anything. > > > > Is there a way to trace what hget is doing/calling so that I can have a > > clue about the bottleneck? There is no transmission errors on the > > interface, so the problem is in the upper levels of TCP/IP. > > yes. i believe this was suggested before. from the evidence, the best > guess is that you are using an old kernel with an old tcp. Does it explain the difference between LAN and WAN? ftp is TCP; and on LAN there is no visible problem (connecting to a host running NetBSD)--- well, since the latency on LAN is the 1/300 of the latency of WAN, the problem could be masked... > > the old tcp had abysmal performance starting at a latency of ~10ms. this > was due to a flawed implementation of tcp reno. plan 9 used to commit > the cardinal sin of tcp, and move the left edge of the window. > > anyway, please update your tcp. the debugging tools that are most > helpful with tcp are > /net/tcp/stats > /net/tcp/*/status > echo tcp>/net/log && tail -f /net/log To update I need to update the sources. Where are now the "updated" sources? since Bell Labs site seems to be definitively down... Is there somewhere the "latest" sources, at least with the TCP corrections? -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C