Re: USB performance bug since kernel 2.6.13 (CRITICAL???)
From: Open Source
Date: Thu Oct 12 2006 - 16:57:12 EST
Yes, I am pretty sure you are right about the timing. But it shouldn't be that way. If it is, then there's a bug.
I'm fully willing to accept there is something else I should be doing driver-wise, but it shoudn't require recompiling the stock distribution kernels. Otherwise, Linux is not competitive with Microsoft Windows in this regard!
I'll try a recompile and report back. In the meantime, if anyone else has any ideas, please let me know!
Gopal
----- Original Message ----
From: Lee Revell <rlrevell@xxxxxxxxxxx>
To: Open Source <opensource3141@xxxxxxxxx>
Cc: linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
Sent: Thursday, October 12, 2006 1:19:12 PM
Subject: Re: USB performance bug since kernel 2.6.13 (CRITICAL???)
On Thu, 2006-10-12 at 13:05 -0700, Open Source wrote:
> Hi,
>
> Thanks for the rapid response! But...I'm a bit confused. Why is there any software OS timer involved at all? Bulk messages should be scheduled by the host controller and for USB 2.0 the microframe period is 125 us. When I submit an URB, it should be sent to the host controller and scheduled for the next microframe. When the URB completes I should get an interrupt from the hardware. Hence, my transactions (WRITE followed by READ) should at worst be approximately 250 us plus some overhead to process the transaction itself, provided there aren't any other time consuming processes running on my OS. My overhead is less than 250 us. I was willing to tolerate 1 ms per transaction, but 4 ms just doesn't make any sense. Therefore I'm not sure if CONFIG_HZ is an appropriate excuse for this issue.
>
I don't know, it just seemed likely because 1ms vs 4ms is close to the
change in the timer tick rate. Try it.
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/