From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FTQgm-0001hc-4J for qemu-devel@nongnu.org; Tue, 11 Apr 2006 17:46:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FTQgk-0001gS-Bq for qemu-devel@nongnu.org; Tue, 11 Apr 2006 17:46:19 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FTQgk-0001gO-6j for qemu-devel@nongnu.org; Tue, 11 Apr 2006 17:46:18 -0400 Received: from [64.233.162.202] (helo=zproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FTQlg-0004Ew-R0 for qemu-devel@nongnu.org; Tue, 11 Apr 2006 17:51:24 -0400 Received: by zproxy.gmail.com with SMTP id l8so1251867nzf for ; Tue, 11 Apr 2006 14:46:17 -0700 (PDT) Message-ID: <6fe044190604111446k635c58bdj89d154e04525cf1c@mail.gmail.com> Date: Tue, 11 Apr 2006 14:46:17 -0700 From: "Kenneth Duda" Sender: ken.duda@gmail.com Subject: Re: [Qemu-devel] Network Performance between Win Host and Linux In-Reply-To: <443C1455.5080302@win4lin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6fe044190604111020h47108190x23983325567fb51c@mail.gmail.com> <200604111828.29361.paul@codesourcery.com> <6fe044190604111049j186d7c44oea9568ce1a8b54f3@mail.gmail.com> <443C1455.5080302@win4lin.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Thanks, Leo. It appears your patch or something similar has made it into 0.8.0. I have already merged the select loops, but it didn't help as much as I hoped, maybe 10%. A much bigger improvement was made by fixing the badly hacked slirp DELACK behavior. Believe it or not, slirp delays all TCP acks *unless* the segment data starts with an escape character, I kid you not. I threw that out, and have made slirp's tcp_input rfc2581 compliant (to my shallow reading of the rfc) and that boosted throughput from vm->host by 3.5x, to 56 megabits (from 16 megabits). The performance from host->vm was helped less, and that was because of another hack in slirp that was causing it to get the wrong MSS --- it was sending 512 byte segments. Now, I'm looking at excessive numbers of retransmissions (believe it or not) --- I suspect the ne2000 ring buffer is overflowing but I'm not yet sure. I will post a patch including all of these things when I'm done. I'm expecting a significant aggregate improvement. -Ken On 4/11/06, Leonardo E. Reiter wrote: > Hi Ken, > > I'm attaching a pretty old patch I made (from the 0.7.1 days), which did > a quick and dirty merge of the select's. It's not something that is > clean and it will need adapting to 0.8.0... but, I figure you could draw > some quick hints on how to merge the 2. Basically it fills the select > bitmaps when it walks through the fd's the first time, then calls select > instead of poll. It also has slirp fill its own bits (fd's) in before > calling select. So this is condensed to 1 select call. > > Do what you want with the code - like I said, it's messy and old. But > maybe you can at least use it to quickly test your hypothesis. I'd be > interested in learning about any benchmarks you come up with if you > merge the select+poll. Also, it may not be valid at all on Windows > hosts since there is a question about select() being interrupted > properly on those hosts - it should work on Linux/BSD. > > Regards, > > Leo Reiter > > P.S. this patch should be applied with -p1, not -p0 like my newer > patches are applied. Sorry for that - like I said, it's quite old. >