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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel