From mboxrd@z Thu Jan 1 00:00:00 1970 From: Erik Rull Subject: Re: usb-linux.c - delay between USB URBs Date: Thu, 19 Mar 2009 23:32:08 +0100 Message-ID: <49C2C7E8.9090202@rdsoftware.de> References: <49C16A98.8040708@rdsoftware.de> Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "kvm@vger.kernel.org" To: "Xin, Xiaohui" Return-path: Received: from moutng.kundenserver.de ([212.227.126.186]:62920 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762038AbZCSWcM convert rfc822-to-8bit (ORCPT ); Thu, 19 Mar 2009 18:32:12 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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 t= he 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 year= s old :-) Best regards, Erik Xin, Xiaohui wrote: > Erik, > Did you use uhci or ehci controller in qemu? If uhuci, then > Don=A1=AFt know we are met the same issue or not. May you try the pat= ch to see if it has some effect or not? We observe it has effect on nat= ive qemu side. >=20 > The patch is simple but experimental, you may try to modify the "coun= t" number as you need to see a effect. >=20 > Thanks > Xiaohui >=20 > -----Original Message----- > From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On= Behalf Of Erik Rull > Sent: 2009=C4=EA3=D4=C219=C8=D5 5:42 > To: kvm@vger.kernel.org > Subject: usb-linux.c - delay between USB URBs >=20 > Hello, >=20 > my problem is still the same - the USB key has only a transfer rate o= f ~ 2=20 > MB / min through the virtualization. >=20 > So I did some debugging in usb-linux.c - first I switched on debuggin= g. > The debug output was way to much so I added a timestamp calculation b= etween=20 > a) start and end of async transfer and b) end of one and start of the= next=20 > block (each block is 64 bytes large). > The transfer rate of the driver itself is ~ 200kByte / sec - quite fi= ne and=20 > much faster than the complete chain (only ~32kByte / sec). > The delay between one and the next packet is ~2msec (transfer of 2MBy= te=20 > from USB key to HDD measured)! that means, 64 bytes are transferred t= hen a=20 > pause of nearly 2msec is placed and then the next 64 bytes are sent t= o the=20 > driver. This fits nearly exactly my measured transfer rate of 32kByte= /sec=20 > (64 Bytes / 2msec =3D> 32kByte / sec). >=20 > Where do the 2 msec come from? I have no real other processes running= that=20 > could interfere here. In the Windows guest there is nothing else but = the=20 > windows explorer and some other standard processes running. > Any Idea where to continue searching for these 2msecs?? >=20 > Best regards, >=20 > Erik >=20 > -- > 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