Hi, first of all thanks for picking up this topic. I am an application level developer without being able to go into driver specific development. The driver is vendor provided so there is no chance for me to change its conceptional design. However all I can say is that the Interrupt Timer has influence on the driver performance and that I have good experience with non real time kernels as long as these have the higher frequency enabled. So the need of changing a driver is low, hence its design might be not optimal needing 1000 MHz tick timer but this is too long to discus here... I am wondering about the implications of using a real time kernel and its drawbacks, unfortunately the documentation about the differences and technical reasoning of different kernel layouts in the standard distribution is nearly nonexistent in OpenSuse, but I understand it is probably out of scope of unpaid services. BR Thomas On 6/7/21 11:59 AM, Hannes Reinecke wrote:
On 6/3/21 11:37 AM, Thomas Hartwig wrote:
I am wondering if there is any kernel available by default which offers kernel interrupt timer (CONFIG_HZ) at 1000 Hz. I checked preempt in 15.2 but there it is 250 Hz. Why this is kept at 250 Hz there?
Primarily for historical reasons; 250 Hz was found to be a good compromise between interactive and non-interactive tasks.
My use case is very special: my environment is dealing with high speed cameras and the low frequency is needed to be able to manage high frame speed at several thousand frames per second. Right now I am using a special desktop kernel from a foreign source however I am wondering if there is any chance to have this into mainline LEAP distro available? I know my use case is very special and I should be able to maintain my own kernel for this, however I am wondering if this would be a nice benefit of the LEAP distribution in general and why the preempt kernel is kept at lower frequency still...
Actually this sounds like a case for the realtime kernel. If you have hardware with specific timing needs I would have thought that the driver/application/what have you should be moved to employing a 'realtime' scheduling policy, and manage the frame capture from within the driver rather than relying on the kernel interrupt timer to do it for you.
If you had a need for raising the interrupt timer it really sounds like a bad driver design to me ...
If, OTOH, you can convert your application to leveraging realtime priority you can look a the -rt kernel, which is geared up for precisely such usecases.
Cheers,
Hannes