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

["Leonardo E. Reiter" <lreiter@win4lin.com>]

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 <lreiter@win4lin.com> 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
> 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