Scheduling Latency Question - monitor/msgprint results

Hi,

We operate QNX 4.24 on two different single board computers. The Teknor
Viper 830 and the Teknor Raptor C810.

We also run an in-house developed application on these systems. The
application includes logic to interface with a device installed in the
ISA chassis, in the case of the Viper 830, or in a cPCI chassis, in the
case of the Raptor-C810. Our application is basically the same in both
systems but does have some changes to handle the ISA to cPCI
differences. The QNX OS is basically the same with the exception of
being a different SBC and chassis.

The device we interface with uses an interrupt to acquire the attention
of our application. Our application includes an Interrupt Handler
process which fields the interrupt and Triggers a proxy to another
process of our application.

With these two systems we see two quite different scheduling latency
times. That is the time from Triggering of the proxy to the invocation
of the process receiving the proxy is quite different. When operating on
the Viper 830 SBC, the scheduling latency is measured to be around 30
microseconds long. When operating on the Raptor C810 SBC, the scheduling
latency is measured to be from 30 microseconds up to 5 milliseconds
long, and most typically it’s 5 milliseconds.

We have traced QNX activity using the QNX “monitor” and “msgprint”
utilities. The results of these utilities confirm our time values noted
above. Additionally, the results show significant differences in process
activity during the time period between the Trigger of the proxy and the
invocation of the receiving process.

Attached are a portion two monitor/msgprint result files taken from runs
on the Viper and the Raptor, files ProxyTime830 and ProxyTime810
respectively. We are unsure about how to interpret the event
descriptions provided by monitor/msgprint and hence how to interpret
these results. In the ProxyTime830 file you can see our interrupt #5 and
our application’s process “itp_l1”. In the ProxyTime810 file you can see
our interrupt #11 and our application’s process “itp_l1p”.

Your help in providing us with some information about the meaning of the
results and what may be causing the excessive scheduling latency
exhibited in the ProxyTime810 file would be greatly appreciated.

Thanks in advance,
Charlie Powell

SMM ?

Not familiar with your hardware, but I would check to see whether it has
SMM first.

Thanks for your reply and sorry but I don’t know what the acronym SMM
stands for?

Charlie

Rennie Allen wrote:

SMM ?

Not familiar with your hardware, but I would check to see whether it has
SMM first.

System Management Mode. It is a completely independent mode of the
processor, invisible to the operating system (the processor actually uses
real mode addressing while in SMM). Since QNX has no say in when SMM get’s
entered, and it isn’t QNX code executing when SMM is active QNX can not give
any real-time guarantees when you are executing on a machine with SMM (i.e.
SMM hardware is incompatible with real-time).

“Charlie Powell” <charlie.powell@nokia.com> wrote in message
news:3ADEEAEB.DC8194D5@nokia.com

Thanks for your reply and sorry but I don’t know what the acronym SMM
stands for?

Charlie

Rennie Allen wrote:

SMM ?

Not familiar with your hardware, but I would check to see whether it has
SMM first.