Previous

Next

Real-Time File I/O

Real-Time file I/O means that the time needed by a read or write operation can be predicted, or at least an upper bound for this time can be guaranteed. It does not necessarily imply that the I/O operation must be fast, although many real-world applications will also require high speed.

To achieve real-time performance, a number of prerequisites must be satisfied:

• Single file operation
  To avoid the need for the drive's head to seek to different areas on the disk, other files on the same device must not be accessed while real-time file I/O is in progress. The only exception could be files on physically different devices which do not share any resources with the device hosting the real-time file. For example, during a real-time read from an IDE drive, access to a diskette would be allowed.
• Use of contiguous files
  Again, to avoid extra seeks, the file must reside in a single chain of clusters. Such files can be allocated using function RTFExtend. Please note, however, that RTFExtend itself is not real-time. Its time requirement depends heavily on the degree of fragmentation of the volume and the number and current state of the buffers.
• FAT and directory data must be in the buffer cache
  RTFiles-32 must keep track of where the next read or write operation for a file will occur. The directory data and FAT data for the file is required for this. To avoid extra seek and read operations during real-time file I/O, this data must be in the buffer cache. The buffer cache must be large enough to hold this data and the data must have been explicitly loaded before the real-time access starts. RTFiles-32 API function RTFGetFileInfo with flag RTF_FI_ALLOC_SIZE or RTF_FI_CLUSTER_CHAINS set guarantees to load this data into the buffers.
• Access should be sector-aligned
  To avoid displacing sectors from the buffer cache and to best utilize the device's performance, data should be read and written sector-aligned (i.e., the file pointer should always be a multiple of the sector size) and the size of data blocks should also be multiples of the sector size.
• The CPU must be fast enough
  The device driver must be able to keep up with the device to make best use of the device's throughput. This may not be possible for systems using a slow CPU and a fast hard disk. When a device driver misses a deadline (e.g., reacts too late when the device requests processing with an interrupt), a complete rotation of the disk may be required to restart the operation. Performance may suffer dramatically in such a situation.
• I/O must execute at highest task priority
  If the real-time file I/O is performed in a multithreaded program, it must run at the highest priority of all tasks. If this is not the case, another task might get the CPU time when the device driver would need it, causing it to miss a deadline.
• Device access must be error-free
  Most devices or device drivers will perform retries when read or write errors occur on a device. Usually, each retry will require at least one additional disk rotation.
• The device must always be ready
  Some devices may periodically be unavailable. For example, a diskette needs an extra delay when its motor(s) must be started or a hard disk might perform internal recalibration at unknown and uncontrollable times.

If all of the conditions listed above are met, the worst case time for a read or write operation will require the following times:

The disk controller has to seek to the desired track. Since we are assuming contiguous access, a maximum of one track must be seeked, so we will assume the drive's track-to-track seek time.

The disk controller must wait for a specific mark on the disk to pass the read/write head. For example, diskettes have an index hole near the innermost track for this purpose. This operation can take up to one disk rotation.

The disk controller has to count passing sectors until the sector on the track at which the access should start reaches the read/write head. This operation can take up to one rotation.

Contiguous reading or writing is now possible until the head must move to the next cylinder. In a worst-case scenario, this will be only a single sector. However, a second seek operation will occur only after a complete cylinder is processed.

To seek to the next cylinder, the drive's track-to-track seek time plus 1 rotation is required to find the index hole.

Thus, the complete time can be calculated as:

StartupTime

Time to find the first sector

Worst case: track-to-track seek time plus two rotations

SeekTime

Number of seeks during the transfer

Worst case: Integer of (CylinderSize + DataSize - 2 * SectorSize) / CylinderSize

The time requirement per seek is the maximum of one rotation and the drive's track-to-track seek time.

TransferTime

Time to read or write the data

DataSize / BytesPerTrack / RotPerSec (rotations per second)

Example:

A block of 4k size must be written to a 1.44M floppy disk. This diskette type rotates at six rotations per second, stores 9k per track, and has two tracks per cylinder. The track-to-track seek time is assumed to be equal to the time of one disk rotation (1/6 seconds). It is assumed that the drive's motor is still turned on from a previous disk access and that the read/write head is positioned one track before the track the first sector is written to:

If 1M of data is written, the following times would apply:

Advanced Topics

Optimizing for Best Data Security

Using RTFiles-32 with RTTarget-32