![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: I'm involved with a magnetic fusion experiment that stores about 5 Mbytes of data in a burst every few minutes up to about 200 times a day. When the data is stored a number of processes access it right away. I am looking for a way to make this data access quicker. I was hoping there is a way to set up a cache that holds maybe the last 100 Mbytes of data written to a disk in memory. Any suggestions? The Answer is : RMS global buffering and XFC, or XFC, particularly given sufficient physical memory for buffers and sufficient (though slower) disk storage, and reasonable process quotas. Five megabytes of cached data is well within the XFC design and expectations, in terms of the available potential XFC cache size and the associated cache speed. RMS files and global buffering provides a simple, effective, and fast way to access the data -- and provides the interlocking that is often found necessary. Custom-written schemes generally do not initially provide interlocking, and this omission tends to cause application problems over time -- and a need to retrofit the locks and the multi-processor (and potentially clustering) capabilities. The use of RMS global buffers does assume use of RMS records and record operations. RMS global buffers do not cache block operations. Use of XFC is default for all virtual I/O and does cache RMS record and block operations, as well as any $qio or $qiow using virtual I/O operations, for all I/O operations with the upper transfer size limit (for purposes of XFC caching) determined by the VCC_MAX_IO_SIZE system parameter. You will want to discuss details of the application and its requirements with HP services folks or other knowledgeable folks specializing in this design area. Details such as the penalty for data drops -- does the data stream recover from transient data loss, for instance -- the timeliness requirements for getting the data to disk, for the immediacy of access to the data from other processes, the value of the data itself, the responsiveness of the processor and contention requirements and restrictions, storage and I/O hardware, and various other aspects all affect this and most any other real-time design.
|