5

I'm working on an embedded Linux project, using an arago distribution that is probably around version 3.3.

I have configured a high-resolution Linux timer to wake-up my process once per millisecond. This works ok but there are two issues with the timing:

  1. A jitter in the wake-up time
  2. Variability of the processing time when awake, despite the fact that the processing done by the process is constant.

I attribute these problems to the less-than real-time performance of Linux. But I need to investigate ways of improving the real-time performance.

I have checked that the kernel is configured with the CONFIG_PREEMPT kernel option, which is good for real-time.

I have also applied the SCHED_FIFO scheduling class to my process:

struct sched_param schedparm;
memset(&schedparm, 0, sizeof(schedparm));
schedparm.sched_priority = 1; // lowest rt priority
sched_setscheduler(0, SCHED_FIFO, &schedparm);

but that made no difference.

I guess that a logical step is to apply the PREEMPT_RT patch to the kernel build, but I haven't identified how to do that yet.

Is there anything else I can do to improve the jitter / duration variability?

Or can anyone suggest an accessible tutorial on how to apply the PREEMPT_RT patch?

Claudio
  • 10,614
  • 4
  • 31
  • 71
user1768576
  • 153
  • 2
  • 10
  • Correct me if I am wrong, but the clock can never absolutely precise resolve to exact a millisecond. The clock relies on an underlying frequency that is not a clean multiple of that 1 ms fequence, so there must be a jitter. That is imminent. Same for the duration of the processing step. I'd say standard computers are not suitable to such precision, it is not what they are built for. You will ahve to use a special circuit for such tasks. – arkascha Dec 05 '12 at 11:13
  • I disagree, the Linux high-resolution timers have a resolution of 1ns. Of course, I wouldn't expect that sort of accuracy, but I think that I should be able to improve on what I am seeing. – user1768576 Dec 05 '12 at 11:31
  • @user176: How did you solve this same issue. Even i am facing the same issue now ? Please update with answer if you have solved it. Pleasre look at the below question: http://stackoverflow.com/questions/15805231/need-to-improve-the-linux-performance-for-embedded-system – Ashoka K Apr 04 '13 at 11:09
  • Lots of questions left unanswered here. On what platform are you running? The quality of the timers available for Linux to use is important. What is this processing you're doing? How are you measuring the jitter? – Jonathon Reinhart Dec 16 '15 at 11:47

2 Answers2

1

It seems PREEMPT_RT is the logical next step. Did you try this tutorial?

https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO

Update: I suggest you look at how others build a preemptive kernel, e.g. here: https://aur.archlinux.org/packages/linux-rt/

You can read the PKGBUILD to understand what is done.

ypnos
  • 50,202
  • 14
  • 95
  • 141
  • I am rather confused about the PREEMPT_RT patch. I read that the patch was included in the kernel from 2.6 onwards. I am using Linux 3.3. Does that mean it will include the patch already? Do I still need to build the kernel with option CONFIG_PREEMPT_RT=y? – user1768576 Dec 05 '12 at 14:06
  • You don't need to apply the patch if its included, but "from 2.6 onwards" makes no sense. Second, you need to set CONFIG_PREEMPT_RT=y. I strongly believe the default kernel configs used by distros are not compiled with such an option. You can check the config used by your distribution. It is part of the kernel package, sometimes of the kernel-src package. See also my updated answer. – ypnos Dec 05 '12 at 17:07
0

If you use Debian testing, or LMDE for that matter, they have a precompiled PREEMPT_RT kernel in the repo for the x86 and amd64 architectures.

apt-get install linux-image-rt-686-pae

or

apt-get install linux-image-rt-amd64
SzG
  • 12,333
  • 4
  • 28
  • 41