[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Network Performance between Win Host and Linux

From: Leonardo E. Reiter
Subject: Re: [Qemu-devel] Network Performance between Win Host and Linux
Date: Tue, 11 Apr 2006 17:58:18 -0400
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)

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.


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.


On 4/11/06, Leonardo E. Reiter <address@hidden> 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.


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]