Project Home
Project Home		 Trackers
Trackers		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Community/Discussion/General/Scheduling jitter for different frequencies/List of Posts
Forum Topic - Scheduling jitter for different frequencies: (3 Items)
   
Update
Grzegorz Sobczyk(deleted)
09/11/2017 7:22 PM
post118028
Scheduling jitter for different frequencies   
Hi!
Recently I implemented QNX Neutrino RTOS on Zynq-7000 platform (ARM A9) and measured scheduling jitter for different 
task frequencies with no CPU load.
In my test I wait in MsgReceive function for pulse generated by timer. Then I read high frequency clock from FPGA 
(100MHz).
I measured scheduling jitter for 10Hz, 100Hz, 1kHz, 10kHz and 100kHz tasks and got strange results. For short period 
task I got (-300,+300) nanoseconds jitter, but for longer periods I got following:

 - 1kHz task had (+600, +1300) nanoseconds jitter
 - 100Hz task had (+8, +12) microseconds(!) jitter
 - 10Hz task had (+69,+71) microseconds jitter

Jitter not only grow bigger for longer period tasks, but also it was always greater than zero. I didnt expect such 
differencies. Could anyone provide some explanation of such behaviour? Might it be explained by POSIX standard, that 
allows timers to expire not prematurely but with overhead? Why did it become more visible for short period tasks?
Grzegorz Sobczyk(deleted)
09/11/2017 7:27 PM
post118029
Re: Scheduling jitter for different frequencies   
Edit in last sentence:
Why did it become more visible for *long* period tasks?
Albrecht Uhlmann
09/15/2017 5:48 AM
post118035
Re: Scheduling jitter for different frequencies   
Hi,
which QNX version are you using? QNX 6.6, or maybe QNX 7? In QNX 7, there are tolerant timers, make sure this is not in 
use.

What tick size is your system running at? Call ClockPeriod to find the real value. Make sure that your timer frequency 
is an integer multiple of that value, otherwise strange things can happen. This implies that setting the timer period 
below the ticksize will give you a timer runnint *at* the tick size.

It is true, because of POSIX you will end up always with a delayed wake-up, never earlier.

You could also play around with calling clock_gettime() then calculate and set the timer with an absolute expiry time. 
Maybe CLOCK_MONOTONIC is a better choice.

You could also play around with the priority of the pulse event of the timer. If you set it to 255, does this alter the 
behaviour?

Regards,
Albrecht

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems