linux-kernel - Re: [linux-usb-devel] 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Oct 2006 14:02:57 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Open Source <opensource3141@...oo.com>
cc:	linux-usb-devel@...ts.sourceforge.net,
	<linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13
 (CRITICAL???)

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 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 transaction-level timing because I cannot always
> queue the transactions up.  Recall that each transaction
> is a WRITE followed by a READ.  The results of the
> READ determine the outgoing bytes for the following
> transaction's WRITE.
> 
> Not to sound like a broken record, but there is something
> seriously wrong here.  This has to be a bug somewhere.
> It could be very well just be something as simple as
> issuing the right incantation with libusb, devio, etc.  But,
> I've been using libusb for years now and am at a loss
> on what might have changed to require this.
> 
> Any ideas???

Try using usbmon to get a detailed record of events with high-precision
timestamps.  Maybe also add similar logging to your program.  This may
suggest some ideas about where the slowdown originates.

It's possible that some process you're unaware of is using the CPU, and 
the reduced clock rate increases the latency for your process to continue 
running.

Alan Stern

-
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/