🚀 go-pugleaf

In article <PCG.92Aug6153327@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:

>   No, something is badly wrong. Are you sure your read(2) calls are in
>   large units (this matters *a lot*!), say each read(2) is for an entire
>   50KB frame?

Yes. Everything else would be too troublesome to program.

>   Are you sure you have "properly" setup the filesystem parameters?

>   Are you sure the disks's and the controller's parameters are also
>   properly setup (e.g. enabling the read ahead buffer in the disk)?

It was done under advice of SGI, Munich....

   adams> You are right, the application stores data in files. It does not
   adams> read from raw disk.

>   But the SGI filesystem is famously efficient in the sense that it
>   delivers almost all the raw disk bandwidth. Sequential read rates of
>   well over 1MB/s are easily observed (and 1MB/s at 50KB/frame is already
>   20 frames/s). Indeed the SGI filesystem is so well done that it delivers
>   almost all the raw speed in random reads too.

So they hoped, but it would not work ....

Interestingly most we talked to did _NOT_ observe 1MByte/s for large
data blocks, but fairly less. 

>   I get well over 300KB/s on a 400 MB SCSI disk reading from the
>   filesystem on my lowly 386, and I would get more if the SVR4 driver had
>   less appalling overheads. The original BSD FFS was getting 300KB/s reads
>   too, or one third of total bandwidth, ten years ago on a VAX-11/780.

1) Do you refer to SCSI on a VAX 11/780? Sure there was one controller,
but our VAX-guys were less than satisfied with its performance and 
dumped it 12 years ago, superseded by an SMD-E-controller from Emulex 
together with approbriate disks. Improved I/O by a factor of 10....

2) Most disk controllers by DEC were microcoded and very intelligent, 
weren't they?

Details lost, as VAX 11/780 has been dumped meanwhile.

best, adams