From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FTQsS-0000Ng-CX for qemu-devel@nongnu.org; Tue, 11 Apr 2006 17:58:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FTQsQ-0000N8-2Z for qemu-devel@nongnu.org; Tue, 11 Apr 2006 17:58:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FTQsP-0000N5-Ts for qemu-devel@nongnu.org; Tue, 11 Apr 2006 17:58:21 -0400 Received: from [204.127.192.83] (helo=rwcrmhc13.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FTQxM-0005Th-Q4 for qemu-devel@nongnu.org; Tue, 11 Apr 2006 18:03:28 -0400 Message-ID: <443C267A.4090807@win4lin.com> Date: Tue, 11 Apr 2006 17:58:18 -0400 From: "Leonardo E. Reiter" MIME-Version: 1.0 Subject: Re: [Qemu-devel] Network Performance between Win Host and Linux References: <6fe044190604111020h47108190x23983325567fb51c@mail.gmail.com> <200604111828.29361.paul@codesourcery.com> <6fe044190604111049j186d7c44oea9568ce1a8b54f3@mail.gmail.com> <443C1455.5080302@win4lin.com> <6fe044190604111446k635c58bdj89d154e04525cf1c@mail.gmail.com> In-Reply-To: <6fe044190604111446k635c58bdj89d154e04525cf1c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Yes... I sent a follow-up note after I looked at the latest vl.c with a newer patch applied. much simpler. As for the delay acks, I've seen this and removed the delay for testing before. I read in the comment (not sure if it was Fabrice or the slirp author) about how the delay was 1 of 3 methods that had been chosen as sort of a "compromise." I recall testing newer versions of the code and not having as much of an issue with the delayed ack as before, so I figured Paul's performance fixes had addressed that somewhat (they definitely helped tremendously for receiving data). In any case, it's good that you are taking a scientific approach to addressing this. I personally think that slirp is a great idea for networking, for most uses, because it's totally in userspace, etc., etc. But let's keep in mind that the original code was designed to meet the performance criteria of a serial line ;) The work you are doing should help in bringing that more up to date. I'd be glad to help with any testing if/when you have patches. Thanks, Leo Reiter Kenneth Duda wrote: > 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. >> > > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center Main: +1 512 339 7979 Fax: +1 512 532 6501 http://www.win4lin.com