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

[Leonardo E. Reiter]

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 <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.
> >
> > 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
> address@hidden
> 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