We experienced a very strange problem seems to be related to
timer-processing under QNX 4.25D (specifically in Proc32 4.25J !!!).
(I’ve already filled a problem report form on the QDN website, but
there was no feedback, so I try to post it here (with more details),
too…)
- Problem summary:
Under Proc32 4.25J it can frequently happen, that a periodic timer
using proxy notification will expire after (cycle-interval-time +/-
ticksize), and not after - the required - (cycle-interval-time)!
The (+/-ticksize) differences will be balanced by each other, almost
immediately, so the average expiration time will be the required
value, but the rate of occuring +/- differences is quite high: in
some of the tests it had reached the 20%/20% value!
An important fact, that if - after starting the owner application
of the timer - we explicitly set ticksize to a lower value, and then
back to the original one, the +/- differences disappear, the
affected timer will expire accurately with the required
cycle-interval-time…
[Is it a bug or a feature???]
-
Environment:
-
Hardware (does not seem to be relevant):
Various Intel chipset (TX,ZX) based PCs (+ a notbook) with Intel
Pentium MMX & Celeron processors. (I can provide further details
on request…)
-
Software:
-
QNX 4.25D (Proc32: 4.25J)
-
Photon 1.14A
-
Watcom C/C++ 10.6B
-
Problem details:
There is a timer attached (as a periodic wakeup-timer) in a high priority
(-> 27/28) process, with a 20ms cycle interval, using proxy based
notification. (The ticksize is 2ms.)
[Normally the owner process can complete its periodic activity
within the cycle time of its wakeup timer (20ms).]
The problem is, that it can frequently happen, that the timer will
expire after 18ms or 22ms (cycle-time +/- ticksize) and not after
20ms (the required cycle-time).
The +/- differences will be balanced/corrected by each other, a -(+)
difference generally will be immediately followed by a +(-)
difference, but the rate of abnormal expiration times is quite high.
Testing method: I used ‘monitor’ for testing (priority: 29), and I
compared the timestamps of following lines:
" proxy(()) triggers ()"
[-> where the proxy seems to be triggered…]
and not the lines:
" () recv … from proxy(())"
[-> where the owner of the timer finally seems to receive the msg
of the proxy; it can be delayed…]
Some notes:
-
Running with different cycle times (8 or 10ms) identical results
will be produced. -
An other timer with the same cycle-interval-time in an other
process (running as a part of the same application) shows
identical symptoms, so we can not say that the problem affects
only a specific timer of a specific process. -
Priority of Proc32: 30 (default).
-
The -F option of Proc32 is NOT used, so the frequency of the 8254
clock is the default. -
Priority of Fsys.eide was reduced from 22 to 11.
-
Possible fixes:
-
Stepping back to Proc32 4.25I the problem disappears, the affected
timer expires accurately. -
Running under Proc32 4.25J, if - after starting all of the
component processes - we explicitly set ticksize to a lower value
(e.g. to 1ms) and then back to 2ms, the problem seems to
disappear! (It’s really strange, but it happens…)
By stopping the whole application and then restarting it, the
problem occurs again, but a repeated ‘ticksize 1; ticksize 2’
command sequence helps again…
[Each of the possible solutions can be verified by the ‘monitor’
utility: no more +/-ticksize differences can be found in the
timestamps of 'proxy … triggers … ’ lines!!!]
[On request I can send detailed test results (->monitor-outputs)…]
Good luck in investigation,
Gyorgy Tamasi (cosy-software@freemail.hu)
COSY Software / Schoenenberger Systeme GmbH