Path: utzoo!attcan!uunet!husc6!uwvax!rutgers!bellcore!faline!thumper!ulysses!andante!alice!dmr
From: dmr@alice.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Vax 11/780 performance vs Sun 4/280 performance
Message-ID: <7980@alice.UUCP>
Date: 14 Jun 88 04:21:17 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 35

After decribing a lot of the grot you have to go through to get
3MB/s out of an MVS system, Barry Shein wrote,

> But don't underestimate raw, frothing, manic hardware.
> It's a big trade-off, large IBM mainframes are to I/O what Crays are
> to floating point...

Crays are better at I/O, too.  For example,
I made a 9947252-byte file by catting 4 copies of the dictionary
and read it:

3K$ time dd bs=172032 </tmp/big >/dev/null
57+1 blocks in
57+1 blocks out
	seconds
elapsed	1.251356
user	0.000639
sys	0.300725

which is a cool 8MB/s read from an ordinary Unix file in competition
with other processes on the machine.  (OK, I gave it a big buffer.)
The big guys would complain that they didn't get the full 10 or 12
MB/s that the disks give.  They would really be annoyed that I could
get only 50 MB/s when I read the file from the SSD, which runs at
1000MB/s, but to get it to go at full speed you need to resort to
non-standard Unix things.

The disk format on Unicos (Cray's version of SVr2) is an extent-based
scheme supporting the full Unix semantics except that they don't handle
files with holes (that is, the holes get filled in).  In an early
version, a naive allocation algorithm sometimes created files
ungrowable past a certain point, but I think they've worked on the
problem since then. 

				Dennis Ritchie