From: Open Source <opensource3141@yahoo.com>
To: Lee Revell <rlrevell@joe-job.com>
Cc: linux-usb-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: USB performance bug since kernel 2.6.13 (CRITICAL???)
Date: Thu, 12 Oct 2006 13:05:27 -0700 (PDT) [thread overview]
Message-ID: <20061012200527.14579.qmail@web58107.mail.re3.yahoo.com> (raw)
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.
Besides, Windows is now more than twice as fast out of the box than Linux when it comes to this particular type of USB usage. We can't have that can we? :-) Linux used to be fast and the only difference with my recent experiences is the kernel version.
Best regards,
Still Beleagered Open Source Fan
----- Original Message ----
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
Sent: Thursday, October 12, 2006 12:55:55 PM
Subject: Re: USB performance bug since kernel 2.6.13 (CRITICAL???)
On Thu, 2006-10-12 at 12:33 -0700, Open Source wrote:
> I am using a device that submits URBs asynchronously using the libusb
> devio infrastructure. In version 2.6.12 I am able to submit and reap
> URBs for my particular application at a transaction rate of one per
> millisecond. A transaction consists of a single WRITE URB (< 512
> bytes) followed by a single READ URB (1024 bytes). Once I upgrade to
> version 2.6.13, the transactional rate drops to one per 4
> milliseconds!
The kernel's internal tick rate was lowered from 1000Hz to 250Hz
starting with 2.6.13. Rebuild with CONFIG_HZ=1000 and the performance
should return to normal.
Lee
next reply other threads:[~2006-10-12 20:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-12 20:05 Open Source [this message]
2006-10-12 20:19 ` Lee Revell
-- strict thread matches above, loose matches on Subject: below --
2006-10-14 16:33 Open Source
2006-10-13 23:30 Open Source
2006-10-14 0:24 ` Alan Cox
2006-10-13 19:31 Open Source
2006-10-12 20:56 Open Source
2006-10-12 21:26 ` Lee Revell
2006-10-13 12:12 ` Ed Tomlinson
2006-10-12 19:33 Open Source
2006-10-12 19:55 ` Lee Revell
2006-10-12 19:21 Open Source
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061012200527.14579.qmail@web58107.mail.re3.yahoo.com \
--to=opensource3141@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=rlrevell@joe-job.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®