Want a 1ms tick from Linux without modifying Linux Kernel

Started by
20 comments, last by cowboygun 13 years, 4 months ago

I need to develop an embedded application running on Linux, to be more specific, Wind River Linux 4.0 is my favorite for now. My application requires a timer, or scheduler, which is required to tick my application for about every 1ms. I say "about" because there is no strict timing requirements, and either 1.01ms or 0.98ms would be acceptable. In my application, written in C++, I will implement OBSERVER pattern and Listener paradigm to get a full-featured scheduler to dispatch events to processes at variable rates, say 5ms, 10ms, etc.

I would like to know if I can accomplish the above design without modifying the linux kernel, since under GPL, having a kernel module in my application will cause my application to be GPLed. At this moment I don't want to go that far yet. If there is something in the kernel already available, and can tick my application every 1ms, I would like to use it directly in my application. I hope this way will save me from the GPL license issue. Any thoughts? Thank you in advance!

Advertisement
Google "RT-PREEMPT".
http://linux.die.net/man/3/clock_gettime

use clock_getres clock_gettime with CLOCK_REALTIME like you could QueryPerformanceCounter/QueryPerformanceFrequency on Windows

-me
Linux can do pretty good ms resolution events. I recommend just using Boost Deadline Timer. After googling for boost periodic timer this came up if you want a periodic timer.
Also, the OpenMP timer has absurdly small resolution and extremely high accuracy (also thread-safe!)
My out-of-the-box Debian and Ubuntu Linux systems have timeout on epoll_wait (and thus probably on everything else too, but I didn't test that explicitly) working at accurracies in the microsecond (micro, not milli) range without having to refer to any special RT stuff.

So, a millisecond should be no issue at all (assuming every "normal" Linux works more or less the same).
Quote:Original post by samoth
My out-of-the-box Debian and Ubuntu Linux systems have timeout on epoll_wait (and thus probably on everything else too, but I didn't test that explicitly) working at accurracies in the microsecond (micro, not milli) range without having to refer to any special RT stuff.

So, a millisecond should be no issue at all (assuming every "normal" Linux works more or less the same).


What is the *granularity* of epoll_wait? If you call epoll_wait 100μs apart, will it wait for 100μs or will it wait somewhere between 0 and 20ms (like Windows do)?

[OpenTK: C# OpenGL 4.4, OpenGL ES 3.0 and OpenAL 1.1. Now with Linux/KMS support!]

The former.

I tested that once when I had the exact same question (how to block somewhat reliably for 1ms) as the OP, and found that this is really nothing to worry about.

While I don't remember whether I ran the tests over 1 second, or 10 seconds, 100 seconds, or whatever time, the baseline was that if you ask it to block for 1μs a million times, the total time will add up to slightly over a second (as opposed to 2000 seconds). So, in wall time, you get pretty much exactly what you asked for, plus some syscall overhead. Which honestly, I found absolutely stunning.
Using epoll() is overkill when you could just use timerfd_create() can friends for a nanosecond-level timer. Of course, you can multiplex a timerfd through epoll(), poll(), select(), or do a blocking read() in a thread (whatever your favorite multiplexing poison is), but using timerfd you can have multiple timers pending and leave the dispatch to the kernel, yielding simpler code and lower system overhead.

Stephen M. Webb
Professional Free Software Developer

Quote:Original post by Sneftel
Google "RT-PREEMPT".

Is it an overkill to turn the Linux into a fully preemptible kernel? I only need a 1ms tick. I hope something really simple. Thank you anyway.

This topic is closed to new replies.

Advertisement