🚀 go-pugleaf

adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams) writes:

>In article <nefd2l0@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:

| One group here does video image processing and has to handle a large
| (~GBYTES) data base of frames. These guys relied on the advice of
| Silicon Graphic, Germany and bought a SGI 4Dxxx with SCSI drives.
| (A frame is a mixture of vectors and bitimages.)
| 
| Requirement was, that about 30 frames / second have to be processed.
| Field experience showed that about 2 frames a second could be retrieved,
| yielding a transfer rate of 100 kBytes...

>>   Then something is *seriously* misconfigured, or the app is doing something
>>   silly like using unbuffered stdio (the latter sounds unlikely, given
>>   your later statements).  We haven't had disk i/o that slow in ages, unless
>>   you put really slow disks or i/o cards in the system somehow.

>It has been configured and reconfigured under the advice of
>engineering support from SGI.... Controller and disk came from SGI....

>The application does nothing else than to read in frames, one about
>50 kBytes, unbuffered (simple read()). One hint:  ...  more than
>90% idle, though single user mode!, and drive is kept selected.

In this thread, nobody has asked or volunteered if this app is using
the filesystem or reading from a raw disk. The performance sounds
like the latter, loosing revs all the time. This would also explain
the high idle time percentage.
-- 
| ...!unido!ukw!lupe  (German EUNet, "bang")     |  Disclaimer:            |
| lupe@ukw.UUCP       (German EUNet, domain)     |  As I am self-employed, |
| suninfo!alanya!lupe (Sun Germany)              |  this *is* the opinion  |
| Res non sunt complicanda praeter necessitatem. |  of my employer.        |