Subject: Re: USB performance bug since kernel 2.6.13 (CRITICAL???)
From: Lee Revell <rlrevell@joe-job.com>
To: Open Source <opensource3141@yahoo.com>
Cc: linux-usb-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
In-Reply-To: <20061012200527.14579.qmail@web58107.mail.re3.yahoo.com>
References: <20061012200527.14579.qmail@web58107.mail.re3.yahoo.com>
Content-Type: text/plain
Date: Thu, 12 Oct 2006 16:19:12 -0400
Message-Id: <1160684353.24931.79.camel@mindpipe>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1237
Lines: 16

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/