more "disk" IO comparisons
David Mathog
While this has mostly served to illustrate just how badly VMS sucks at this
particular type of fundamental operation it has also turned up a few
surprises. For instance:
On Tru64 these tests run at exactly the same speed on a DS10 as a DS20
A 466 Mhz DS10 is as fast, or faster, than an Itanium Blazer running at 666 Mhz.
I don't have access to a P4 or 1.2 Ghz Athlon running Linux - if any of you do
please run the benchmarks on those. (On WNT or W2k would be ok too.)
The new read file caching present in 7.3FT can be compared to a a 7.2-1
system without any file caching.
The DS20 supposedly has twice the memory bandwidth of a DS10, and when
running on Unix mostly what this test measures is memory bandwidth and file
cache efficiency. I think what this is telling us is that each CPU on a
DS20 has the same bandwidth as that of a DS10, but that both can run at
full speed. Which doesn't help here because the code is single threaded.
Or maybe there's some other explanation. But I was really expecting the
DS20 to be twice as fast as the DS10.
You may pick up the programs and full results from:
http://seqaxp.bio.caltech.edu/pub/SOFTWARE/mybenchmark.zip
After my signature is the current summary table found in
[.systems]AAA_COMPARISON_TABLE.TXT See AAA_README.TXT in the distribution
for a description of the various programs.
David Mathog
mat...@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech
**************************************************************************
* RIP VMS *
**************************************************************************
This is a table showing MYBENCHMARK speeds on a variety
of platforms. Times shown are in seconds. The tests are
from the MYBENCHMARK suite which measure various aspects
of "disk" I/O and file caching performance.
Tests to local disks and/or through file cache or RAMdisk:
maketestf mystart myread mysplit Disk OS Hardware
Notes maketest myopenin myopen mysplitbinary
--------------------------------------------------------------------------------
2 - 0.33 0.01 0.01 0.17 0.17 0.41 1.14 /tmp Linux64 Blazer Itanium (666Mhz)
3 - 0.42 0.00 0.00 0.28 0.24 0.64 0.62 /tmp RH 7 Proliant 550 (450Mhz)
5 0.90 0.40 0.00 0.00 0.20 0.20 0.70 1.30 /tmp SunOS 5.7 Ultra60 (360 Mhz)
7 2.90 0.20 0.00 0.00 0.10 0.10 0.50 0.30 /tmp Tru64 DS10L (466 Mhz)
9 3.40 0.20 0.00 0.00 0.10 0.10 0.60 0.30 /tmp Tru64 DS20 (500 Mhz)
12 1.46 0.29 0.00 0.00 0.14 0.11 0.40 0.37 /tmp RH 6.2 DS10 (466 Mhz)
16 - 0.43 0.01 0.01 0.30 0.64 1.10 0.97 RAM VMS 7.2-1 DS10 (466 Mhz) (FASTRMS)
11 19.85 1.36 0.02 0.01 0.20 4.46 7.76 7.94 local OVMS7.3FT DS10L (466 Mhz) (FASTRMS)
15 - 1.77 0.02 0.04 0.47 9.05 16.62 14.38 local VMS 7.2-1 DS10 (466 Mhz) (FASTRMS)
14 - 26.46 0.11 0.01 0.54 7.75 46.51 39.10 local VMS 7.2-1 DS10 (466 Mhz) (Vanilla)
Tests to networked disks:
maketestf mystart myread mysplit Disk OS Hardware
Notes maketest myopenin myopen mysplitbinary
--------------------------------------------------------------------------------
1 - 2.29 0.01 0.01 1.14 1.40 5.49 4.67 NFS Linux64 Blazer Itanium (666Mhz)
4 1.20 0.70 0.00 0.00 3.60 0.50 1.70 3.80 NFS SunOS 5.7 Ultra60 (360 Mhz)
6 3.50 1.50 0.00 0.00 0.10 2.10 6.00 4.70 NFS Tru64 DS10L (466 Mhz)
8 3.50 1.40 0.00 0.00 0.10 2.20 6.20 4.70 NFS Tru64 DS20 (500 Mhz)
10 35.57 34.33 0.03 0.02 0.20 5.55 43.27 40.24 MSCP OVMS7.3FT DS10L (466 Mhz) (FASTRMS)
1. Linux64 on a Blazer Itanium (666Mhz) - the Compaq testdrive system.
Using /home (NFS mounted from spe253) . 08-FEB-2001
2. Linux64 on a Blazer Itanium (666Mhz) - the Compaq testdrive system.
Using /tmp . 08-FEB-2001
3. RedHat7 on a Proliant 5500 (450Mhz) - the Compaq testdrive system.
Using /tmp . 08-FEB-2001
4. SunOS 5.7 on an Ultra60 (360 Mhz) - the Caltech ITS "clyde" system.
Using /home (NFS mounted). 02-MAR-2001
5. SunOS 5.7 on an Ultra60 (360Mhz) - the Caltech ITS "clyde" system.
Using /tmp. 02-MAR-2001
6. Tru64Unix 5.1 on a DS10L (466Mhz) - the Compaq testdrive system.
Using /usr/bin/time on the login directory which is on /home, which
in NFS mounted and served from "spe253". 08-FEB-2001
7. Tru64Unix 5.1 on a DS10L (466Mhz) - the Compaq testdrive system.
Using /usr/bin/time on the /tmp directory. 08-FEB-2001
MAKETESTF: Creating test file, fortran
8. Tru64Unix 5.1 on a DS20 (500Mhz) - the Compaq testdrive system.
Using /usr/bin/time on the login directory which is on /home, which
in NFS mounted and served from "spe253". 08-FEB-2001
9. Tru64Unix 5.1 on a DS20 (500Mhz) - the Compaq testdrive system.
Using /usr/bin/time on the /tmp directory. 08-FEB-2001
MAKETESTF: Creating test file, fortran
10. OpenVMS 7.3 field test on a DS10L (466Mhz) - the Compaq testdrive system.
Using USER1 login directory which is served from VMSSERV which is
an AlphaServer 1200 5/400 and the device is a DEC RZ1CB-CA.
FASTRMS variant of these programs. 08-FEB-2001
11. OpenVMS 7.3 field test on a DS10L (466Mhz) - the Compaq testdrive system.
Using $2$DKA100, which is a SCSI disk on "spe202". Using FASTRMS
variants. 09-FEB-2001
12.Redhat 6.2 on a DS10 (466Mhz U2W disks) - my "barrel" system,
Using /usr/bin/time on the /tmp directory. 08-FEB-2001
14. OpenVMS 7.2-1 on a DS10 (466 Mhz U2W disks). "seqaxp" system.
RMS set to defaults. No FASTRMS settings.
15. OpenVMS 7.2-1 on a DS10 (466 Mhz U2W disks). "seqaxp" system.
RMS set to defaults. FASTRMS settings.
16. OpenVMS 7.2-1 on a DS10 (466 Mhz U2W disks). "seqaxp" system.
RMS set to defaults. FASTRMS settings. On a RAMDISK
Paul Repacholi
> I've run the "mybenchmark" disk/file IO speed tests on a variety of
> systems. While this has mostly served to illustrate just how badly
> VMS sucks at this particular type of fundamental operation it has
> also turned up a few surprises. For instance:
> On Tru64 these tests run at exactly the same speed on a DS10 as a
> DS20 A 466 Mhz DS10 is as fast, or faster, than an Itanium Blazer
> running at 666 Mhz.
> The DS20 supposedly has twice the memory bandwidth of a DS10, and
> when running on Unix mostly what this test measures is memory
> bandwidth and file cache efficiency. I think what this is telling
> us is that each CPU on a DS20 has the same bandwidth as that of a
> DS10, but that both can run at full speed. Which doesn't help here
> because the code is single threaded. Or maybe there's some other
> explanation. But I was really expecting the DS20 to be twice as
> fast as the DS10.
The DS/ES systems use a cross point switch between CPUs, memory and
IO. Your bench mark is point bandwidth limited by the CPU, as total
memory BW is greater than CPU bandwidth. If you run 2 copys on a DS20
you will get to or closer to the memory limit.
For the DS20 to have twice the BW of the 10, the memory must be able
to sustain greater than twice the CPU bandwidth. Equal won't quite cut
it due to cache probes victims etc.
No suprise it's faster than the bubbler...
--
Paul Repacholi 1 Crescent Rd., +61 (08) 9257-1001 Kalamunda. West
Australia 6076 Raw, Cooked or Well-done, it's all half baked.