From: Rene Herman <rene.herman@keyaccess.nl>
To: David Brownell <david-b@pacbell.net>
Cc: Petr Vandrovec <vandrove@vc.cvut.cz>, Mark Lord <lkml@rtr.ca>,
Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: External USB2 HDD affects speed hda
Date: Thu, 02 Jun 2005 00:24:29 +0200 [thread overview]
Message-ID: <429E359D.8090701@keyaccess.nl> (raw)
In-Reply-To: <200506011337.29656.david-b@pacbell.net>
David Brownell wrote:
>>Added EHCI maintainer to this one as well. If possible, this looks like
>>a good candidate for a /proc or /sys knob?
>
>
> No, it's based on a mis-understanding of the hardware.
>
> The controller should only be doing DMA when some driver has submitted
> an URB and that URB hasn't yet completed. Pretty much like any other
> hardware, like a disk or network controller.
Okay, thanks, and okay, crap. Sounded like a nice, plausible explanation...
> For periodic transfers -- interrupt, isochronous, neither used for
> disk I/O -- the driver issuing the transfer always has control over
> the polling period. But that's mostly related to the USB activity;
> if a periodic transfer is active, then the current segment of the
> periodic schedule has to be scanned (by DMA) every microframe (8x/msec).
> If that segment is empty, that's just one word (32 bits). If there
> are transfers, it's got to read them and maybe perform them.
I see. Well, sort of at least. "Even if the HDD were using periodic
transfers, which it isn't, it would be DMAing 32-bits 8x per msec while
idle, which certainly isn't going to cost 8MB/s bus bandwidth". Right?
Rene.
next prev parent reply other threads:[~2005-06-01 22:29 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
2005-06-01 20:37 ` David Brownell
2005-06-01 22:24 ` Rene Herman [this message]
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=429E359D.8090701@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=david-b@pacbell.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.