Pi Zero Real Time FIFO Scheduling

Now we can try the same test but with FIFO real time scheduling selected.

To do this we need to use the sched_setscheduler function:

sched_setscheduler(pid,SCHED_FIFO,&priority);

where pid is the thread id - if zero then the calling thread is used.

The second parameter sets the type of scheduling used FIFO in this case and the final parameter is a pointer to a structure that specifies the priority. 

Notice you need to include <sched.h> to make use of the scheduling functions.

The modified program is: 

#include <bcm2835.h>
#include <stdio.h>
#include <sched.h>

int main(int argc, char **argv) {
 const struct sched_param priority = {1};
 sched_setscheduler(0, SCHED_FIFO, &priority);

 if (!bcm2835_init())
   return 1;
 bcm2835_gpio_fsel(RPI_GPIO_P1_07 ,
 BCM2835_GPIO_FSEL_OUTP);
 while (1) {
  bcm2835_gpio_write(RPI_GPIO_P1_07 , HIGH);
  bcm2835_gpio_write(RPI_GPIO_P1_07 , LOW);
 }
 bcm2835_close();
 return 0;
}

 

If you run this program you will discover that the result are very different. The first thing you might notice if you have a console open is that the response is very sluggish. The reason is that your program is hoging the CPU.

If you run a logic analyzer then there is a surprise.

The program runs for one second and then it is interrupted for around 50ms.

Clearly there is something with a higher priority is now interrupting your program and probably keeping the console and other essentials alive. 

If you now run a cpu hoging task you will discover that there is no change in the behavior of your program. It runs for a second and then is interrupted for 50ms.  There is no 10ms switching between tasks - your program still gets a full 1 second of uninterrupted cpu time and this is irrespective of the cpu load.

You can also try locking the programs memory to stop the system from paging it if other applications need a lot of memory. In practice this isn't a common occurrence on a device like the Raspberry Pi but if you do need to do it then all you need is a call to mlock in sys/mman.h and to unlock to unlock it. You can lock the current memory or future memory allocations. In most cases it is sufficient to lock current memory unless you are using dynamic memory allocation. 

mlockall(MCL_CURRENT);

In the case of our test program locking memory make no difference as there is plenty of real memory to go around. 

Pi 2  Quad Core 900MHz

The single core Pi Zero has to share its single core even with a high priority FIFO process. The quad core Pi 2 and Pi 3 should behave differently because they have three cores to work with after you monopolize a whole core with your program. 

Lets see how things work with a Pi 2. 

First lets try the program without real time features. With a lightly loaded Pi 2 we have the usual 0.08 to 0.1 microsecond pulses with the usual 0.6 microsecond pulse every 0.125ms and 15 microsecond pulse every 10ms. 

When you add cpu hoging processes then at about four processes irregular 10ms pulses start to appear

The 10ms pulses correspond to periods of time when the program is swapped out and not running. It isn't regular because the four cores are shared between each of the processes. 

If you change the program to use realtime FIFO scheduling then with the same cpu load that produced the 10ms pulses you get a result that looks like a lightly loaded CPU. That is the 10ms pulses vanish and all you have to contend with are the 0.6 microsecond and 15 microsecond interruptions. 

The reason for this behavior is fairly obvious. Now your process can be run by one of the cores while the remaining three are shared between the other non-realtime processes. 

Thus for a Pi 2 or 3 near realtime Linux works better than for a single core Pi Zero or Pi 1. 

For a Pi 2 or 3 you can reasonably expect to respond within 15 microseconds. 

Practical FIFO Scheduling

Adding a simple statement makes your program hog one of the available processor cores and removes the long interruptions that occur when other threads are scheduled to run. 

You might think at this point that the best thing to do is set a maximum priority and use FIFO scheduling as soon as your program is loaded. However hogging a single core on a Raspberry Pi can have some undesirable effects. 

To avoid these it is a good idea to only enable FIFO scheduling when it is absolutely needed or to use the yield command at regular intervals.

For example if you are writing a program that has to decode an incoming pulse stream then using FIFO scheduling for the time it actually does the decoding is the best option. After the decoding is complete return to SCHED_OTHER, 

It is true that no amount of scheduling is going to convert the Raspberry Pi into a real time system. The reason is that it is not real time hardware and not configured to be. There are things the CPU has to do to keep the Pi running and these cannot be disabled. 

The best you can achieve with the Pi Zero is to effectively lock your task into its single core an keep the CPU uninterrupted for a one second period and accept the 50ms interrupt. You can only guarantee to respond to external events in 50ms. Of course you still have the  .5 microsecond interrupts every 1.25ms to take into account but unless you are working with below 1 microsecond timings these are not usually a problem.

For the quad core Pi 2 and 3 you can use one of the cores to keep your program running and only have the  0.6 microsecond pulse every 0.125ms and 15 microsecond pulse every 10ms to worry about. 

So we really do have near real time Linux if not actual real time Linux.

 

 

 

Related Articles

Real Raspberry Pi - Getting Started And Custom NOOBS