HELP: Looking for advice on interval timer sending a high pr

QNX Newsgroups (Archives) qnx.rtos
#1

Hello QNX community,

I am working with some legacy code. This code is basically a driver (which
is single threaded) for some polled hardware. Here is a vital snippet where
the timer that is used to “drive” the hardware is set up:

#define RS_CTL_POLLING_INTERVAL 1 // in milliseconds

#define RS_CTL_TIMEOUT_INTERVAL 1000 // in milliseconds

// Set up a channel in order to receive QNX messages and pulses
int coid;
coid = ConnectAttach(0,0,attach->chid,_NTO_SIDE_CHANNEL,0);

// Set up the sigevent struct for the ctl timer and create this timer
sigevent event;
event.sigev_notify = SIGEV_PULSE;
event.sigev_priority = 24;
event.sigev_coid = coid;
event.sigev_code = PULSE_CTL_TIMER;
timer_create(CLOCK_REALTIME, &event, &CtlTimer);

// Set up the ctl timer as a repeating interval timer!
CtlTimerSpecPoll.it_value.tv_sec = RS_CTL_POLLING_INTERVAL/1000;
CtlTimerSpecPoll.it_value.tv_nsec = (RS_CTL_POLLING_INTERVAL % 1000) *
1000000;
CtlTimerSpecPoll.it_interval.tv_sec = RS_CTL_POLLING_INTERVAL/1000;

CtlTimerSpecPoll.it_interval.tv_nsec = (RS_POLLING_INTERVAL %1000) *
1000000;

// Set up the ctl timer as a one shot timer!
CtlTimerSpecTimeout.it_value.tv_sec =
RS_CTL_TIMEOUT_INTERVAL /1000;
CtlTimerSpecTimeout.it_value.tv_nsec =
(RS_CTL_TIMEOUT_INTERVAL % 1000) * 1000000;
CtlTimerSpecTimeout.it_interval.tv_sec = 0;
CtlTimerSpecTimeout.it_interval.tv_nsec = 0;

CtlTimerPollCount = RS_CTL_TIMEOUT_INTERVAL/RS_CTL_POLLING_INTERVAL;

CtlTimerCountdown = -1;

// Arm the ctl timer as a repeating interval timer
timer_settime(CtlTimer, 0, &CtlTimerSpecPoll, NULL);

As one can see an interval timer is set up to fire every millisecond and
send a pulse at priority 24(!!).The timer-associated pulse is delivered to
the driver itself and the driver is using the SCHED_RR scheduling policy. We
have several other cooperating processes other than the driver and they are
all running at priority 10.

I would like to know others’ thoughts about this execution environment in
terms of thread starvation, responseness of other threads in other processes
including QNX-supplied processes, etc. E.g. I have been told that ionet runs
at priority 21.


Regards, Bill Halchin

#2

“William Halchin” <bhalchin@syrres.com> wrote in message
news:d2u4pc$ja7$1@inn.qnx.com…

Hello QNX community,

I am working with some legacy code. This code is basically a driver (which
is single threaded) for some polled hardware. Here is a vital snippet
where the timer that is used to “drive” the hardware is set up:

#define RS_CTL_POLLING_INTERVAL 1 // in milliseconds

#define RS_CTL_TIMEOUT_INTERVAL 1000 // in milliseconds

// Set up a channel in order to receive QNX messages and pulses
int coid;
coid = ConnectAttach(0,0,attach->chid,_NTO_SIDE_CHANNEL,0);

// Set up the sigevent struct for the ctl timer and create this timer
sigevent event;
event.sigev_notify = SIGEV_PULSE;
event.sigev_priority = 24;
event.sigev_coid = coid;
event.sigev_code = PULSE_CTL_TIMER;
timer_create(CLOCK_REALTIME, &event, &CtlTimer);

// Set up the ctl timer as a repeating interval timer!
CtlTimerSpecPoll.it_value.tv_sec = RS_CTL_POLLING_INTERVAL/1000;
CtlTimerSpecPoll.it_value.tv_nsec = (RS_CTL_POLLING_INTERVAL % 1000) *
1000000;
CtlTimerSpecPoll.it_interval.tv_sec = RS_CTL_POLLING_INTERVAL/1000;

CtlTimerSpecPoll.it_interval.tv_nsec = (RS_POLLING_INTERVAL %1000) *
1000000;

// Set up the ctl timer as a one shot timer!
CtlTimerSpecTimeout.it_value.tv_sec =
RS_CTL_TIMEOUT_INTERVAL /1000;
CtlTimerSpecTimeout.it_value.tv_nsec =
(RS_CTL_TIMEOUT_INTERVAL % 1000) * 1000000;
CtlTimerSpecTimeout.it_interval.tv_sec = 0;
CtlTimerSpecTimeout.it_interval.tv_nsec = 0;

CtlTimerPollCount = RS_CTL_TIMEOUT_INTERVAL/RS_CTL_POLLING_INTERVAL;

CtlTimerCountdown = -1;

// Arm the ctl timer as a repeating interval timer
timer_settime(CtlTimer, 0, &CtlTimerSpecPoll, NULL);

As one can see an interval timer is set up to fire every millisecond and
send a pulse at priority 24(!!).The timer-associated pulse is delivered to
the driver itself and the driver is using the SCHED_RR scheduling policy.
We have several other cooperating processes other than the driver and
they are all running at priority 10.

I would like to know others’ thoughts about this execution environment in
terms of thread starvation, responseness of other threads in other
processes including QNX-supplied processes, etc. E.g. I have been told
that ionet runs at priority 21.

It’s not the interval that is really important but what is being done. If
the process perform every 1ms takes 900us, then leaves only 10% of the CPU
for other lower priority process. Is that a problem? If the CPU is a 386,
yes as 10% may not be enough to handle other activity such as networking.
If the CPU is really powerful 10% is enough of network for example.

If the interfval is 100ms but the process is taking 90ms the idea is the
same, still only leaving 10% for other lower priority process.

Of course that 10% is just an average because as the rate increase, so does
the system overhead.





Regards, Bill Halchin

#3

Hi Mario (and others),

I am not just concerned about the timing interval but also the priority
of 24. It seemed to be arbitrarily picked by the developer. He has tries
many other ad hoc things, e.g. at one time the CtlTimer was one shot that
would be re-armed when finished with the hardware (re-armed in preparation
for the next hardware cycle). Also various SCHED_RR and SCHED_FIFO have been
experimented with in an ad hoc manner rather than designed in from the
beginning. Anyway getting back to the priority, I am concerned that 24 is
too high and starving other processes. Comments?

Regards, Bill

“Mario Charest” <darkmatter@intothevoid.land> wrote in message
news:d2u88b$ls4$1@inn.qnx.com…

“William Halchin” <> bhalchin@syrres.com> > wrote in message
news:d2u4pc$ja7$> 1@inn.qnx.com> …
Hello QNX community,

I am working with some legacy code. This code is basically a driver
(which is single threaded) for some polled hardware. Here is a vital
snippet where the timer that is used to “drive” the hardware is set up:

#define RS_CTL_POLLING_INTERVAL 1 // in milliseconds

#define RS_CTL_TIMEOUT_INTERVAL 1000 // in milliseconds

// Set up a channel in order to receive QNX messages and pulses
int coid;
coid = ConnectAttach(0,0,attach->chid,_NTO_SIDE_CHANNEL,0);

// Set up the sigevent struct for the ctl timer and create this timer
sigevent event;
event.sigev_notify = SIGEV_PULSE;
event.sigev_priority = 24;
event.sigev_coid = coid;
event.sigev_code = PULSE_CTL_TIMER;
timer_create(CLOCK_REALTIME, &event, &CtlTimer);

// Set up the ctl timer as a repeating interval timer!
CtlTimerSpecPoll.it_value.tv_sec = RS_CTL_POLLING_INTERVAL/1000;
CtlTimerSpecPoll.it_value.tv_nsec = (RS_CTL_POLLING_INTERVAL % 1000) *
1000000;
CtlTimerSpecPoll.it_interval.tv_sec = RS_CTL_POLLING_INTERVAL/1000;

CtlTimerSpecPoll.it_interval.tv_nsec = (RS_POLLING_INTERVAL %1000) *
1000000;

// Set up the ctl timer as a one shot timer!
CtlTimerSpecTimeout.it_value.tv_sec =
RS_CTL_TIMEOUT_INTERVAL /1000;
CtlTimerSpecTimeout.it_value.tv_nsec =
(RS_CTL_TIMEOUT_INTERVAL % 1000) * 1000000;
CtlTimerSpecTimeout.it_interval.tv_sec = 0;
CtlTimerSpecTimeout.it_interval.tv_nsec = 0;

CtlTimerPollCount = RS_CTL_TIMEOUT_INTERVAL/RS_CTL_POLLING_INTERVAL;

CtlTimerCountdown = -1;

// Arm the ctl timer as a repeating interval timer
timer_settime(CtlTimer, 0, &CtlTimerSpecPoll, NULL);

As one can see an interval timer is set up to fire every millisecond and
send a pulse at priority 24(!!).The timer-associated pulse is delivered
to the driver itself and the driver is using the SCHED_RR scheduling
policy. We have several other cooperating processes other than the
driver and they are all running at priority 10.

I would like to know others’ thoughts about this execution environment
in terms of thread starvation, responseness of other threads in other
processes including QNX-supplied processes, etc. E.g. I have been told
that ionet runs at priority 21.

It’s not the interval that is really important but what is being done. If
the process perform every 1ms takes 900us, then leaves only 10% of the CPU
for other lower priority process. Is that a problem? If the CPU is a
386, yes as 10% may not be enough to handle other activity such as
networking. If the CPU is really powerful 10% is enough of network for
example.

If the interfval is 100ms but the process is taking 90ms the idea is the
same, still only leaving 10% for other lower priority process.

Of course that 10% is just an average because as the rate increase, so
does the system overhead.







Regards, Bill Halchin

#4

“William Halchin” <bhalchin@syrres.com> wrote in message
news:d2udu6$q6l$1@inn.qnx.com…

Hi Mario (and others),

I am not just concerned about the timing interval but also the
priority of 24. It seemed to be arbitrarily picked by the developer. He
has tries many other ad hoc things, e.g. at one time the CtlTimer was one
shot that would be re-armed when finished with the hardware (re-armed in
preparation for the next hardware cycle). Also various SCHED_RR and
SCHED_FIFO have been experimented with in an ad hoc manner rather than
designed in from the beginning.

Sometime experimenting is good, there are lots of unknown, even in an OS
like QNX. SCHED_* only makes a difference for thread of same priority.

Anyway getting back to the priority,

I am concerned that 24 is too high and starving other processes. Comments?

That is what I 'm trying to tell you :wink: It may or may not starve other
process, it depends on multitude of factors. If for example that process
takes 100% of CPU, then that’s bad. If it only takes 1% then it could be
set at priority 254 and it would almost negligeable.

If it was set at 24 that tells me the work that need to be done is more
important than everything that is bellow priority 24. If it’s not then lower
the priority. If it is more important you want to limit the effect on low
priority process then that process need to be written in such a way that it
uses only a certain percentage of the CPU at every timer event.

You can also look at the adaptive scheduling.




It’s not the interval that is really important but what is being done.
If the process perform every 1ms takes 900us, then leaves only 10% of the
CPU for other lower priority process. Is that a problem? If the CPU is
a 386, yes as 10% may not be enough to handle other activity such as
networking. If the CPU is really powerful 10% is enough of network for
example.

If the interfval is 100ms but the process is taking 90ms the idea is the
same, still only leaving 10% for other lower priority process.

Of course that 10% is just an average because as the rate increase, so
does the system overhead.







Regards, Bill Halchin

\

#5

Hello,

Thnaks for suggestions. I am trying to build a boot image with the
procnto-instr and use the system profiler to see what is really going on.
Because we start our applications from the .script section of the build
file, I will have to start the tracelogger from .script also. Besides
interrupt as a filter, what else should I turn on? 30 seconds enough?

Regards, Bill

“Mario Charest” postmaster@127.0.0.1 wrote in message
news:d2ugbs$s07$1@inn.qnx.com…

“William Halchin” <> bhalchin@syrres.com> > wrote in message
news:d2udu6$q6l$> 1@inn.qnx.com> …
Hi Mario (and others),

I am not just concerned about the timing interval but also the
priority of 24. It seemed to be arbitrarily picked by the developer. He
has tries many other ad hoc things, e.g. at one time the CtlTimer was
one shot that would be re-armed when finished with the hardware (re-armed
in preparation for the next hardware cycle). Also various SCHED_RR and
SCHED_FIFO have been experimented with in an ad hoc manner rather than
designed in from the beginning.

Sometime experimenting is good, there are lots of unknown, even in an OS
like QNX. SCHED_* only makes a difference for thread of same priority.

Anyway getting back to the priority,

I am concerned that 24 is too high and starving other processes.
Comments?

That is what I 'm trying to tell you > :wink: > It may or may not starve other
process, it depends on multitude of factors. If for example that process
takes 100% of CPU, then that’s bad. If it only takes 1% then it could be
set at priority 254 and it would almost negligeable.

If it was set at 24 that tells me the work that need to be done is more
important than everything that is bellow priority 24. If it’s not then
lower the priority. If it is more important you want to limit the effect
on low priority process then that process need to be written in such a way
that it uses only a certain percentage of the CPU at every timer event.

You can also look at the adaptive scheduling.





It’s not the interval that is really important but what is being done.
If the process perform every 1ms takes 900us, then leaves only 10% of
the CPU for other lower priority process. Is that a problem? If the
CPU is a 386, yes as 10% may not be enough to handle other activity such
as networking. If the CPU is really powerful 10% is enough of network
for example.

If the interfval is 100ms but the process is taking 90ms the idea is the
same, still only leaving 10% for other lower priority process.

Of course that 10% is just an average because as the rate increase, so
does the system overhead.







Regards, Bill Halchin



\