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

[Leonardo E. Reiter]

Ken,

I'll check that on Linux-on-Linux... it's likely just some Windows 
overhead.  Windows is my guest OS priority, which is why I tested on 
Windows.

As for getting patches into the mainline, this is a job for the 
maintainers.  Fabrice is the main person, but Paul Brook also merges a 
lot of patches in.  I'm not sure what their process is, or to what 
extent they communicate with each other.  I'm sure Paul and/or Fabrice 
would be kind enough to explain.  I agree that there are lots of pending 
patches... in the case of yours specifically though, since it's so 
sweeping, I would guess that it probably needs more field testing before 
it becomes mainline.

Regards,

Leo Reiter

Kenneth Duda wrote:
> Leo, thank you for exercising this stuff.
>
>
> > 1. before your patches, the upstream transfers (guest->host) consumed
> > almost no CPU at all, but of course were much slower.  Now, about half
> > the CPU gets used under heavy upstream load.
>
>
> I am surprised that only half the CPU gets consumed --- that suggests
> there's another factor of two improvement waiting to be made.  If you
> see anything like this with Linux-on-Linux, please let me know and
> I'll try to track it down.
>
> Separately, I'm curious about the path for getting these changes into
> the qemu mainline.  If that's something you're in tune with and are in
> the mood to summarize for me, I'd appreciate that.  We love qemu but
> there are some rough edges and I think we have something like 16
> patches we're maintaining internally, many of which might be helpful
> for others.
>
>      -Ken
>
> On 4/12/06, Leonardo E. Reiter <address@hidden> wrote:
>
> > Hi Ken,
> >
> > (all) the patches seem to work very well and be very stable with Windows
> > 2000 guests here.  I measured some SMB over TCP/IP transfers, and got
> > about a 1.5x downstream improvement and a 2x upstream improvement.  You
> > will likely get more boost from less convoluted protocols like FTP or
> > something, but I didn't get around to testing that.  Plus it's not clear
> > how much Windows itself is impeding the bandwidth.  I am using
> > -kernel-kqemu.
> >
> > 2 additional things I noticed:
> >
> > 1. before your patches, the upstream transfers (guest->host) consumed
> > almost no CPU at all, but of course were much slower.  Now, about half
> > the CPU gets used under heavy upstream load.  The downstream, with
> > Windows guests at least, consumes 100% CPU the same as before.  I
> > suspect you addressed this specifically with your select hack to avoid
> > the delay if there is pending slirp activity
> >
> > 2. overall latency "feels" improved as well, at least for basic stuff
> > like web browsing, etc.  This is purely subjective.
> >
> > Nice work!  I'll be testing with a Linux VM soon and try to pin down
> > some better benchmarks, free of Windows clutter.
> >
> > - Leo Reiter
>
>
>
> _______________________________________________
> 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