Excerpted from message dated 05-18-95, Paul Sidorsky to Murray Lesser:
   (original subject: Borland C++ (OS/2))

PS>In a message written on Wednesday May 17 1995, Murray Lesser insanely
  >babbles to Paul Sidorsky:

Paul--

[Sermon mode on]  I (and perhaps others) find quote headers similar to
the one you use not only very unprofessional, but also insulting.  My
first impulse was to not reply to your query, as insane babbles merely
waste echo bandwidth.  [Sermon mode off]

PS>                                                       The thing
  >I'm wondering is how you get, say, the 1/10000th of a second
  >precision timings you see in Turbo Profiler for DOS.  From what I
  >know the computer has a timing "port" that you can configure to time
  >up to something like 1/100000th of a second.  I can only assume that
  >this port doesn't use the system clock, but if that's the case then
  >what _does_ it use?  Or are times not as accurate as they appear to
  >be?

    In DOS, where the application programmer can get hands-on control of
the hardware, you can measure event times to a nominal accuracy of 838.1
nanoseconds, by directly reading the count-down-register value of timer
channel 2 (normally used to drive the speaker) and the system clock. The
technique is described in Michael Abrash's (unfortunately) out-of-print
book: "Zen of Assembly Language" under the heading "The Zen
Timer."

Abrash claims "relative timings" good to 10 microseconds (0.000010
second) when the technique is used with care.

    As I understand it, there are similar ways to measure very small
time intervals under OS/2, since the hardware hasn't changed, but these
require delving into device drivers--something I know nearly nothing
about.  There is a profiler that comes with CSet++ (EXTRA) that requires
having loaded its device driver before it can be used.  Perhaps one of
the DD gurus in this conference might wish to stick an oar in.

    The times displayed by profilers undoubtedly are not as accurate as
they appear to be.  There is always an "uncertainty principle" when
using the system to measure its own performance; it takes time to watch
for and time-stamp events.

PS>       I don't know very much about the hardware goings-on, so I
  >usually only guess at that kind of stuff.  One of these days I'll
  >sit down and learn all this fancy stuff, but until then I'll have to
  >stumble along.

    Guessing is good, especially when it is backed up with a few
intelligent experiments.  But, after you have guessed, (as my old
colleague Perrin Smith used to say) "Don't get carried away by a flood
of logic."  If you aren't sure about the guess, ask.  If you post
incorrect guesses, you will hear from someone .  (Even if you are
right, you might hear from someone!)

    Actually, unless you want to design or build hardware, all you
really need to know is the hardware architecture--the interfaces between
the hardware device and the programmer.  This is that good stuff that
used to come in the old IBM "Technical Reference" manuals but is hard to
find these days.

          --Murray
___
 * MR/2 2.23 #120 * Prediction is very difficult, especially about the future
                 
---