In a message on 01-23-95, Ed Becker said to Peter Hansen:

PH> Actually, that's almost the documented ceiling on the _thread
PH> dispatch delay_, not the interrupt latency.  For interrupts the
PH> number is something like 400 microseconds "guaranteed" with typical
PH> values more like 70 microseconds, all depending on the processor of
PH> course.

EB>Where are you getting this information?  I would be defintely
EB>interested in reading whatever material will give me this sort of
EB>information.

The "documented" stuff is from the book "The Design of
OS/2" which is
the mainstay description of that kind of thing, written by Deitel and
Kogan (from memory) and as I don't have it handy I can't give the ISBN
for now but you should have no difficulty tracking it down.

The undocumented stuff (like "typical" values) is from email with
various people that I've tracked down as knowing about this kind of
thing, and in many cases having written many, many device drivers and
such that involve interrupts and timing and whatnot.  The typical value
I quote above came from discussions with Steve Mastrianni, author of the
book "Writing OS/2 2.1 Device Drivers in C" published by Van Nostrand
Reinhold.  He did not do the actual measurements but relayed them to me
and confirmed them.  The measurement of 60-70 nominal/typical was on a
486DX33.  On the same system the worst case measurement was 334 micros.
On a loaded system with swapping and such the thread dispatch delay
actually increased from the "guaranteed" 6 milliseconds to more than 25.

I have not actually written any of this stuff myself because the
conclusion of my research, at this point, is that OS/2 cannot support
the project that I have without more investment than I am willing to
give it right now.  I continue to try to learn more in this area,
however, since the time may come...

Basically, the information is out there and if you work hard and track
it down (and ask nicely via email :-) you will find whatever nugget you
are looking for.  In most cases actually implementing a test to measure
results for your own situation would be the best bet.  Publishing the
results here or elsewhere -- which it's unfortunate but understandable
more people haven't done (competitive advantage) -- would be a very
welcome contribution.  Actually, I dislike posting these tidbits without
having checked them out myself, but as nobody else who should know
better seems to be posting hard information I saw little choice.  I was
kind of hoping my posts would bring forth discussions and possibly
corrections from those more knowledgeable but it hasn't happened yet...

------------------------------------------------------------------------
 Peter Hansen                                     Engenuity Corporation
 Internet: peter{at}engcorp.com                    Guelph, Ontario, Canada
___
 * MR/2 * Now cruising at Warp 3!

--- QScan v1.14b / 01-0348