From: Rene Herman <rene.herman@keyaccess.nl>
To: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Mark Lord <lkml@rtr.ca>,
Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
Linux Kernel <linux-kernel@vger.kernel.org>,
David Brownell <dbrownell@users.sourceforge.net>
Subject: Re: External USB2 HDD affects speed hda
Date: Wed, 01 Jun 2005 21:45:13 +0200 [thread overview]
Message-ID: <429E1049.20903@keyaccess.nl> (raw)
In-Reply-To: <429E0965.1090809@vc.cvut.cz>
Petr Vandrovec wrote:
> Rene Herman wrote:
>> No, that's not it. Both ide0 (14) and EHCI (3) are on private,
>> unshared IRQs. rmmodding ehci_hcd as per Pavel's sugestion gets me
>> back my speed. Exactly _why_ I've no idea though. I've just added you
>> to the CC on that reply...
>
>
> Because EHCI hardware continuously watches some memory area to
> find whether there are some transfers from host to your USB
> devices ready... You just need better memory bandwidth so all
> your devices transfers fit on your bus. Or maybe EHCI driver
> could program hardware to not query transfer descriptors
> that often. But it would increase latency for people
> who use USB only and do not care about other parts of system.
I see. I was totally unaware of that, many thanks for the information.
Getting more memory bandwidth (to/from the PCI bus at least) will have
to wait for my next system, I suppose.
Added EHCI maintainer to this one as well. If possible, this looks like
a good candidate for a /proc or /sys knob?
Or maybe even starting out with a low querying frequency and dynamically
adjusting it up (and down again!) with traffic? Probably not that. I'd
like to have the knob though, so that I can have EHCI builtin and still
tell the controller to take it easy (certainly after I've switched of
the external HDD again, but on this system possibly also while in use).
Rene.
next prev parent reply other threads:[~2005-06-01 19:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-30 23:21 External USB2 HDD affects speed hda Rene Herman
2005-06-01 8:18 ` Pavel Machek
2005-06-01 18:25 ` Rene Herman
2005-06-01 19:40 ` David Brownell
2005-06-01 22:14 ` Rene Herman
2005-06-01 22:33 ` Rene Herman
2005-06-01 23:43 ` David Brownell
2005-06-02 1:23 ` Mikulas Patocka
2005-06-02 2:17 ` David Brownell
2005-06-02 13:19 ` Rene Herman
2005-08-05 22:34 ` Rene Herman
2005-09-17 2:36 ` David Brownell
2005-09-17 14:45 ` Rene Herman
2005-12-12 23:24 ` Rene Herman
2005-06-02 13:57 ` Lennart Sorensen
2005-06-02 13:11 ` Rene Herman
2005-06-02 20:37 ` Lennart Sorensen
2005-06-02 22:49 ` Grant Coady
2005-06-02 23:56 ` Rene Herman
2005-06-03 0:54 ` David Brownell
2005-06-01 11:48 ` Mark Lord
2005-06-01 18:30 ` Rene Herman
2005-06-01 19:15 ` Petr Vandrovec
2005-06-01 19:45 ` Rene Herman [this message]
2005-06-01 20:37 ` David Brownell
2005-06-01 22:24 ` Rene Herman
2005-06-01 23:40 ` David Brownell
-- strict thread matches above, loose matches on Subject: below --
2005-12-21 7:08 Helmut Toplitzer
2005-12-21 8:10 ` Rene Herman
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=429E1049.20903@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=dbrownell@users.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@rtr.ca \
--cc=vandrove@vc.cvut.cz \
/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