[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: |
Kenneth Duda |
Subject: |
Re: [Qemu-devel] Network Performance between Win Host and Linux |
Date: |
Tue, 11 Apr 2006 15:42:33 -0700 |
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 <address@hidden> 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 <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
>
>
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
[Qemu-devel] Re: Network Performance between Win Host and Linux, Kenneth Duda, 2006/04/11
Re: [Qemu-devel] Re: Network Performance between Win Host and Linux, Leonardo E. Reiter, 2006/04/12