Real Time Analysis

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1

============================================================
Operating System: QNX 4.25
Platform: Pentium P5 , 133 Mhz, 16M
Application: Video Analysis

Background:
Our system interfaces with several other CCAs via VME Bus (Universe I
chipset).
In our application there are over 20 processes running at different priority
levels.
Of these processes, one is responsible for sending a periodic message to
another CCA, the nominal frequency
of this transmission is 0.8 seconds. The transmission is scheduled based on
a proxy sent by a timer event.
On occasion, the transmission is delayed by up to 3.3 seconds.

Problem:
I’ve been able to generate a monitor file containing the events surrounding
the condition and I’m using Deja-view
to sift through the monitor file. Unfortuneatly, the monitor file does not
contain info about what function calls
were executed; this info may help aid in determining what system events
pre-empted the specific function call (gprecmsg) that
transmits the periodic message.
I’ve also compiled the gprecmsg file using the following compiler
options: -Wc,"-ee -ep"; this step was recommended
in the deja-view manual for tracing function calls. When my application s/w
executes, it generates a second monitor file
with the same filename as the process containing the special compilation.
After I shutdown my application, the process is
left running (this is intentional in our system) so I slay the process to
terminate the monitoring session. When I try to convert
the monitor file generated by the process using mindex, mindex begins to
execute but terminates due to a Memory Fault.
Mindex has no problem converting a file generated by the utility “monitor”.
I also checked the file size of this file and it is
under 1Meg so its size is not the problem. I’ve run “chkfsys” on the drive
in hopes of fixing the file but had no luck.

Question:

  1. Is the other tools available that would better suit my needs?
  2. If no to Q1 then what should I do to generate a more detailed monitor
    file?
  3. Is there a better method to determine what events are pre-empting my
    transmission by so much time?

Thank you in advance for your assistance,
William Shadid
Software Development Specialist
Neptec Design Group
Ph: 613-599-7603 ext. 290
Fax: 613-599-7604
e-mail: bshadid@neptec.com

=========

2

“Evan Trickey” <etrickey@neptec.com> wrote in message
news:908tff$d6j$1@inn.qnx.com…

============================================================
Operating System: QNX 4.25

You are in the wrong conference, this is for QRTP (QNX4).

Platform: Pentium P5 , 133 Mhz, 16M
Application: Video Analysis

[cut]

Question:

  1. Is the other tools available that would better suit my needs?

Not to my knowledge

  1. If no to Q1 then what should I do to generate a more detailed monitor
    file?

I think it’s should be detailed enough.

  1. Is there a better method to determine what events are pre-empting my
    transmission by so much time?

You should be able to found that via the deja-view. You should be able
to see the proxy being trigger every .8 and you should be able to tell
why your process is not invoked (probably higher priority process is
running).


Thank you in advance for your assistance,
William Shadid
Software Development Specialist
Neptec Design Group
Ph: 613-599-7603 ext. 290
Fax: 613-599-7604
e-mail: > bshadid@neptec.com

============================================================================

\

3

William, the difference between the desired worst-case time, and the
worst-case time that you are actually achieving, is of such a large
scale, that pulling out DejaView may be overkill.

When something is occasionally taking 2.5 seconds away from
your periodic process, it should be easy to find by simply using trace
calls in your code. The QNX 4 high speed trace calls are minimally
invasive, and should (for all practical purposes - given your stated
time scale) not influence the execution of your system at all.

Given the timebase you are talking about, heavy trace instrumentation
of your code would be recommended. DejaView is typically useful
for tracking down problems where the timing is very tight, and
additional instrumentation may have a significant impact on the
execution of the system, or in those cases where the perturbance that
one is attempting to locate is very small (temporally), and may be
associated with a system process.

You also state that “I’ve been able to generate a monitor file containing
the events surrounding the condition”; given that you have an idea of
what events surround the condition, a few well placed trace calls
should narrow down the problem very quickly.

Hope this helps…

Rennie

“Evan Trickey” <etrickey@neptec.com> wrote in message
news:908tff$d6j$1@inn.qnx.com…

============================================================
Operating System: QNX 4.25
Platform: Pentium P5 , 133 Mhz, 16M
Application: Video Analysis

Background:
Our system interfaces with several other CCAs via VME Bus (Universe I
chipset).
In our application there are over 20 processes running at different
priority
levels.
Of these processes, one is responsible for sending a periodic message to
another CCA, the nominal frequency
of this transmission is 0.8 seconds. The transmission is scheduled based
on
a proxy sent by a timer event.
On occasion, the transmission is delayed by up to 3.3 seconds.

Problem:
I’ve been able to generate a monitor file containing the events
surrounding
the condition and I’m using Deja-view
to sift through the monitor file. Unfortuneatly, the monitor file does not
contain info about what function calls
were executed; this info may help aid in determining what system events
pre-empted the specific function call (gprecmsg) that
transmits the periodic message.
I’ve also compiled the gprecmsg file using the following compiler
options: -Wc,"-ee -ep"; this step was recommended
in the deja-view manual for tracing function calls. When my application
s/w
executes, it generates a second monitor file
with the same filename as the process containing the special compilation.
After I shutdown my application, the process is
left running (this is intentional in our system) so I slay the process to
terminate the monitoring session. When I try to convert
the monitor file generated by the process using mindex, mindex begins to
execute but terminates due to a Memory Fault.
Mindex has no problem converting a file generated by the utility
“monitor”.
I also checked the file size of this file and it is
under 1Meg so its size is not the problem. I’ve run “chkfsys” on the drive
in hopes of fixing the file but had no luck.

Question:

  1. Is the other tools available that would better suit my needs?
  2. If no to Q1 then what should I do to generate a more detailed monitor
    file?
  3. Is there a better method to determine what events are pre-empting my
    transmission by so much time?

Thank you in advance for your assistance,
William Shadid
Software Development Specialist
Neptec Design Group
Ph: 613-599-7603 ext. 290
Fax: 613-599-7604
e-mail: > bshadid@neptec.com

============================================================================

\