I have a task which is basically a TIMER; so it goes to sleep and is supposed to wake up periodically.. So the timer task sleeps for say 10ms. But what is happening is that it is inconsistent in waking up and cannot be relied upon to awaken in time correctly.
In fact, in my runs, there is a big difference in sleep times. Sometimes it can vary by 1-2 ms in awakening and very few times does not come back to at all. This is because the kernel scheduler puts all the sleeping and waiting tasks in a queue and then when it polls to see who is to be awakened, I think it is round robin. So sometimes the task would have expired by the time the scheduler polls again. Sometimes, when there are interrupts, the ISR gets control and delays the timer from waking up.
What is the best solution to handle this kind of problem?
(Additional details: The task is a MAC timer for a wireless network; RTOS is a u-velOSity microkernel)
You should be using the timer API provided by the OS instead on relying on the scheduler. Here's an introduction to the timer API for Linux drivers.
If you need hardcore timing, the OS scheduler is not likely to be good enough (as you've found).
If you can, use a separate timer peripheral, and use it's ISR to do as little as you can get away with (timestamping some critical data, set some flags for example) and then let your higher-jitter routine make use of that data with its less guaranteed timing.
Linux is not an RTOS, and that is probably the root of your problem.
You can render Linux more suited to real-time use in various ways and to various extent. See A comparison of real-time Linux approaches for some methods and an assessment of the level of real-time performance you can expect.
Related
I want to clarify about timers in linux, how they are behaving?
I know in micro-controllers the timers/counters we use the reference, timing of machine instruction to execute.so there we could make it loop for how much time we need sleep/timer/counter.
But in linux where & how it will take the reference that if i use sleep(5), exactly 5 seconds are elapsed.If any one know please clarify me kindly.
Every operating system kernel (that I know of) has a whole machine independent framework for timers. This is pretty much one of the most central things a kernel must have because we need timers for everything, process scheduling, dealing with hardware errors, select/poll timeouts, network protocols, etc. At any point in time your kernel has dozens, if not thousands of timers waiting to be executed at some point in the future. Most of them will be canceled and never executed.
The simplest framework that pretty much everyone uses sets up one of the many clocks in a machine to generate an interrupt at a set interval. 100Hz is the most common, Windows (at least in the past) sets it to 64Hz (but it can be changed by any application), some systems experimented with 1024Hz. The timer interrupt fires and the interrupt handler checks if there's anything queued up to do at that time and if there is, it is executed. There has been some work for Linux to improve this so that we can get shorter or longer intervals than 10ms depending on the next scheduled timer, both to improve the precision of the timers and to save power, but in general it works as described above.
If I understand your question correctly, you think that there is something that measures how much certain sequence of instructions takes and then loops until some amount of time passes. This is something that is almost never done because it wastes power and it blocks anything else from running at the same time and is also quite unreliable. It is still done in modern kernels, but very rarely and only when high precision is required when talking to really, really stupid hardware. Last time I had to do it was 17 years ago to talk to some ethernet controller where you had to manually implement MII by bit-banging in software, it was terrible and hung the system for quite a long time every time you (un-)plugged an ethernet cable. Nobody builds hardware that requires this anymore because it really ruins the performance of modern systems.
So in your question, sleep(5) will be implemented by registering a function in the timer framework to be called in 5 seconds from now and then putting the process to sleep. 5 seconds later the timer fires and the process gets awakened again.
I have a low latency server/client audio application running on seperate cores. (via cpuset)
No xruns are detected, I suspect the scheduler to interrupt my critical routine. Since disabling interrupts is not possible in user space my idea was to create a kernel module and write wrapper functions for local_irq_disable()/local_irq_enable(). Security is not an issue. An rt Linux with fully preemptible kernel is in use.
I assume the nanosleep function won't work without interrupts too?
What would be the more elegant way to disable the scheduler but keep
the timers running?
How do I call these wrapper functions from user space?
Edit: SMP affinity is the keyword here: SMP IRQ Affinity
I would recommend to first try to trace your kernels scheduling by using lttng and tracecompass to find out what really is happening on your system and what other process, ressource lock or interrupt is forcing your process out of cpu.
Do you really need this process to run without cpu time gaps? If not: do you need response time in micoroseconds or milliseconds?
I know it has to do with time and efficiency, and how ISRs take time away from other processes, but I am unclear why this is. I am always told to keep ISRs very short. I am a bit confused why this is.
Normally, ISRs come into scene when a hardware device needs to interact with the CPU. They send an interrupt signal that makes the CPU to leave whatever it was doing to service the interrupt. That it's what ISR must care about.
Now, this depends on many factors, being the hardware environment and the nature of the interrupt maybe the most relevant ones, but it usually happens that in order to properly service an interrupt, ISRs run with interrupts disabled so they cannot be interrupted. This means that the CPU cannot be shared among other processes while it is running ISR code because the system timer interrupt that is used to run the scheduler (which is the part of the kernel that takes care of making the illusion that the CPU can do several tasks at the same time) won't work.
So, if your ISR takes too much time to perform a certain operation with the device, your system will be affected as a whole, because the percentage of time the CPU is available for the rest of processes will be less than usual. This is much noted on old system with PIO hard disks, which interrupt the CPU for every disk sector they want to transfer to the CPU, and the ISR must do the actual transfer. If there's many disk traffic, you may notice things like your mouse moving jerky (because the interrupt that the mouse device sends to the CPU is not attended)
OSes like Linux allow ISRs to defer time consuming operations with hardware devices to tasklets: sort of kernel threads that can share CPU time with other processes, yet keeping the atomic nature of hardware device operations (the OS ensures that there won't be more than one tasklet function -for the specific tasklet associated to the ISR- running in the system at the same time). The PIO transfer from disk to kernel buffers is an example of such operation.
Some precisions w.r.t. the accepted answer.
Interrupts are not necessarily disabled when running an interrupt, and that is not necessarily the reason why the kernel processes all interrupts before returning to threads.
There is the concept of interrupt priorities. An interrupt of higher priority will preempt a running ISR: if the timer interrupt is of higher priority than the running ISR, it will run. However, a kernel will not handle context switches at this time, but rather defer them until all queued/pending ISRs have run.
Also, on some processors (eg. ARM Cortex-M3), the concept of handling an interrupt is a mode of operation in the processor itself. The processor cannot go back to running threads until it gets out of interrupt mode. Once that happens, all interrupts are fully serviced: you cannot go back to running an ISR.
But the main reason why all ISRs must finish before going back to threads is that kernels do not have the concept of a thread-like running context for ISRs. An ISR thus cannot pend: it must run to completion. An ISR is thus hogging the CPU, except from higher-priority interrupts, until it finishes its purpose.
Usually, the main thread has lower priority than the ISRs. Depending on the scheduler, often the main code will be executed after all pending ISRs have been run.
Having alot of computation intensive code in one or many ISR is generally not advisable, since it may cause delays or even CPU starvation of lower priority ISRs or threads, which may be detrimental if time-critical code needs to be executed.
However, when action needs to be taken immediately at an interrupt event, the fastest way is to execute code from the associated ISR (and possibly assign it a high priority).
If you plan on using several interrupt sources that execute time-consuming code, the way to go is by using an RTOS to allow safe and efficient interleaving of several threads to service each of the interrupts.
I would like to run a long term task on a dedicated core and would like that task to be minimally interrupted / preempted. I can see 2 solutions. Which one is better or any other solution?
1) Set affinity and isolate core using isolcpus
2) Make the thread real time using SCHED_FIFO and set the priority high
- if this is the better choice how high the priority should be? Can I set it to 99?
What I am concerned about is being preempted by kernel threads, IPIs ...
Regarding the first solution you mentioned, by adding parameter isolcpus = [CPU no.] during boot will instruct Linux scheduler to not run any task on that CPU unless requested by user using CPU Affinity. But this CPU may receive interrupts and that can also be avoided by setting IRQ Affinity, so that the isolated CPU doesn’t receive any interrupt. Finally in your code of the task you set the Affinity to the isolated CPU and you are good to go.
But Even if you follow these steps, kernel tasks are executed on the isolated CPU core if you are not using a real-time kernel from RP_PREEMPT, hence it might not be possible to completely isolate a CPU core unless you are using RT kernel.
Refer - http://elinux.org/CPU_Shielding_capability
The second solution about using SCHED_FIFO scheduling policy and using a high priority value will still not prevent the kernel threads, Timer tick interrupts, IPIs etc., from pre-empting your task. Because the scheduling policies and priority is for kernel to schedule all other User-space processes and threads and does not apply to kernel threads or processes.
So by setting high priority to your task does not mean you will get 100% CPU dedicated to your task. Also the alternative, manually setting the CPU mask of your task to a CPUSET in the system, can cause problems and suboptimal load balancer performance. Your task will still get interrupted from time to time by Linux code, including other tasks - such as the timer tick interrupt and the scheduler code, IPIs from other CPUs and stuff like work queue kernel threads, although the interruption should be quite minimal if you have don’t have much activity going on in your other cores.
But the cleanest way to achieve this should come from Kernel tweak which I found from this link http://www.linuxjournal.com/article/6799?page=0,2. Though I haven’t tried this personally, I think it’s worth giving a look at this article as well before you decide upon the method you will use.
In my application a no. of devices (camera, A/D, D/A etc ) are communicating with a server. I have two options for saving power consumptions in a device as not all devices has to work always:
1- Do poling, i.e each device periodically keep on looking at a content of a file where it gets a value for wake or sleep. If it finds wake, then it wakes up and does its job.
In this case actually the device will be sleeping but the driver will be active and poling.
2- Using interrupts, I can awake a device when needed.
I am not able to decide which way to go and why. Can someone please enlighten me in this regard?
Platform: Windows 7, 32 bit, running on Intel Core2Duo
Polling is imprecise by its nature. The higher your target precision gets, the more wasteful the polling becomes. Ideally, you should consider polling only if you cannot do something with interrupts; otherwise, using an interrupt should be preferred.
One exception to this rule is if you would like to "throttle" something intentionally, for example, when you may get several events per second, but you would like to react to only one event per minute. In such cases you often use a combination of polling and interrupts, where an interrupt sets a flag, and polling does the real job, but only when the flag is set.
If your devices are to be woken up periodically, I would go for the polling with the appropriate frequency (which is always easier to setup because it's just looking at a bit). If the waking events are asynchronous, I would rather go for an interrupt-driven architecture, despite the code and electronic overhead.
Well it depends on your hardware and software atchitecture and complexity of software. It is alwasy better to choose interrupt mechanism over polling.
As in polling your controller will be busy continuously polling the hardware to check if desired value is available.
While using interrupt mechanism will free the controller to perform other tasks, and when interrupt arises your ISR can perform task for specific need.