Re: USB performance bug since kernel 2.6.13 (CRITICAL???)
- From: Lee Revell <rlrevell@xxxxxxxxxxx>
- Date: Thu, 12 Oct 2006 16:19:12 -0400
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/
- References:
- Re: USB performance bug since kernel 2.6.13 (CRITICAL???)
- From: Open Source
- Re: USB performance bug since kernel 2.6.13 (CRITICAL???)
- Prev by Date: Re: Userspace process may be able to DoS kernel
- Next by Date: Re: 2.6.19-rc1 regression: unable to read dvd's
- Previous by thread: Re: USB performance bug since kernel 2.6.13 (CRITICAL???)
- Next by thread: Re: USB performance bug since kernel 2.6.13 (CRITICAL???)
- Index(es):