Date: Fri, 22 Mar 2002 18:55:43 -0500 (EST)
   From: Dan Streetman <[EMAIL PROTECTED]>

   On Fri, 22 Mar 2002, David Brownell wrote:

   >> 1. The problem, according to my crude user-space measurements using
   >>    gettimeofday(), is that a bulk transfer of 4096 bytes takes
   >>    approximately 70 milliseconds to complete.  Does this seem
   >>    reasonable?  It seems like a very long time for such a small amount
   >>    of data.
   >
   >Yes it does seem rather long.  4KBytes is 64 max size packets
   >(of 64 bytes each) which would (optimistically) fit neatly into
   >four frames (19 packets each) with space left over ... one frame
   >per millisecond, by definition.
   >
   >So you're seeing about 64 milliseconds too long, if you assume
   >best case ... and typical case, on an unloaded USB, should be
   >only a few frames short of best case even with a slow HC.
   >
   >I'll not speculate where that extra delay comes from, but I'd
   >suspect it's outside of the USB layer (so bigger I/O sizes
   >could give you better throughput).

   If the userspace program does any sleeping at all (even usleep) it
   will be asleep for at least 10ms, due to the kernel (scheduler) timer
   being periodic every 10ms.  Still, 70ms is quite long, unless you're
   sleeping 6 different times...

Well, I did some more experiments, in particular, applying a patch to
eliminate the 4k limit (see below).  Surprisingly, eliminating the
limit and changing my program to use 0xfe00 length bulk transfers
(exactly the same length as used by Creative's Windows software) had
almost no effect on throughput, which increased from 55 kB/s to only
61 kB/s.  The Windows 2000/XP performance is about 500 kB/s, although
it drops to 190 kB/s when I am using sniffusb.  The sequences of
control and bulk transfers used by my program are identical to those I
observe with sniffusb.

I will have to do some more work to figure out what is going on.

Meanwhile, though, if eliminating the 4k limit seems like a good idea,
may I suggest applying this patch to the kernel?

Chris


--- linux-2.4.18/drivers/usb/devio.c.~1~        Fri Nov  2 20:18:58 2001
+++ linux-2.4.18/drivers/usb/devio.c    Sat Mar 23 14:32:35 2002
@@ -573,6 +573,8 @@
        int len2;
        unsigned char *tbuf;
        int i, ret;
+       unsigned int pages_needed;
+       unsigned int order;
 
        if (copy_from_user(&bulk, (void *)arg, sizeof(bulk)))
                return -EFAULT;
@@ -587,9 +589,14 @@
        if (!usb_maxpacket(dev, pipe, !(bulk.ep & USB_DIR_IN)))
                return -EINVAL;
        len1 = bulk.len;
-       if (len1 > PAGE_SIZE)
-               return -EINVAL;
-       if (!(tbuf = (unsigned char *)__get_free_page(GFP_KERNEL)))
+       pages_needed = (len1 + (PAGE_SIZE - 1)) / PAGE_SIZE;
+       order = 0;
+       while ((1 << order) < pages_needed) {
+               if (order == MAX_ORDER)
+                       return -EINVAL;
+               order += 1;
+       }
+       if (!(tbuf = (unsigned char *)__get_free_pages(GFP_KERNEL, order)))
                return -ENOMEM;
        tmo = (bulk.timeout * HZ + 999) / 1000;
        if (bulk.ep & 0x80) {

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to