Hello managers,
i've wondered about the measured transferrates of my SCSI-disks.
See below for the answers and my original question.
The answers from the list were in short: everything normal, nothing
to worry about, transferrates of more than 7 MB/sec a only wishful thinking,
values between 3 and 4 are far more realistic today...
What i 've learned was a formula to estimate a maximum transferrate:
the_disks_rpm/60 sec (which is the number of tracks "seen" per second)
* number_of_sectors_per_track
* number_of_bytes_per_sector
= the number of bytes per second that could theoretically be transferred
Thanks again!
Bernt
-------------------------------------------------------------------------
- Bernt Christandl / Max Planck Institut fuer Extraterrestrische Physik -
- D-85740 Garching / Phone: +49/89/3299-3342 / Fax: +49/89/3299-3569 -
- Internet: beb_at_mpe-garching.mpg.de -
-------------------------------------------------------------------------
Gyula Szokoly <szgyula_at_skysrv.Pha.Jhu.EDU> wrote:
> These numbers are not that bad. Check out
>
> http://tarkus.pha.jhu.edu/sysadmin/osf/lsmperf.html
>
> and repeat the calculation for your disk geometry to get the 'nominal'
> values for the disks. The fastest I saw so far was 6.3M/s from a Seagate
> 9G drive (5400 RPM). The 10M/s is the max burst speed of the SCSI interface
> (i.e. controller to controller), not the drive itself.
>
> Gyula
Thomas Leitner <tom_at_finwds01.tu-graz.ac.at> wrote:
(in german, so i try to summarize his words)
> when he benchmarks his disks he does something like
>
> # time dd if=/dev/rrz9c of=/dev/null ibs=1024k obs=1024k count=400
>
> which avoids the influence of the filesystem.
> As an example of a ST32550N
>
> # time dd if=/dev/rrz9c of=/dev/null ibs=1024k obs=1024k count=400
> 400+0 records in
> 400+0 records out
> real 61.6
> user 0.0
> sys 0.2
>
> he gets 400*1024/61.6 = 6649 kB/s, which was nearly what he was
> expecting.
Nick Hill - RAL CISD Systems Group <NMH1_at_axprl1.rl.ac.uk> wrote:
> There are various issues here.
>
> 1) When you copy the file it will go via the UBC memory cache so the size and
> state of the cache may influence the timings. Eg the first copy should be the
> fastest and the later ones longer as writes may have to wait for cache pages
> to be flushed. Similarly when the copy command exits the data will still be
> being written to disk and will actually finish some time later.
>
> 2) Because of (1) above using csh time or /bin/time etc does not give
> accurate times with which to calculate disk transfers. The monitor utility
> or some such utility that looks at internal disk stats structures give a much
> better idea.
>
> 3) SCSI bus speed for slow is 5Mb/s and fast is 10Mb/s. The important word
> here is bus speed. If you have a disk that can sustain write activity at
> 4Mb/s then on the slow bus it might do 4Mb/s and on the fast bus it will do
> 4Mb/s and on a Fast Wide bus with a bandwidth of 20Mb/s it will do 4Mb/s.
> I think you expectations of over 7Mb/s is wishful thinking. Remember disk
> vendors will state that a disk will do max transfer rate of 10Mb/s on a fast
> scsi bus but this is as long as it is coming out of the on disk memory cache.
> Once it has to go and read the data off the platter then it is a different
> story and depends on the disk configuration and disk rpm.
>
> 4) To get maximum I/O rates from SCSI disks you need to have SCSI tag
> command
> queuing (or is it commmand tag queueing :-)) enabled. DIGITAL UNIX enables
> this for disks it recognises and disables it for those that it does not. If
> they are DEC DSP or seagate disks then I would guess that it is disabled. DU
> recognises the DEC rz disk names but not others. For DU prior to 4.0 It can
> be enabled via editing the file /sys/data/cam_data.c and rebuilding the
> kernel. From 4.0 onwards you need a different method which I haven't
> invetsigated.
>
> I am not familiar with the drive types you mention so cannot comment on what
> transfer rates you should see. I have fast wide rz29 disks (7200rpm) on PCI
> based Fast Wide SCSI buses on an alphaserver 8400. These top out at around 6
> to 7 Mb/s write. Segate Elite 9 (5400 rpm) get up to 5.5 with tag queueing
> enabled.
>
> Remeber, once the SCSI bus bandwidth gets above the disk sustainable transfer
> rate then access to a disk will not go any faster. Where you win in going
> from slow to fast and on to fast wide or Ultra scsi is that you can have more
> disks going fast at the same time. For example if you are getting 4Mb/s from
> you disks then you could only have one performing at that rate on your built
> in scsi busses but you should get two going at that rate on the turbochannel
> busses.
>
> Hope this helps,
>
> Nick Hill
My question was:
> Hello managers,
>
> this morning i've installed into my alpha 3000/400 (turbochannel)
> a new double scsi-interface (PMAZC-AA) and configured it to use the FAST
> scsi mode. Anything seems to work fine.
>
> Then (and before) i did some testing. This machine now has the internal,
> the external and 4 additional scsi-interfaces (2 * PMAZB-AA, 2 * PMAZC-AA).
>
> My simple test is as follows: i copy /vmunix (about 9.8 MB) ten times to
> one of my disks and measure the time with the csh-builtin time command.
> This i do ten times and then i "built" from this a mean value.
>
> My disks are digital (dsp5200, dsp5350, dsp5400) and seagate (st15230n)
> and all of them claim to be able to use FAST scsi.
>
> Okay, this night (with only slow scsi but on an idle machine) my mean values
> range from 43.2 sec to 29.7 sec meaning something like 2.2 to 3.2 MB/sec.
> I think the differences result mainly from how full my disks are; there is
> one that is empty and that has the fastest result.
>
> Now today i attach to each of the new fast scsi-interfaces only one disk and
> my mean values, copying from slow-disk to fast-disk range from 24.8 sec
> (3.86 MB/sec) to 38.0 sec (2.52 MB/sec). And copying from the one to the other
> fast disk gives 30.7 sec (3.12 MB/sec) and 36.3 sec (2.64 MB/sec)
>
> Running the monitor-utility while copying shows maximum transferrates of
> only about 4.3 to 4.5 MB/sec.
>
> Is there something wrong? Why don't i see much higher values? At least for
> the latter i'd expect something between 7 and 9 or 10 MB/sec. Is 5 (or 6)
> scsi-buses (with 17 devices most of them nfs-exported) to much for my
> turbochannel?
>
> Any hints or ideas?
Received on Thu Feb 13 1997 - 09:46:11 NZDT