Test table
The “vrbl_to_file” application is a frequently used support application that is invoked from “gp_test” procedures to set a sequence of operating conditions for the engine or test object.
The data files which are read by “vrbl_to_file” have been referred to as “furball” files (a corrupt pronunciation of “vrbl_to_file”). We prefer the name “test_table” files, and you may see that term used in documentation. In addition, “gp_test” is referred to as the “Test Manager” in user manuals.
When launching “vrbl_to_file” you supply an argument that is either “READ” or “READ_ONCE”. This argument controls when and how often the file is read from disk.
READ – The file is read each time “vrbl_to_file” is invoked from a gp_test procedure. The “vrbl_to_file” application reads the file and then searches the file for the specified line index. Since the file is re-read each time “vrbl_to_file” is invoked, it is possible to modify the file “on-the-fly” and have the changes be picked up on the next execution of the test mode.
READ_ONCE – The file is read into the memory area of the “vrbl_to_file” application as soon as the app is launched. Each time it is invoked from the gp_test procedure, the app looks up the line index in the memory buffer and sets the specified variables. Using the READ_ONCE option is required for procedures which run very fast and where a new index is requested at rates of 1hz or faster, such as running an FTP cycle. A re-read of the file is performed only when a new “nt” command is issued for that “gp_test” instance.
THE ISSUE: We have noticed an excessive number of disk accesses to “furball” files in many cells and test rigs which seem to be caused by the use of the “READ” option and executing those test modes frequently. The only reason for using the “READ” option is for the case where you expect to modify the “furball” file during the test. By switching to “READ_ONCE”, you will reduce the number of disk reads. We recommend that you make this modification wherever possible. In the LINUX operating system, the real-time performance of some applications can be adversely affected by a lot of disk I/O.