Using PCIe & intelligent DMA to achieve blazing data rates in real-time recording instruments
RAID considerations
The challenge in selecting the best RAID controller lies in finding one that reliably meets the sustained streaming write and read requirements of the system. Developers can capitalize on the off-the-shelf RAID host bus adaptors’ (HBA) inherent features including selectable RAID level control and automated disk recovery facilities.
Additionally, these high-performance RAIDs provide user-selectable parameters, such as cache size, caching method, stripe size, command queuing and other settings that allow the user to maximize the performance of the recorder.
In multi-channel recorders, it is often beneficial to create multiple RAID drives, consisting of different disks for each channel, but controlled by the same RAID controller. By assigning independent logical drives to the recorder’s channels, the RAID is able to write to contiguous disk space as much as possible.
It is also important to recognize the non-linearity of hard disk drives (HDD) when developing a recorder. Since the density of an HDD remains constant through the disk and the rotation speed remains constant, the read and write rates of a disk fall as HDD accesses move from the outer edge of the disk to the inner edge. This can be seen in Figure 2 below, since disks present their logical addressing from the outer edge to the inner edge, disk read and write rates fall as a disk fills up.
Figure 2 - HD Tune Plot showing the disk data rate, as it changes throughout the physical drive.
RAIDs, built on several disks provide similar non-linearity in their data rates. Because of this, it is imperative that the system developer either provide enough drives in the RAID to meet the maximum data rate requirement for the entire volume, or limit the size of the drive volume to the percentage of disk space that will meet the system’s data rate requirements.
In the case of a RAID with the performance shown in Figure 2 above, if the system developer was required to build a recorder that could maintain 500 MB/sec, the drive volume should be formatted to use about fifty percent of the total disk space. This is done simply by formatting the drive to the appropriate size within the operating system.
Operating system tasks
When dealing with non-real-time operating systems like Windows and Linux, it is important to minimize the operating system’s impact on the recording application. The amount of processor intervention in the recording software can be minimized by dedicating the data transfers to the DMA controllers and simply leaving the processor to manage the data flow. The developer should also elevate the priorities of real-time tasks within the application and keep background tasks at lower priorities to avoid impacting the recorder’s performance.
GUI control is a must
When designing a real-time recorder, it is important to provide the user a control interface that is intuitive and easy to use. The easiest way to achieve this is through a graphical user interface (GUI.)
A GUI provides the user with the ability to control the recorder by pushing virtual buttons with a mouse or via a touch screen, providing a simple and satisfying out-of-the-box experience. The GUI should allow the user to, not only control the recorder, but also provide: ongoing status updates to the user; facilities to manage the data files; and utilities to monitor and analyze the signals being recorded.
The GUI should have the ability to run either locally on the recorder or remotely on an independent PC or other device. Being able to run on a remote device allows the user to put the recorder in an environment that may not be appropriate for the operator. This allows the recorder to be close to the sensor or antenna source, placing the A/D or digital I/O interface near the signal of interest.
The best way to provide both local and remote control of the recorder is through a client-server architecture. This architecture provides a socket-based communication link between the client GUI and the server recording application, separating the real-time portion of the recorder (the server) from the non-real-time portion (the client.) The client can then connect to the server, whether the client sits on the server PC itself or on a PC that is connected to the server over Ethernet.
By sending messages to the server, the client GUI can control all aspects of the recorder. This includes the ability to start and stop recordings, to setup front-end hardware parameters, to monitor incoming signal information and to request status information from the server. The interface for this messaging structure should be defined in an Application Programming Interface (API).
Loading comments... Write a comment