[rescue] Sun 711

[James Lockwood]

On Fri, 3 May 2002, George Adkins wrote:

> Understood, except that this isn't.  it's a 1 gig file, which has not ben
> pre-read anywhere else, plus there are no other tasks going on.  An Idle
> system with 1 interactive shell executing the commands on an otherwise still
> disk subsystem.  No bursty traffic, no concurrent access of the disks.  I
> already thought about this and did the test under conditions where cacheing
> would not be anything other than the ordinary read-ahead one would get during
> the read process.

You wrote earlier:

] Actually not any benchmark package, just cat some mpegs together and
] split(1) off a 1024*1024 byte chunk and then cat data.file >> target to
] = 1 Gig size.
] Then :
] date;cat data.file > /dev/null;date
] a few times and average the run times to whatever degree of accuracy you
] like... then divide 1024 by the number of seconds to get MB/Sec.

If you have just written this file then it is likely still cached.  The
only way do be sure you are not seeing cache effects is to manipulate data
files far in excess of RAM size, or to directly manipulate an uncached
resource (such as a raw disk device).

> In this case, it's not an illusion, it's flat-out read speed.

Try this:

ptime dd if=/dev/rdsk/c0t0d0s2 of=/dev/null bs=1024k count=1024

(use whatever raw disk device is applicable)

This bypasses filesystem overhead, but fs overhead is seldom a concern for
a single huge sustained I/O.

-James