qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Kenneth Duda" <kduda@arastra.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: Network Performance between Win Host and Linux
Date: Wed, 12 Apr 2006 11:19:27 -0700	[thread overview]
Message-ID: <6fe044190604121119r5a161123s77c0d7d13beaa637@mail.gmail.com> (raw)
In-Reply-To: <443D0909.3090806@win4lin.com>

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

  reply	other threads:[~2006-04-12 18:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-11 17:20 [Qemu-devel] Network Performance between Win Host and Linux Kenneth Duda
2006-04-11 17:28 ` Paul Brook
2006-04-11 17:49   ` Kenneth Duda
2006-04-11 18:19     ` Helmut Auer
2006-04-12  2:10       ` Kazu
2006-04-11 20:40     ` Leonardo E. Reiter
2006-04-11 21:46       ` Kenneth Duda
2006-04-11 21:58         ` Leonardo E. Reiter
2006-04-11 22:42           ` Kenneth Duda
2006-04-11 21:00     ` Leonardo E. Reiter
2006-04-11 22:36 ` [Qemu-devel] " Kenneth Duda
2006-04-12 14:04   ` Leonardo E. Reiter
2006-04-12 18:19     ` Kenneth Duda [this message]
2006-04-12 18:26       ` Leonardo E. Reiter
2006-04-12 14:31   ` Leonardo E. Reiter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6fe044190604121119r5a161123s77c0d7d13beaa637@mail.gmail.com \
    --to=kduda@arastra.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).