public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Erik Rull <erik.rull@rdsoftware.de>
To: "Xin, Xiaohui" <xiaohui.xin@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: usb-linux.c - delay between USB URBs
Date: Thu, 19 Mar 2009 23:32:08 +0100	[thread overview]
Message-ID: <49C2C7E8.9090202@rdsoftware.de> (raw)
In-Reply-To: <C85CEDA13AB1CF4D9D597824A86D2B9001C6C864E9@PDSMSX501.ccr.corp.intel.com>

Hello,

hm - interesting, the performance could be really increased. But only a
little bit - its now around 60kb/sec (okay a factor of nearly 2) - the
average delay is still around 1 msec. Well faster but not at a real USB
limit. I played around with the count value and 10 seems to be one of the best.

Any other Ideas? The Windows XP shows me a pretty old USB Host adaptor, is
there a way to change to a newer one? The chipset is now nearly 11 years
old :-)

Best regards,

Erik


Xin, Xiaohui wrote:
> Erik,
> Did you use uhci or ehci controller in qemu? If uhuci, then
> Don’t know we are met the same issue or not. May you try the patch to see if it has some effect or not? We observe it has effect on native qemu side.
> 
> The patch is simple but experimental, you may try to modify the "count" number as you need to see a effect.
> 
> Thanks
> Xiaohui
> 
> -----Original Message-----
> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On Behalf Of Erik Rull
> Sent: 2009年3月19日 5:42
> To: kvm@vger.kernel.org
> Subject: usb-linux.c - delay between USB URBs
> 
> Hello,
> 
> my problem is still the same - the USB key has only a transfer rate of ~ 2 
> MB / min through the virtualization.
> 
> So I did some debugging in usb-linux.c - first I switched on debugging.
> The debug output was way to much so I added a timestamp calculation between 
> a) start and end of async transfer and b) end of one and start of the next 
> block (each block is 64 bytes large).
> The transfer rate of the driver itself is ~ 200kByte / sec - quite fine and 
> much faster than the complete chain (only ~32kByte / sec).
> The delay between one and the next packet is ~2msec (transfer of 2MByte 
> from USB key to HDD measured)! that means, 64 bytes are transferred then a 
> pause of nearly 2msec is placed and then the next 64 bytes are sent to the 
> driver. This fits nearly exactly my measured transfer rate of 32kByte /sec 
> (64 Bytes / 2msec => 32kByte / sec).
> 
> Where do the 2 msec come from? I have no real other processes running that 
> could interfere here. In the Windows guest there is nothing else but the 
> windows explorer and some other standard processes running.
> Any Idea where to continue searching for these 2msecs??
> 
> Best regards,
> 
> Erik
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



      reply	other threads:[~2009-03-19 22:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-18 21:41 usb-linux.c - delay between USB URBs Erik Rull
2009-03-19  1:37 ` Xin, Xiaohui
2009-03-19 22:32   ` Erik Rull [this message]

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=49C2C7E8.9090202@rdsoftware.de \
    --to=erik.rull@rdsoftware.de \
    --cc=kvm@vger.kernel.org \
    --cc=xiaohui.xin@intel.com \
    /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