CSCI P545 – E&RTS Lab – Questions

Lab 1

• I see that main() runs a non-terminating while(true) loop. Why doesn't this loop consume 100% of the CPU time?

  COMMENTS.

  • Open a term window and enter a ps aux command. You will see that there are many Linux processes runing concurrently with the driver.

  • Enter a top command. You will see that the square program consumes far less than 100% of the CPU.

  • The while(true) loops in both square-raw and square_sensor.run(), and all drivers, communicate using file operations. All file operations put the calling process to a "waiting" state, so these loops are not CPU dominated, in any case. The Operating System will schedule other "ready" processes before returning to this one.

    More specifically, the os_fstat(clock_fd) call at the beginning of the loop in square_raw, and likewise within CartFS Sensor class does an implicit wait, blocking the caller until the beginning of the next SyncFS cycle. This is accomplished by a modified version of the standard Linux fstat() file operation.

  ---

• I added statements to square_raw.py for saving telemetry data. At the beginning of main() I open two files:

  f1 = open("latlng.txt", "a"); f2 = open("serror.txt", "a");

  Within the while loop:

  try: while True: ...... f1.write(str(gps['lat']) + " " + str(gps['lon']) + "\n"); f2.write(heading_error + "\n");

  ... When I run this code in the simulator for one lap, I always get incomplete data in my log files, about 80 records (gps points) for one lap. However, when I just use print() function to standard output, the problem is gone, and I get around 370 records (gps points) per lap. So is this because of some real-time constrains inside that while loop? Is the file.write() function is too resource consuming?

  COMMENTS.

  • At the beginning of main() all drivers relocate to the directory /tmp/cartfs. This is a special, memory-mapped directory, mounted to use the SyncFS file access protocols. One should not create telemetry data files in this directory. Data files should be created in the disk-based file systems, for instance

    f1 = open("/u/userid/square-log.txt", "a");

    I cannot be sure without additional experimentation, but the special file-I/O protocols in /tmp/cartfs may cause missed writes. In any case, creating data files in this area will result in dynamic memory allocation, which is highly undesirable.

  • One should write all the telemetry data to a single file so that telemetry generated in a single cycle is properly aligned. It is a good idea to include clock['clock'] so that one can track the "ticks". For example,

    f1.write(clock['clock'] + " " + str(gps['lat']) + " " + str(gps['lon']) + " " + str(heading_error) + "\n");

  • When you encounter problems like this it is very useful (to both me and you) to plot the position data (lat/lon) in order to so see the pattern of missed writes.

  • There is nothing wrong with using standard output for printing telemetry, for instance

    print clock['clock'], gps['lat'], gps['lon'], str(heading_error)

    You can re-direct this to a file, and use the Linux tail By the way, did you know that you can suppress the new-line by addint a comma at the end of the print-list? command to watch it. Or at the end of the run, copy-paste the term window into a file.

  • Saving telemetry to a file on a cycle-by-cycle basis will disrupt execution of the driver because disk-I/O interferes with program execution. A better way to record telemetry is to save it to a list, or better yet a pre-allocated array, and dump it to a file at the end of the test. No test in the Laboratory Project runs longer than 30 minutes. At 10 Hz, this translates to 30⋅60⋅10 = 18,000 cycles. If each record is 100 bytes long, then you would need to reserve about 2 Mbyte of storage for telemetry—not much on the notebook computers we use.