We are experiencing a peculiar problem with an
application that is sufficiently complex that we
are having difficulty isolating the cause of this
problem. In the hope that someone may have seen
something like this before, I will present the
effect to see if anyone can suggest where we
ought to be looking.
CPU is a 200 MHz Pentium with 32 MB RAM on a CPCI
single board computer.
Under certain “abnormal” conditions our task
suite appears to operate as we expect, but all
QNX timing functions behave as if the ticksize
has been set to 55 ms. We set our ticksize to 1
ms in sysinit. ‘sin info’ and ‘ticksize’ without
parameters always agree that the ticksize is 1
ms, but, when we encounter our problem, executing
a ‘sleep 1’ from the command line takes 55
seconds. Our task timers are similarly scaled
down. Executing a ‘ticksize 1’ from the command
line immediately restores normal timing.
We are using both QNX and TCP/IP networking,
POSIX message queues, and some tasks do have root
privilege and access PCI boards mapped into IO
space. We do not intentionally interact with any
of the standard PC IO devices such as timers.
I know there is much unsaid here, but if anyone
can give an idea where we are going astray it
would be appreciated.
Under certain “abnormal” conditions our task
suite appears to operate as we expect, but all
QNX timing functions behave as if the ticksize
has been set to 55 ms. We set our ticksize to 1
ms in sysinit. ‘sin info’ and ‘ticksize’ without
parameters always agree that the ticksize is 1
ms, but, when we encounter our problem, executing
a ‘sleep 1’ from the command line takes 55
seconds. Our task timers are similarly scaled
down. Executing a ‘ticksize 1’ from the command
line immediately restores normal timing.
Suspiciously, 55ms is the tick size of MS-Windows
3.11. Are you trying to do anything with rundos
or a DOS emulator of some kind?
Andrew
Andrew Thomas, President, Cogent Real-Time Systems Inc.
2430 Meadowpine Boulevard, Suite 105, Mississauga, Ontario, Canada L5N 6S2
Email: andrew@cogent.ca WWW: http://www.cogent.ca
We are experiencing a peculiar problem with an
application that is sufficiently complex that we
are having difficulty isolating the cause of this
problem. In the hope that someone may have seen
something like this before, I will present the
effect to see if anyone can suggest where we
ought to be looking.
CPU is a 200 MHz Pentium with 32 MB RAM on a CPCI
single board computer.
Under certain “abnormal” conditions our task
suite appears to operate as we expect, but all
QNX timing functions behave as if the ticksize
has been set to 55 ms. We set our ticksize to 1
ms in sysinit. ‘sin info’ and ‘ticksize’ without
parameters always agree that the ticksize is 1
ms, but, when we encounter our problem, executing
a ‘sleep 1’ from the command line takes 55
seconds. Our task timers are similarly scaled
down. Executing a ‘ticksize 1’ from the command
line immediately restores normal timing.
We are using both QNX and TCP/IP networking,
POSIX message queues, and some tasks do have root
privilege and access PCI boards mapped into IO
space. We do not intentionally interact with any
of the standard PC IO devices such as timers.
I know there is much unsaid here, but if anyone
can give an idea where we are going astray it
would be appreciated.
I would guess something in your code is calling qnx_ticksize() to
change the value. The argument is in nsec. It probably
as been mistaken for another unit. a grep qnx_ticksize * will
help you find the problem.
Aside from this I don’t see how that is possible, unless
you have hit a bug in the kernel, but that i doubt.