Conference rusure::math

1132.0. "Seeking fine structure info on I/O applications" by EAGLE1::BEST (R D Best, sys arch, I/O) Thu Sep 28 1989 15:53

Our group has been asked to try to estimate the I/O requirements
for some future MSB platforms.

If anyone has analysed the 'fine structure' of applications
that perform moderate to intensive I/O, or done extensive runs
of such an application to analyse performance, I would like to be
in contact with them.  By 'fine structure', I mean the flow and quantity
of computation and I/O (what the program does, how much computing,
what algorithms, how much I/O, when, and where to/from).

If you contact me, please be a bit patient, since I'm still in the stage
of figuring out exactly what kind of data I should collect across
applications to produce meaningful results.

Our internal client wants to hear statements like 'if you achieve
B Mbytes/s and L s latency for QIOs, from I/O device type T,
you will meet the requirements of P percent of your customers'
for various values of P like 50, 80, and 95, and varying values of T
like Ethernet, and {name-a-disk-subsystem}.

Also, I'm looking for source code for real applications that make
moderate to intense I/O demands.  Of particular interest is code that
would normally be considered I/O bound, although scientific/engineering
applications with moderate I/O demands (e.g. off-line seismic event
deconvolution) are by no means excluded, and real-time applications should
definitely be represented.

Ideally, source code should be available (so I can analyse it),
and we should be able to compile and run it on a VAX (i.e. written in something
for which we have a readily available compiler).  I can read (with varying
degrees of comfort) Pascal, C, Fortran, Basic, Forth, Lisp, Prolog, Ada,
and VAX/Macro.  I'm unfortunately (fortunately?) unfamiliar with COBOL.

I think the first requirement (source code availability)
is the more important, since we can probably roughly estimate I/O load from
looking at the program, once we get a bit of experience.

			Thanks,
			/R Best, Eagle1::Best

I forgot to mention that the emphasis is on applications that will be
common in the future; for example, transaction processing, symbolic algebra(?),
large system simulation, tomography calculations, etc.