we were trying to get the best result with software PWM on raspberry pi with Raspbian. We made a python script which starts PWM on a GPIO pin, and observed the results with the oscilloscope. It didn't do well, the delay wasn't acceptable.After that we set the realtime priority of our software PWM process to 99 and changed the scheduling to real time round robin, anf later to fifo (1865 is the process pid). sudo chrt -f -p 99 1865sudo chrt -r -p 99 1865It acted the same as before the priority change.ALL the other processes were run with nonrealtime priorities. However, there were around 3000 interrupts per second going on from the timer and USB.In this question the answer stated:... the vanilla kernel handles real time priorities, which gives them higher priority than normal tasks, and those tasks will generally run until they voluntarily yield the CPUAny ideas why the change of priority didn't have a visible efect?Do real time priorities influence what will happen with the process on interrupts?
Change of real time priority made no visible effect
process;linux kernel;real time;priority
I didn't make a visible effect because the process was run in user space and it was given real time priorities in context of other processes in user space. However, the kernel space was still loaded with interrupts, and when other processes got their (small) share of processor time, they could have initiated a system call which as a result has a migration to kernel space where the real time priorities of our process don't mean anything.The interrupts were all happening in kernel space, an where therefor also not influenced by the real time priorities.