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

["Kenneth Duda" <kduda@arastra.com>]

I was confused by the comments around the delaying of acks.  Delaying
these acks didn't make intuitive sense to me and is inconsistent with
RFC 2581, which states:

   ... a TCP receiver MUST NOT excessively delay
   acknowledgments.  Specifically, an ACK SHOULD be generated for at
   least every second full-sized segment, and MUST be generated within
   500 ms of the arrival of the first unacknowledged packet.

I have implemented things so that acks are never delayed, which is
simplest and seems fine in the environment where I imagine
slirp-within-qemu is being used (simulated ethernets).  I'm interested
in other viewpoints.

    -Ken


On 4/11/06, Leonardo E. Reiter <lreiter@win4lin.com> wrote:
> 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 <lreiter@win4lin.com> 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
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>