We have a clock pulse coming into the parallel port of our PC. There is an
interrupt handler for IRQ7 that fires off a proxy that a task is doing a
Receive on.
The problem is that qnx_ticksize effects the amount of skew from the clock
pulse.
That is if qnx_ticksize is set to 2ms then my worst case skew from my 2ms
clock pulse is 4ms. (The 4ms firing of the task then is followed by a 300us
firing, to “make up” for the holdoff.)
If the qnx_ticksize is set to 0.5ms then my worst case skew from my 2ms
clock pulse is 1ms.
This makes it appear that the scheduler is affecting how proxies are
delivered.
The task waiting for the proxy is set at maximum priority and there is
nothing in the interrupt handler but the code to fire off the proxy.
What can I do to eliminate the relationship between the ticksize and clock
pulse?
Thanks
“Tony Ganote” <Tony.Ganote@wpafb.af.mil> wrote in message
news:9h7o4n$mcc$1@inn.qnx.com…
We have a clock pulse coming into the parallel port of our PC. There is
an
interrupt handler for IRQ7 that fires off a proxy that a task is doing a
Receive on.
The problem is that qnx_ticksize effects the amount of skew from the clock
pulse.
That is if qnx_ticksize is set to 2ms then my worst case skew from my 2ms
clock pulse is 4ms. (The 4ms firing of the task then is followed by a
300us
firing, to “make up” for the holdoff.)
If the qnx_ticksize is set to 0.5ms then my worst case skew from my 2ms
clock pulse is 1ms.
This makes it appear that the scheduler is affecting how proxies are
delivered.
The task waiting for the proxy is set at maximum priority and there is
nothing in the interrupt handler but the code to fire off the proxy.
What can I do to eliminate the relationship between the ticksize and clock
pulse?
To my knowledge there is no relation ship. A rescheduling occurs after
the interrupt. How to you measure this effect.
Thanks
The timeline should be like this:
- IRQ 7 fires
- Possible delay due to another higher priority interrupt being processed.
- IRQ 7 Interrupt handler runs, exiting with Proxy PID
- Scheduler runs and picks highest priority process
- Highest priority process runs
It is unlikely that step 2) is the hold up. However if another
process is running at your priority or higher, you will not run
at step 5, but rather will have to wait. Otherwise you should
run immediately.
Previously, Tony Ganote wrote in qdn.public.qnx4:
We have a clock pulse coming into the parallel port of our PC. There is an
interrupt handler for IRQ7 that fires off a proxy that a task is doing a
Receive on.
The problem is that qnx_ticksize effects the amount of skew from the clock
pulse.
That is if qnx_ticksize is set to 2ms then my worst case skew from my 2ms
clock pulse is 4ms. (The 4ms firing of the task then is followed by a 300us
firing, to “make up” for the holdoff.)
If the qnx_ticksize is set to 0.5ms then my worst case skew from my 2ms
clock pulse is 1ms.
This makes it appear that the scheduler is affecting how proxies are
delivered.
The task waiting for the proxy is set at maximum priority and there is
nothing in the interrupt handler but the code to fire off the proxy.
What can I do to eliminate the relationship between the ticksize and clock
pulse?
Thanks
\
–
Mitchell Schoenbrun --------- maschoen@pobox.com
Okay, here’s the deal. Via the glory of cut and paste the priority of the
proxy was not high enough. Also, to get better dithers (35-50usec) I
rebuilt the kernel with “Proc32 -i 7”.
Oh well…
Tony Ganote <Tony.Ganote@wpafb.af.mil> wrote in message
news:9h7o4n$mcc$1@inn.qnx.com…
We have a clock pulse coming into the parallel port of our PC. There is
an
interrupt handler for IRQ7 that fires off a proxy that a task is doing a
Receive on.
The problem is that qnx_ticksize effects the amount of skew from the clock
pulse.
That is if qnx_ticksize is set to 2ms then my worst case skew from my 2ms
clock pulse is 4ms. (The 4ms firing of the task then is followed by a
300us
firing, to “make up” for the holdoff.)
If the qnx_ticksize is set to 0.5ms then my worst case skew from my 2ms
clock pulse is 1ms.
This makes it appear that the scheduler is affecting how proxies are
delivered.
The task waiting for the proxy is set at maximum priority and there is
nothing in the interrupt handler but the code to fire off the proxy.
What can I do to eliminate the relationship between the ticksize and clock
pulse?
Thanks