On Wed, 24 Mar 2004, Pat LaVarre wrote:
> > the sizeable benefit David was
> > talking about really applies only to high-speed devices. Full-speed
> > devices won't notice the difference nearly as much.
>
> Loosely paraphrased, I see you saying we feel 80% of the pain in HS, so
> naturally I as
Pat LaVarre wrote:
David B:
Thanks for your interest.
In practice, I haven't yet proven that any of my devices actually do
benefit from a max GB/cdb greater than 0.65536 while an fs is
mounted ...
You mean, 64 KByte/request?
Probably yes. Sorry I don't know what a "request" is. Do you
David B:
Thanks for your interest.
In practice, I haven't yet proven that any of my devices actually do
benefit from a max GB/cdb greater than 0.65536 while an fs is
mounted ...
You mean, 64 KByte/request?
Probably yes. Sorry I don't know what a "request" is. Do you already
know what a "
the sizeable benefit David was
talking about really applies only to high-speed devices. Full-speed
devices won't notice the difference nearly as much.
Loosely paraphrased, I see you saying we feel 80% of the pain in HS, so
naturally I ask:
Do we get 80% of the interop benefit if we choke off byt
On Wed, 24 Mar 2004, David Brownell wrote:
> Pat LaVarre wrote:
>
> > In practice, I haven't yet proven that any of my devices actually do
> > benefit from a max GB/cdb greater than 0.65536 while an fs is
> > mounted ...
>
> You mean, 64 KByte/request? I'm curious what the relevant number
Pat LaVarre wrote:
In practice, I haven't yet proven that any of my devices actually do
benefit from a max GB/cdb greater than 0.65536 while an fs is
mounted ...
You mean, 64 KByte/request? I'm curious what the relevant number
is for IDE or SATA... and how disk and page caching affect it.
T
Well, since ... Linux slow things down significantly by
default, I'd want to see a better answer than "end-users can manually
make them fast again" ...
Of course, "breaks at rated speed" could be a quirk too ... and
if Linux emitted a message for those devices, maybe their vendors
would eventually
Matthew Dharm wrote:
On Thu, Mar 18, 2004 at 08:17:00PM -0800, David Brownell wrote:
Pat LaVarre wrote:
Agreed, shattering a read/ write stream into miniscule pieces improves
interop at small cost to typical usage of much storage.
It improves interop, yes ... but that cost would only be small
for
On Thu, Mar 18, 2004 at 08:17:00PM -0800, David Brownell wrote:
> Pat LaVarre wrote:
> >Agreed, shattering a read/ write stream into miniscule pieces improves
> >interop at small cost to typical usage of much storage.
>
> It improves interop, yes ... but that cost would only be small
> for full s
Pat LaVarre wrote:
Agreed, shattering a read/ write stream into miniscule pieces improves
interop at small cost to typical usage of much storage.
It improves interop, yes ... but that cost would only be small
for full speed devices. It's called "de-tuning", or "pessimizing"
(contrast "optimizing"
Agreed, shattering a read/ write stream into miniscule pieces improves
interop at small cost to typical usage of much storage.
Sorry I mistook the words "I wonder if we shouldn't reduce max_sectors
permanently" as a disavowal of your cogent discussion:
We should let people who want more perform
On Thu, Mar 18, 2004 at 12:09:45PM -0700, Pat LaVarre wrote:
> Matt D:
>
> >>>Subject: Re: [usb-storage] Re: [linux-usb-devel] unneeded subclass
> >>>error in driv er
> >>>Try changing max_sectors in linux/drivers/usb/storage/scsiglue.c to a
> >>>smaller number (i.e. 16 or 32 or 64) and see if th
12 matches
Mail list logo
