2003-08-19 04:52:57

by Nayak, Samdeep

[permalink] [raw]
Subject: Linux SCSI benchmarking tool??

Hi,

I am trying to benchmark a iSCSI driver for performance on a 2.4 kernel. I
have used dd, dt, IOmeter and rawio utilities so far and each seemed to
represent a different picture to me on the same setup (Single target with
few LUNS). (DD showed good performance on an ext2 mounted file system till
I realized that I was writing to the buffer and not writing on the raw
drive). Since I am trying to catch up with the SCSI world, I am just
wondering if any one else has tried any other utilities that would provide
better results or am I doing something wrong here??

-Thanks in advance,

-Regards
Samdeep



2003-08-19 05:05:32

by Nuno Silva

[permalink] [raw]
Subject: Re: Linux SCSI benchmarking tool??

Hi!

Nayak, Samdeep wrote:

[..snip..]

> I realized that I was writing to the buffer and not writing on the raw

The simple solutions is to boot with 16MB of RAM :)
Just append RAM=16M to linux's command line (in lilo...) and use large
sets of data.

Regards,
Nuno Silva


2003-08-19 05:03:46

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: Linux SCSI benchmarking tool??

On Mon, 18 Aug 2003 21:52:54 PDT, "Nayak, Samdeep" <[email protected]> said:

> have used dd, dt, IOmeter and rawio utilities so far and each seemed to
> represent a different picture to me on the same setup (Single target with
> few LUNS). (DD showed good performance on an ext2 mounted file system till
> I realized that I was writing to the buffer and not writing on the raw
> drive). Since I am trying to catch up with the SCSI world, I am just
> wondering if any one else has tried any other utilities that would provide
> better results or am I doing something wrong here??

Those tools report different things because they are measuring different
aspects of the performance. For many system configurations, the fact that 'dd'
is writing on a buffer rather than a drive is actually a *feature*, as you
might care about just how much of a boost the cache is giving you - I don't
care how fast my compile writes to disk, I care how fast the cache and page
subsystems actually present the data to userspace...

"better results" depends on the question - otherwise "42" is as good an answer as
any, for exactly the reasons that Deep Thought gave.... ;)


Attachments:
(No filename) (226.00 B)