Problem with realtime pri and /bin/Photon

We have a realtime process that we are porting to Photon that uses ‘timer_create’ to make a timer
that sends a signal to itself every msec. The signal causes a routine
to run that we would like to be entered with minimum latency and to not
miss many msec intervals. We therefore raised the priority of this process compared to the other processes that are part of this application. Before the Photon port this worked adequately (and this is one reason we chose QNX- low context switch latencies), but now it does not. We think we have discovered the reason why. When a process talks to /bin/Photon we see that /bin/Photon matches it’s priority to the priority of the process it is interacting with. We have read the good reasons to do this in the architecture manual. However in this realtime application this is working against us. If the signal arrives when the realtime process is talking to /bin/Photon and /bin/Photon is excuting then it will not be preempted for the signal delivery since it is at the same priority as the realtime process. This is causing us to miss many msec intervals (20 msec or more has been observed).

We desparately need a fix for this. Is it possible to have a flag for /bin/Photon so that it will only lower it’s priority and not raise it?
Thanks.

I think the recommended approach is to separate hard real-time operations from the application’s GUI. Can you split your application into two programs, one for the GUI and one higher priority task to handle the signal? (Usually, humans can’t perceive differences of a few milliseconds, so reducing the quality of the GUI should be OK.)

  • Pete


    Previously, art wrote in qdn.public.qnx4.photon:

We have a realtime process that we are porting to Photon that uses ‘timer_create’ to make a timer
that sends a signal to itself every msec. The signal causes a routine
to run that we would like to be entered with minimum latency and to not
miss many msec intervals. We therefore raised the priority of this process compared to the other processes that are part of this application. Before the Photon port this worked adequately (and this is one reason we chose QNX- low context switch latencies), but now it does not. We think we have discovered the reason why. When a process talks to /bin/Photon we see that /bin/Photon matches it’s priority to the priority of the process it is interacting with. We have read the good reasons to do this in the architecture manual. However in this realtime application this is working against us. If the signal arrives when the realtime process is talking to /bin/Photon and /bin/Photon is excuting then it will not be preempted for the signal delivery since it is at the same priority as the realtime process. This is causing us to miss many msec intervals (20 msec or more has been observed).

We desparately need a fix for this. Is it possible to have a flag for /bin/Photon so that it will only lower it’s priority and not raise it?
Thanks.

Thanks for your reply! In this case we can’t change the architecture without a lot of rewriting effort using shared memory.
Supposedly this approach should work since the signal handler does not need to
call Photon routines and we are not installing it using ‘PtAppAddSignalProc’. We just need /bin/Photon to not raise it’s priority.

Previously, Pete DiMarco wrote in qdn.public.qnx4.photon:

I think the recommended approach is to separate hard real-time operations from the application’s GUI. Can you split your application into two programs, one for the GUI and one higher priority task to handle the signal? (Usually, humans can’t perceive differences of a few milliseconds, so reducing the quality of the GUI should be OK.)

  • Pete


    Previously, art wrote in qdn.public.qnx4.photon:
    We have a realtime process that we are porting to Photon that uses ‘timer_create’ to make a timer
    that sends a signal to itself every msec. The signal causes a routine
    to run that we would like to be entered with minimum latency and to not
    miss many msec intervals. We therefore raised the priority of this process compared to the other processes that are part of this application. Before the Photon port this worked adequately (and this is one reason we chose QNX- low context switch latencies), but now it does not. We think we have discovered the reason why. When a process talks to /bin/Photon we see that /bin/Photon matches it’s priority to the priority of the process it is interacting with. We have read the good reasons to do this in the architecture manual. However in this realtime application this is working against us. If the signal arrives when the realtime process is talking to /bin/Photon and /bin/Photon is excuting then it will not be preempted for the signal delivery since it is at the same priority as the realtime process. This is causing us to miss many msec intervals (20 msec or more has been observed).

We desparately need a fix for this. Is it possible to have a flag for /bin/Photon so that it will only lower it’s priority and not raise it?
Thanks.