linux-kernel - Re: ehci-hcd affects hda speed

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:	Tue, 15 Apr 2008 22:24:17 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	"Lev A. Melnikovsky" <melnikovsky@...l.ru>
CC:	Alessandro Suardi <alessandro.suardi@...il.com>,
	David Brownell <david-b@...bell.net>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: ehci-hcd affects hda speed

On 15-04-08 21:56, Lev A. Melnikovsky wrote:

> Sorry, I had virtually no time to answer earlier. If (hopefully) someone 
> is still interested, here's my feedback

Interested yes, although being no longer in posession of the hardware it's a 
somewhat academic interest...

> I have repeated experiments with P3B-F and VT6212L combination (to 
> improve visibility the AsyncSchedSleepTime is set to 1us):
> 
> #0. Nothing is connected to USB, no ehci-hcd loaded
>       hda throughput 28+-1MB/s
> 
> #1. ehci-hcd loaded, still no USB peripherals
>       hda throughput 28+-1 MB/s
> 
> #2. Something (USB hub and FLASH drive tested) is attached
>       hda throughput 15+-1 MB/s
> 
> #3. All USB peripherals are removed
>       hda throughput 15+-1 MB/s
> 
> #4. ehci-hcd is rmmod'ed
>       hda throughput 28+-1MB/s
> 
> The oddest peculiarity for me is the hysteretic difference between #1 and 
> #3 states. I mean experimental data (hda throughput) depends not on the 
> state (hardware/loaded modules), but on the path we followed.

On the chip having inited itself at least. Yes, your results match what I 
experienced.

> Interestingly enough, sampling registers (via /sys) often shows Async bit 
> set of the status register in the state #3. It is always cleared in #1. 
> The async file is empty in both states. I wonder, how many degrees of 
> freedom does an empty schedule have? Does "empty" mean "has no incomplete 
> requests" or "has no requests at all"? Just guessing...

Should leave this up to David, but as far as I'm aware "no at all".

> RH> The sleep time wasn't the core problem, so I wonder of later VIA chips do
> RH> still have the active async schedule problem...
> I don't think this is purely VIA problem. I did not _try_ to install that 
> VT6212L card into newer motherboard, but my _feeling_ is that we see an 
> "incompatibility" between older PCI mobo chipsets and VIA USB controller.

I very much doubt that. Can't really imagine an off-silicon reason the chip 
would keep scanning the async schedule. I'm also now using a NEC controller 
card in that same machine and it also shows no problems.

> Actually, taking into account superior PCI bandwidth of modern PCs (if 
> compared with my old P3B-F motherboard) I am not sure we can perform a 
> clean reliable test without PCI bus analyzer.

http://lkml.org/lkml/2005/5/30/259

> 
> -l
> 

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