ceforge.net;
WolfgangMües <[EMAIL PROTECTED]>; linux-kernel@vger.kernel.org
Sent: Friday, October 13, 2006 4:41:44 PM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13
(CRITICAL???)
Ar Gwe, 2006-10-13 am 16:02 -0700, ysgrifennodd Open Source:
> clear understanding of
l@lists.sourceforge.net
Sent: Saturday, October 14, 2006 12:58:33 PM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13
(CRITICAL???)
On Sat, 14 Oct 2006 11:07:37 -0700 (PDT), Open Source <[EMAIL PROTECTED]> wrote:
> 4) The process "sleeps" to wait for the disk
On Sat, 14 Oct 2006 11:07:37 -0700 (PDT), Open Source <[EMAIL PROTECTED]> wrote:
> 4) The process "sleeps" to wait for the disk.
> (No other processes are running so only the idle loop
> is running at this point.)
> 5) An interrupt triggers back from the disk.
> 6) The process wakes up.
>
> Now i
lists.sourceforge.net
Sent: Saturday, October 14, 2006 10:09:03 AM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13
(CRITICAL???)
On Saturday 14 October 2006 18:40, Open Source wrote:
> I'm not so sure about that. Once the interrupt is finished being
> serviced,
On Saturday 14 October 2006 18:40, Open Source wrote:
> I'm not so sure about that. Once the interrupt is finished being
> serviced, the scheduler should immediately wake up
> and service any blocked processes rather than sitting
> idle for one CONFIG_HZ period (4 ms when CONFIG_HZ=250).
> At leas
AIL PROTECTED]>
To: linux-usb-devel@lists.sourceforge.net
Sent: Friday, October 13, 2006 11:53:35 PM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13
(CRITICAL???)
On Saturday 14 October 2006 01:02, Open Source wrote:
> Either the problem is in the ehci code or in devio.c
Open Source <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>; USB development list
; Kernel development list
Sent: Friday, October 13, 2006 7:11:39 PM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13
(CRITICAL???)
On Sat, 14 Oct 2006, Alan Cox wrote:
> A
On Saturday 14 October 2006 01:02, Open Source wrote:
> Either the problem is in the ehci code or in devio.c. In
> devio.c the user space process calls an ioctl to reap the
> urb (blocking until it is complete). The asynchronous
> callback for the urb is called when the urb is unlinked
> and that
On Sat, 14 Oct 2006, Alan Cox wrote:
> Ar Gwe, 2006-10-13 am 16:30 -0700, ysgrifennodd Open Source:
> > There is an ioctl that is waiting for the URB to be reaped.
> > I am almost certain it is this syscall that is taking 4 ms (as
> > opposed to 1 ms with CONFIG_HZ=1000).
>
> What does strace say
Ar Gwe, 2006-10-13 am 16:30 -0700, ysgrifennodd Open Source:
> There is an ioctl that is waiting for the URB to be reaped.
> I am almost certain it is this syscall that is taking 4 ms (as
> opposed to 1 ms with CONFIG_HZ=1000).
What does strace say about it ? This is measurable not speculation.
>
On Friday 13 October 2006 12:31 pm, Open Source wrote:
>
> It seems like the unlinking of completed URBs
> happens asynchronously on a timer. This is a
> surprise to me since I thought this was happening
> on an IRQ from the host controller. But if what I'm
> surmising is correct it would explai
-usb-devel@lists.sourceforge.net;
WolfgangMües <[EMAIL PROTECTED]>; linux-kernel@vger.kernel.org
Sent: Friday, October 13, 2006 4:41:44 PM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13
(CRITICAL???)
Ar Gwe, 2006-10-13 am 16:02 -0700, ysgrifennodd Open Source:
>
Ar Gwe, 2006-10-13 am 16:02 -0700, ysgrifennodd Open Source:
> clear understanding of what is causing it. As it stands it doesn't
> seem like even the experts know exactly where this
> delay is being caused.
strace should tell you precisely how long each syscall takes if you ask
it to trace thing
sb-devel@lists.sourceforge.net;
linux-kernel@vger.kernel.org
Sent: Friday, October 13, 2006 2:08:46 PM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13
(CRITICAL???)
On Fri, 13 Oct 2006, Open Source wrote:
> Hi Wolfgang (and all),
>
> Thanks for the input. Howev
On Fri, 13 Oct 2006, Open Source wrote:
> Hi Wolfgang (and all),
>
> Thanks for the input. However, I am not understanding
> exactly why kernel mode is treated any differently than
> user mode for this sort of thing. I am looking at the code
> in ehci-q.c and ehci-hcd.c.
>
> It seems like the
Hi,
On Friday 13 October 2006 21:31, Open Source wrote:
> Thanks for the input. However, I am not understanding
> exactly why kernel mode is treated any differently than
> user mode for this sort of thing. I am looking at the code
> in ehci-q.c and ehci-hcd.c.
>
> It seems like the unlinking of
On 10/13/06, Open Source <[EMAIL PROTECTED]> wrote:
> p.s. My apologies about the word wrap. I'm using
> a different mail client than my usual one and didn't
> realize it was not wrapping automatically.
Why all the cloak and dagger? You could at least make up a real name.
Bob
least be
as good as Windows, right?
Hopefully we can get this sorted out.
Cheers.
- Original Message
From: WolfgangMües <[EMAIL PROTECTED]>
To: linux-usb-devel@lists.sourceforge.net
Sent: Friday, October 13, 2006 12:11:08 PM
Subject: Re: [linux-usb-devel] USB performance bug sinc
On Friday 13 October 2006 19:20, Open Source wrote:
> Alan -- yes, I understand the ability to increase throughput
> by transfering more bytes and I am definitely able to see
> better overall throughput when increasing the number
> of bytes per transaction. However, I needs to still have
> good tr
On Fri, 13 Oct 2006, Open Source wrote:
> Hi all,
>
> I just tested using CONFIG_HZ_1000=y and
> CONFIG_HZ=1000 and as expected, this change
> improves the throughput. Thank you Lee for pointing
> that out so quickly.
>
> Alan -- yes, I understand the ability to increase throughput
> by transfe
: Alan Stern <[EMAIL PROTECTED]>
To: Open Source <[EMAIL PROTECTED]>
Cc: linux-usb-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
Sent: Friday, October 13, 2006 6:56:31 AM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13
(CRITICAL???)
[FYI, it would make thi
[FYI, it would make things easier for the rest of us if you can convince
your email client to wrap lines before 80 columns.]
On Thu, 12 Oct 2006, Open Source wrote:
> Hi all,
> I am writing regarding a performance issue that I recently observed
> after upgrading from kernel 2.6.12 to 2.6.17.
On Thursday 12 October 2006 17:26, Lee Revell wrote:
> On Thu, 2006-10-12 at 13:56 -0700, Open Source wrote:
> > 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 sh
On Thu, 2006-10-12 at 13:56 -0700, Open Source wrote:
> 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 recompili
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 com
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
>
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 sched
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 c
(Resending because [EMAIL PROTECTED] bounced right back to me. Sorry for the
multiple messages!)
- Forwarded Message
From: Open Source <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
Sent: Thursday, October 12, 2006 12:21:56 PM
Subject: USB performance bug since
29 matches
Mail list logo
