linux-kernel - Re: USB performance bug since kernel 2.6.13 (CRITICAL???)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Oct 2006 13:56:51 -0700 (PDT)
From:	Open Source <opensource3141@...oo.com>
To:	Lee Revell <rlrevell@...-job.com>
Cc:	linux-usb-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: USB performance bug since kernel 2.6.13 (CRITICAL???)

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@...-job.com>
To: Open Source <opensource3141@...oo.com>
Cc: linux-usb-devel@...ts.sourceforge.net; linux-kernel@...r.kernel.org
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/