Path: utzoo!attcan!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!news
From: CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel)
Newsgroups: comp.lang.pascal
Subject: (R)Interesting: interaction between Timing and DELAY in TP
Message-ID: <24932@adm.BRL.MIL>
Date: 5 Nov 90 14:29:31 GMT
Sender: news@adm.BRL.MIL
Lines: 75


In article <56213@unix.cis.pitt.edu>,
  "Chunqing N. Cheng" <cncst3@unix.cis.pitt.edu> writes:

... stuff deleted ...
    1.   initialize timer
         in my unit, first set INCREASE_CLOCK_SPEED_BY:=55
         which gives 1001 clicks every one second.
         TPtimer is set to be 1000 clicks every one second
         by default.
    2.   mark the begin time
    3.    DELAY(Given_time)
    4.   get the end Time;
    5.  Elapsed_clicks = End_time - Start_time
    6.  Elapsed_time
         t = Elapsed_click/18.2/INCREASE_CLOSK_SPEED_BY  (my unit)
         t = Elapsedtime(end_time,start_time)            (TPTimer unit)


(1) overhead time is proportional to the Given_time in DELAY procedure.
    it is very very funny phenomena!!!!
    it is true in both cases.  The rough numbers are:

      Given_time      Elapsed click numbers   Times in second
       1000                1196                 1.194 (my unit)
                           1195                 3598???(TPtimer unit)
       2000                2392                 2.388 (my unit)
                           2389                 3597???(TPtimer unit)
       3000                3588                 3.581 (my unit)
                           3584                 3596??(TPtimer)
      ......
(2)  calibration of TPTIMER seems to me doing more harm than good.
     Note the click number and the time in second of TPTimer unit
     are divided by 1000 before listing them.  I think the document
... stuff deleted ...
(3) why overhead time is proportional to the time in the delay
    procedure, any comment from any body, Borland people,
    Turbo Power people?  Can we trust delay routine in this
    matter?
... stuff deleted ...
  ==end of quotation==

I don't think we need to call in Borland or TurboPower just yet.
Instead, call TPTimer.ElapsedTime with the parameters in the correct
order, not "Elapsedtime(end_time,start_time)", but
Elapsedtime(start_time,end_time)".

Here are examples calling it the right way, then the wrong way. Note how
the second example agrees with your results. Also notice the close
agreement between TPTimer and Delay.

Calling "ElapsedTimeString(start_time,end_time)" :
  For a Delay of 1000, TPTimer returned 999.757 msec.
  For a Delay of 2000, TPTimer returned 1999.503 msec.
  For a Delay of 3000, TPTimer returned 2999.285 msec.

Calling "ElapsedTimeString(end_time,start_time)" :
  For a Delay of 1000, TPTimer returned 3598592.296 msec.
  For a Delay of 2000, TPTimer returned 3597592.549 msec.
  For a Delay of 3000, TPTimer returned 3596592.769 msec.

While the nominal difference between the Delay value and the return from
TPTimer is roughly proportional to the Delay value, this is not
unexpected. "Output" from similar processes with differing, but
more-or-less constant, rates will differ proportionally to the timing
period.

+-------------------------------------------------------------------------+
| Karl Brendel                                Centers for Disease Control |
| Internet: CDCKAB@EMUVM1.BITNET              Epidemiology Program Office |
| Bitnet: CDCKAB@EMUVM1                       Atlanta, GA, USA            |
| ILink/RIME: KARL BRENDEL                    phone 404/639-2709          |
| CIS  : 73307,3101                           fts       236-2709          |
| GEnie: K.BRENDEL                            Home of Epi Info 5.0        |
+-------------------------------------------------------------------------+