usb-linux.c - delay between USB URBs

usb-linux.c - delay between USB URBs

[Erik Rull]

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

RE: usb-linux.c - delay between USB URBs

[Xin, Xiaohui]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

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

[-- Attachment #2: usb.diff --]
[-- Type: application/octet-stream, Size: 797 bytes --]

diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 89b357e..618c911 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -1022,7 +1022,10 @@ static void uhci_frame_timer(void *opaque)
 {
     UHCIState *s = opaque;
     int64_t expire_time;
+    int count = 0;
 
+    while ( count < 200 )
+    {
     if (!(s->cmd & UHCI_CMD_RS)) {
         /* Full stop */
         qemu_del_timer(s->frame_timer);
@@ -1050,10 +1053,11 @@ static void uhci_frame_timer(void *opaque)
     uhci_process_frame(s);
 
     uhci_async_validate_end(s);
-
+    count++;
+    }
     /* prepare the timer for the next frame */
     expire_time = qemu_get_clock(vm_clock) +
-        (ticks_per_sec / FRAME_TIMER_FREQ);
+        (ticks_per_sec / ( FRAME_TIMER_FREQ * 200) );
     qemu_mod_timer(s->frame_timer, expire_time);
 }
 

Re: usb-linux.c - delay between USB URBs

[Erik Rull]

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