How to restrict time Linux takes for an action?

Question

Question can look blurry since it's hard to describe a problem in one line so here it goes. I use Debian on Raspberry Pi to run a PID regulator which means dt(time difference between loop executions) is obtained every time PID output is calculated. Basically dt is calculated like this.

    oldtime_ = time_;
    clock_gettime(CLOCK_MONOTONIC, &time_);
    Timer.dt = ((static_cast<int64_t>(time_.tv_sec) * 1000000000 + static_cast<int64_t>(time_.tv_nsec)) - (static_cast<int64_t>(oldtime_.tv_sec) * 1000000000 + static_cast<int64_t>(oldtime_.tv_nsec))) / 1000000000.0;

PID is updated around 400 times a second and it goes just fine, but sometimes Linux decides to take much more time to make an action. The result is a large number of dt, say, not 1/400 = 0.0025 but a 0.8 which is 320 times more than needed. The result is incorrect calculation of PID. That looks like this.

I'd love to have an answer how to move raspbian a little bit closer to a real time system.

EDIT

Thanks, anaken78 and anyone who've helped. Using RR_FIFO schedule worked perfectly and processing speed is always aroud 380-400hz.

Answer 1

I am assuming you are using the original Raspberry pi and not the Raspberry pi 2. The problem with original Raspberry pi is that it uses a single core ARM11 cpu which effectively means that any kind of RT calculation (the way you are doing) are bound to have errors because of hardware interrupts. For e.g., packets coming over the Wifi might interrupt your system, which will cause a problem.

One possible thing you could try, if you are fine with having no network connectivity, is to increase your process priority and shut down your wifi and eth interfaces. These, I would say, are the main sources of asynchronous interrupts that might end up disrupting your process execution. There will be other interrupts that keep firing, you can look at /proc/interrupts and /proc/softirq to get an idea of the interrupts firing, but in a platform like raspberry pi, they should either be priodic (timer) or they will very short lived (for e.g. USB interrupts) shouldn't cause lags in your process, to the order of a few ms.