eprice@sagpd1.UUCP (Eric Price) (12/14/90)
Dear Netlanders,
I'm working on rewriting and optimizing some code for my company's
product. Currently our baseline software consists of a ruotine that
when interrupted in real time (say less than < 1200 times per second)
posts a message to a VRTX queue. The message is pulled of the queue
and serviced. To optimize our code and allow the system to really
scream we have decided to let the interrupt perform the actual
message service routine, thus eliminating the overhead of passing
the message. Currently I am noticing some strange timing problems.
What I need to know is: Does anyone out in Netland have any exerience
with a problem similar to mine. All questions, comments and suggestions
will be gladly appriciated.
Thanks in Advance,
Ericyoke@iccgcc.decnet.ab.com (Michael Yoke) (12/21/90)
In article <968@sagpd1.UUCP>, eprice@sagpd1.UUCP (Eric Price) writes: > Keywords:Project is Classified so I can't be too specific. > > > Dear Netlanders, > > I'm working on rewriting and optimizing some code for my company's > product. Currently our baseline software consists of a ruotine that > when interrupted in real time (say less than < 1200 times per second) > posts a message to a VRTX queue. The message is pulled of the queue > and serviced. To optimize our code and allow the system to really > scream we have decided to let the interrupt perform the actual > message service routine, thus eliminating the overhead of passing > the message. Currently I am noticing some strange timing problems. > What I need to know is: Does anyone out in Netland have any exerience > with a problem similar to mine. All questions, comments and suggestions > will be gladly appriciated. > > Thanks in Advance, > > Eric One of the problems with doing a lot of computing in an interrupt service routine is that it adds a lot of latency (sometimes unpredictable) to a system. As long as the system is executing an interrupt service routine, task switches are delayed. If the execution time of your interrupt service routine varies (i.e. is dependent upon the particular message you happen to be servicing), then you can't say with any real certainty how long it's going to take for your system to respond to some event which is handled at the task level. This could be the cause of your strange timing problems. To solve your problem, three things come to mind: 1. Change your code back to the way it was. 2. Don't use VRTX message queues. I had a problem similar to yours that I was able to solve by polling a longword at the task level and filling the longword at the ISR level. Of course, the polling approach may not be acceptable in your situation. 3. Use a more efficient operating system. Mike