|
QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/03/2024 9:41 AM
post122610
|
QNX 8 : ClockPeriod() can no longer be used to set clock period
Hello,
I noticed that in QNX 8, ClockPeriod() can no longer be used to set a clock period (See https://www.qnx.com/developers/
docs/8.0/com.qnx.doc.neutrino.lib_ref/topic/c/clockperiod.html).
While it seems that this was possible in QNX 7.1 (See https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.
neutrino.lib_ref/topic/c/clockperiod.html).
So, my question is: Is there another way to change the clock period for example from 1msec to 0.5msec ?
Thanks,
Regards.
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/03/2024 10:16 AM
post122611
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/03/2024 10:46 AM
post122612
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/03/2024 11:27 AM
post122613
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
Keep in mind that QNX 8 is fully tickless, and uses per-core timers. The only thing this setting affects is the
alignment of normal-resolution software timers. It may not be worth changing.
--Elad
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/07/2024 5:02 AM
post122614
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
Hello,
Many thanks, I missed that important point.
I need a clarification: If I have a thread which calls:
clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &wakeup_time, NULL);
With a tickless system, I would assume that a timer is configured to expire at "wakeup_time".
Am I right?
Will the calling thread be rescheduled exactly at "wakeup_time"? (assuming that there is no higher priority threads in
the system)
Thanks,
Regards.
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/07/2024 7:34 AM
post122615
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
Default timers are still tick-aligned, to avoid excessive interrupts. Even though there is no tick per se, the timer
hardware is configured to the next expiration time rounded up to what would be the next tick value (1ms by default). You
can use high-resolution timers if you really need that, at the expense of extra interrupts in the system.
--Elad
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/07/2024 9:54 AM
post122616
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
Hi Elad,
your clarification explains, why my latency/jitter tests, I made with every QNX version since 6.3, produces a very big
jitter under QNX 8.
e.g.:
For hard real time sampling controller software I use code like this:
loop:
...
TimerTimeout(CLOCK_MONOTONIC, _NTO_TIMEOUT_NANOSLEEP | TIMER_ABSTIME, NULL, &nsTime, NULL);
nsTime += nsec_sampling_period
...
goto loop
nsec_sampling_period has to be a multiple of the clock period of the system, to get rid of rounding jitters.
With this approach, I measure a worst case jitter < 10 us, sampling at the highest thread prio in the system.
BTW. on nowadays fast embedded systems a clock period of 100 us is no problem.
e.g. Our EtherCAT Stack is sometimes used with a 200us cycle for high speed motion controllers in the real world.
To get a low jitter < 10 us under QNX 8, I have to use a sampling period > ca. 3000 us at the moment.
How is it possible, to reduce this 1 ms default, you mentioned, to a lower value, e.g. 100 us ?
Thanks
Michael
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/07/2024 10:19 AM
post122617
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
Found it: procnto -C 10000.
I assume, it is no longer possible, to change this during runtime, right?
Well, on the first view, this looks OK: < 10 us.
But every n sampling ticks, I get a jitter of 100 us, I assume, because of a rounding in the kernel.
-Michael
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/07/2024 11:50 AM
post122618
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
Yes, we removed the run-time option because it ended up complicating the code for no good reason. You pick a value for
the system and stick to it.
I fully understand that different systems can have different characteristics. We just needed to pick a default value,
and 1ms still seems like a reasonable default.
For 8.0, if you have interrupt latency requirements that are in the microseconds, then you can set the IST even above
the clock handler, as long as you don't need the IST itself to use software timers.
--Elad
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/10/2024 4:13 AM
post122620
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
Hello,
To be able to adjust the timer tolerance between 0 and the clock period, I read that I need to set the
PROCMGR_AID_HIGH_RESOLUTION_TIMER ability.
So, on my test board (Raspberry Pi4), I tried:
int ret = procmgr_ability(0, PROCMGR_AID_HIGH_RESOLUTION_TIMER);
But my process is getting an exception:
terminated SIGSEGV code=1 fltno=11 ip=00000058f817990c mapaddr=000000000006090c ref=0000003292315000
Did I missed something?
Thanks.
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/10/2024 7:16 AM
post122621
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
There are a few things wrong with this call.
First, you must terminate the list of abilities with PROCMGR_AID_EOL. This is likely the cause of the SIGSEGV, as the
variadic function looks for the next ability in the list.
Second, you need to specify the operation on that ability (allow/deny) and the domain on which it works (root/non-root).
Finally, this call cannot be used to gain an ability your process doesn't have, or abilities wouldn't be very useful. It
is typically used either to drop abilities your process doesn't need, or to retain an existing ability before dropping
root privileges. In a properly-secured system, abilities are not governed by such calls but rather by security policies.
See the documentation for procmgr_ability()
--Elad
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
10/10/2024 7:44 AM
post122622
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
Thanks.
My bad... Indeed, it works better with:
int ret = procmgr_ability(0, PROCMGR_AID_HIGH_RESOLUTION_TIMER | PROCMGR_AOP_ALLOW | PROCMGR_AID_EOL);
Thanks,
Regards.
|
|
|
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
|
09/11/2025 3:17 AM
post122679
|
Re: QNX 8 : ClockPeriod() can no longer be used to set clock period
Hi all,
just played around with the high resolution timers.
With explicit timers it is working, as expected. e.g.:
SIGEV_UNBLOCK_INIT(&sigEvent);
id = TimerCreate(.... &sigEvent);
time_in.nsec = 1;
time_in.interval_nsec =0;
TimerSetTime(...TIMER_TOLERANCE....);
time_in.nsec = 10000000; // 10 ms
time_in.interval_nsec = 0;
TimerSetTime(...TIMER_PRECISE....);
sleep( VERY_LONG);
We wake up after 10 ms with a tolerance of around 14 ...20 us on an Ultrascale+ CPU;
Perfect.
My simple approach with an implicit timer does not use the high resolution at all. e.g.:
nsTime = 1;
rc = TimerTimeout( CLOCK_MONOTONIC, TIMER_TOLERANCE, NULL, &nsTime, NULL );
nsTime = 10000000; //10 ms
rc = TimerTimeout( CLOCK_MONOTONIC, _NTO_TIMEOUT_NANOSLEEP | TIMER_PRECISE, NULL, &nsTime, NULL );
We wake up after 10 ms + 1 * ticksize;
I s this a know issue?
-- Michael
> Default timers are still tick-aligned, to avoid excessive interrupts. Even
> though there is no tick per se, the timer hardware is configured to the next
> expiration time rounded up to what would be the next tick value (1ms by
> default). You can use high-resolution timers if you really need that, at the
> expense of extra interrupts in the system.
>
> --Elad
|
|
|
|