latencies...

[ramu]

Hi,
Can anyone let me know how vxworks has achieved low latencies
(interrupt latency, context switch latency, semaphore latency) when
compared to other RTOSes?

Thanks and Regards,

[Sparky]

Ramu,

I don't know for certain if the following is why, but I imagine that
it does play a significant role.

The work queue.

To minimize interrupt latency, you obviously have to minimize the
time for which interrupts are locked. Interrupts get locked to
prevent an ISR from interrupting critical code and possibly forcing a
context switch, or messing with data.
Being the smart fellows that they are, the Wind River kernel
developers long ago realized that if you can statistically reduce the
average interrupt latency even time if you assume that most routines
called from within an ISR do not need to enter the kernel. Therefore,
a cooperating two-level locking system can be used ... interrupt locks
and kernel locks.

interrupt lock
... do stuff like error checking ...
enter kernel (lock)
interrupt unlock
... do stuff like queue manipulation ...
exit kernel (unlock)

If the ISR function call needs to enter the kernel, and the kernel is
not locked, it gets to go into the kernel and do its stuff. If
however, the kernel was locked, the work is deferred, put onto the
work queue, and a dummy OK return value is performed so that the ISR
can continue. Deferred work is processed when the task (or ISR) that
locked the kernel exits the kernel.

Sparky.

[sujay]

Sparky,
So do you mean that the worker queue is maintained by the kernel?
And will this behaviour be deterministic, ie., assume in one case
there ISR
went thru and took a kernel lock( because there was none initially)
Versus
another case where there is a kernel lock causing the worker queue to
kick in.
In both the cases the expected O/P may differ, as part of the job has
been deferred.

While talking about vxw5.5 and below, with no process/task address
space, and therefore
context checking/saving the latency will be low( ie the RTOS
behavior) , when it comes vxw6.0
I am seeing that latency will be hit, where the worker queue philosphy
has to be put in use.
Any other thoughts?

BR,
-Sujay

[Sparky]

Yes, the worker queue is maintained by the kernel. The size of the
work queue can be configured when you build your project.

The idea behind the work queue concept works because "statistically"
execution flow is seldom interrupted during kernel state AND most ISRs
do not need to make many kernel calls (if any). The more interrupts
in your system, the more likely this will happen, and the more likely
you will need a larger work queue. If it is too small, and it
overflows, then the system will reset due to a work queue panic.

The amount of time that is spent in kernel state is non-
deterministic. It depends upon many factors such as, but not limited
to ...
1. The type of work the kernel is doing in kernel state. For
example, it could be copying large amounts of data from one buffer to
another, or very little (msgQSend/msgQReceive). It could be trying to
sift through a very long, or a very short pend queue.
2. The interrupt rate.
3. The type and amount of work being done in an ISR.
4. The number and type of entries in the work queue (this ties in
with #1). The work queue is emptied/processed while in kernel state.

I hope this helps. If I remember correctly, VxWorks documentation
should have a section on the work queue.

Sparky