Real-Time Linux for TrackCam - Revision history

JamesYeung: /* Implementations of Real-Time Operating Systems */

2010-06-21T03:41:56Z

Implementations of Real-Time Operating Systems

← Older revision		Revision as of 22:41, 20 June 2010
Line 8:		Line 8:

	==Implementations of Real-Time Operating Systems==		==Implementations of Real-Time Operating Systems==
	There are currently two main methods of implementing a real-time operating system, a micro-kernel approach and a scheduling approach.		There are currently two main methods of implementing a real-time operating system, a micro-kernel approach and a scheduling approach. We will be using an operating system which implements the scheduling approach because it is the operating system that the makers of TrackCam supports.

	===Micro-Kernel===		===Micro-Kernel===

JamesYeung: /* Plotting Data in Real-Time */

2010-06-15T19:56:36Z

Plotting Data in Real-Time

← Older revision		Revision as of 14:56, 15 June 2010
Line 883:		Line 883:
	<br>		<br>
	To compile: gcc main.c -o main -lrt -lnidaqmx<br>		To compile: gcc main.c -o main -lrt -lnidaqmx<br>
			To run:
	~~To run:~~ sudo ./main \| perl ./driveGnuPlotStreams.pl 1 1 50 25000 45000 500x300+0+0 'MotorAngle' 0~~<br>~~		sudo ./main \| perl ./driveGnuPlotStreams.pl 1 1 50 25000 45000 500x300+0+0 'MotorAngle' 0
	Note: You will need to have the script in the same directory.		Note: You will need to have the script in the same directory.
	<pre>		<pre>

JamesYeung: /* Plotting Data in Real-Time */

2010-06-15T19:56:19Z

Plotting Data in Real-Time

Show changes

JamesYeung at 19:55, 15 June 2010

2010-06-15T19:55:45Z

← Older revision		Revision as of 14:55, 15 June 2010
Line 876:		Line 876:

	.		.

			==Plotting Data in Real-Time==
			Here's a version of the PThread Test code that reads the encoder counts at 10kHz for 1 minute and then 5kHz at 1 minute. While it is reading, it will output motor angle at 10Hz. If you pipe this into the driveGnuPlotStream.pl script, it will plot the motor angle in real-time at 10Hz.<br>
			<br>
			Click [http://www.lysium.de/blog/index.php?/archives/234-Plotting-data-with-gnuplot-in-real-time.html here] to download or for more details about the driveGnuPlotStream.pl script.<br>
			<br>
			To compile: gcc main.c -o main -lrt -lnidaqmx<br>
			To run: sudo ./main \| perl ./driveGnuPlotStreams.pl 1 1 50 25000 45000 500x300+0+0 'MotorAngle' 0<br>
			Note: You will need to have the script in the same directory.

	==Future Work==		==Future Work==

JamesYeung: /* PThread Test */

2010-06-15T19:43:28Z

PThread Test

← Older revision		Revision as of 14:43, 15 June 2010
Line 361:		Line 361:
	badtime[xth >30us delay] = actual wakeup time (t = target wakeup time) value = microseconds of delay in this setup<br>		badtime[xth >30us delay] = actual wakeup time (t = target wakeup time) value = microseconds of delay in this setup<br>
	<br>		<br>
	You can download a sample of results [http://hades.mech.northwestern.edu/images/b/b9/RTLinux-PThreadTest-SampleResults.zip here].		You can download a sample of results [http://hades.mech.northwestern.edu/images/b/b9/RTLinux-PThreadTest-SampleResults.zip here].<br>
	<br>		<br>
	To compile: gcc main.c -o main -lrt -lnidaqmx		To compile: gcc main.c -o main -lrt -lnidaqmx

JamesYeung: /* PThread Test */

2010-06-15T19:43:13Z

PThread Test

@@ Line 350: / Line 350: @@
 ===PThread Test===
-This is a test that uses multiple threads where only one is set with a high priority and the rest are normal priority. The high priority thread is also reading one analog signal from a data acquisition card and writing one analog signal to an output card. In this particular test I had four normal priority threads, each continuously performing of the the basic simple math operation (+, -, *, /). This was then tested on a system with a quad core CPU. The four normal priority threads is to ensure that there are more than four active tasks for the CPU to handle. In a true setup, a total of two threads may be enough for your needs. More details about the cards used in this test can be found [http://hades.mech.northwestern.edu/index.php/NI-DAQ_Cards_on_Linux here].
+This is a test that uses multiple threads where only one is set with a high priority and the rest are normal priority. The high priority thread is also reading one analog signal from a data acquisition card and writing one analog signal to an output card. In this particular test I had four normal priority threads, each continuously performing of the the basic simple math operation (+, -, *, /). This was then tested on a system with a quad core CPU. The four normal priority threads is to ensure that there are more than four active tasks for the CPU to handle. In a true setup, a total of two threads may be enough for your needs. More details about the cards used in this test can be found [http://hades.mech.northwestern.edu/index.php/NI-DAQ_Cards_on_Linux here].<br>
 To compile: gcc main.c -o main -lrt -lnidaqmx

JamesYeung: /* Cyclictest */

2010-06-12T20:47:37Z

Cyclictest

← Older revision		Revision as of 15:47, 12 June 2010
Line 720:		Line 720:
	</li>		</li>
	</ul>		</ul>
	The most important number to note in the results is the max because in order to assure hard real-time performance, the system should never have a latency greater than a certain threshold. That threshold would be determined by the frequency of the task that you are trying to perform. For example, if you wanted to perform a task at 100kHz and the worst case latency is 5us, then your task should take no more than 5us since there are only 10us between each consecutive tasks.		The most important number to note in the results is the max because in order to assure hard real-time performance, the system should never have a latency greater than a certain threshold. That threshold would be determined by the frequency of the task that you are trying to perform. For example, if you wanted to perform a task at 100kHz and the worst case latency is 5us, then your task should take no more than 5us since there are only 10us between each consecutive tasks.<br>
	<br>		<br>
	It is interesting to note that when using a priority level of 1 in Cyclictest, we get a much higher max than a priority level of 2 or 80. I still don't have a reasoning for this, but this phenomenon is also apparent in the Homemade Test and PThread Test.		It is interesting to note that when using a priority level of 1 in Cyclictest, we get a much higher max than a priority level of 2 or 80. I still don't have a reasoning for this, but this phenomenon is also apparent in the Homemade Test and PThread Test.

JamesYeung: /* Cyclictest */

2010-06-12T20:44:18Z

Cyclictest

← Older revision		Revision as of 15:44, 12 June 2010
Line 675:		Line 675:
	i = interval in microseconds<br>		i = interval in microseconds<br>
	l = number of times to loop<br>		l = number of times to loop<br>
			<br>
			Outputs:<br>
			T = ?<br>
			P = priority level<br>
			I = interval in microseconds<br>
			C = count (number of tasks performed, this number counts up during the test)<br>
			Min = minimum latency experienced<br>
			Act = current latency (this number changes during the test)<br>
			Avg = average latency experienced<br>
			Max = maximum latency experienced<br>

	<ul>		<ul>
Line 710:		Line 720:
	</li>		</li>
	</ul>		</ul>
	The most important number to note in the results is the max because in order to assure hard real-time performance, the system should never have a latency greater than a certain threshold. That threshold would be determined by the frequency of the task that you are trying to perform. It is ~~interesting~~ to ~~note~~ ~~that when~~ ~~using~~ a ~~priority~~ ~~level~~ of 1 in ~~Cyclictest,~~ we ~~get~~ a ~~much~~ ~~higher~~ ~~max~~ ~~than~~ a ~~priority~~ ~~level~~ of 2 or ~~80.~~ I ~~still~~ ~~don't~~ ~~have~~ a ~~reasoning for this, but this phenomenon is also apparent in the Homemade Test and~~ ~~PThread~~ ~~Test~~.		The most important number to note in the results is the max because in order to assure hard real-time performance, the system should never have a latency greater than a certain threshold. That threshold would be determined by the frequency of the task that you are trying to perform. For example, if you wanted to perform a task at 100kHz and the worst case latency is 5us, then your task should take no more than 5us since there are only 10us between each consecutive tasks.
			<br>
			It is interesting to note that when using a priority level of 1 in Cyclictest, we get a much higher max than a priority level of 2 or 80. I still don't have a reasoning for this, but this phenomenon is also apparent in the Homemade Test and PThread Test.

	===Homemade Test===		===Homemade Test===

JamesYeung: /* Homemade Test */

2010-06-12T19:53:02Z

Homemade Test

← Older revision		Revision as of 14:53, 12 June 2010
Line 713:		Line 713:

	===Homemade Test===		===Homemade Test===
	The results of this test can be summarized and better visualized in histograms. Below are two histograms from each of the two conditions.		The results of this test can be summarized and better visualized in histograms. Below are two histograms from each of the two conditions. It is important to note that these tests were performed with priority level set at 1. The PThread test is a better measure of how real-time the system is.

	[[image:RTLinux_Homemade_Latency_Noload.JPG\|thumb\|500px\|Latencies between target time stamp and recorded time stamp under no-load conditions.\|left]]		[[image:RTLinux_Homemade_Latency_Noload.JPG\|thumb\|500px\|Latencies between target time stamp and recorded time stamp under no-load conditions.\|left]]

JamesYeung: /* Results */

2010-06-12T19:44:40Z

Results

← Older revision		Revision as of 14:44, 12 June 2010
Line 663:		Line 663:
	==Results==		==Results==
	To ensure that the operating system is truly "real-time", I ran the two tests (Cyclictest and Homemade Test) under two conditions, load and no load. The no load condition is simply where except for system processes, only the test programs are running. The load condition is where I compile the source code of OpenCV and the Linux kernel using a niceness of -20.		To ensure that the operating system is truly "real-time", I ran the two tests (Cyclictest and Homemade Test) under two conditions, load and no load. The no load condition is simply where except for system processes, only the test programs are running. The load condition is where I compile the source code of OpenCV and the Linux kernel using a niceness of -20.

			As for the PThread Test, it was run under the no load condition.

	===Cyclictest===		===Cyclictest===
Line 708:		Line 710:
	</li>		</li>
	</ul>		</ul>
	It is interesting to note that when using a priority level of 1 in Cyclictest, we get a much higher ~~Max~~ than a priority level of 2 or 80.		The most important number to note in the results is the max because in order to assure hard real-time performance, the system should never have a latency greater than a certain threshold. That threshold would be determined by the frequency of the task that you are trying to perform. It is interesting to note that when using a priority level of 1 in Cyclictest, we get a much higher max than a priority level of 2 or 80. I still don't have a reasoning for this, but this phenomenon is also apparent in the Homemade Test and PThread Test.

	===Homemade Test===		===Homemade Test===
Line 776:		Line 778:
	.		.

	===~~Pthread~~ Test===		===PThread Test===
			The PThread was run on four different frequencies, 1kHz, 2kHz, 5kHz and 10kHz. Each frequency was tested for 5 hours. I have decided to run the test with the priority level set at 2 due to the unexplained phenomenon of a higher max latency at priority level 1 experienced in the Cyclictest. The graphs below show a histogram of latencies experienced in microseconds. I only kept count of latencies of up to 100us because a latency of 100us or greater would be considered catastrophic. Furthermore, the maximum latency experienced at the start of the test are generally high, so I have decided to discard the first hour as warm up time for the system. However, a one second warm up will be enough in practice since the max latency is experienced within the first one millisecond. The results from test are shown below.
	I used my test program to test "interrupts" of four different frequencies, 1kHz, 2kHz, 5kHz and 10kHz. The results of these test are shown below.

	[[image:RTLinux1kHz.jpg\|thumb\|500px\|Linux-rt delay from wakeup target time at 1kHz.\|left]]		[[image:RTLinux1kHz.jpg\|thumb\|500px\|Linux-rt delay from wakeup target time at 1kHz.\|left]]