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

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: [email protected] [mailto:[email protected]] On Behalf Of Erik Rull
Sent: 2009年3月19日 5:42
To: [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

index 89b357e..618c911 100644
@@ -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);
 }
 

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