Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!aeh
From: aeh@mentor.cc.purdue.edu (Dale Talcott)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Need help programming SCC
Summary: Time Manager takes time
Keywords: Time Manager
Message-ID: <5105@mentor.cc.purdue.edu>
Date: 3 Feb 91 22:48:10 GMT
References: <1991Jan29.205455.26919@sol.UVic.CA> <27A8D317.5428@ics.uci.edu>
Distribution: na
Organization: Purdue University Computing Center
Lines: 32

In article <27A8D317.5428@ics.uci.edu> jchoi@ics.uci.edu (John Choi) writes:
jc>In article <...> marykuca@sol.uvic.ca (Brent Marykuca) writes:
bm>>We are trying to set up a fairly high-resolution timing device based
bm>>on the Time Manager's ability to run a task every millisecond.
...
jc>  When I set up a loop to increment a global variable
jc>every 5 or 10 counts, each incremented vaule seems to correspond to 1.05 msec
jc>over a range of minutes.  ...  I'm using THINK C 4.02 on a Mac II.

Only off by 5%.  You're lucky!  On a Mac Plus, a Time Manager PrimeTime()/
timer-task call pair takes about 0.2 to 0.3 ms, so trying to provide the
"millisecond accuracy" enamored of psychology types was loads of fun.  I
ended up using TickCount as an accurate counter of 1/60.15'ths of seconds
and then used TimeManager "milliseconds" to subdivide those ticks.  The
accuracy was thus +0 -5ms, irrespective of total duration.  On a II, you
should be able to get +0 -2ms.

An article by Lawrence D'Oliveiro says:
ld> According to my interim Inside Mac vol VI dated October 1990, the
ld> tmCount field is "set by RmvTime".

Wish I'd had IM VI!  Looks like the code just got lots simpler.  Not being
a trusting soul, though, I'll verify that several run-every-ms tasks don't
louse up the reported time for a long-duration task.  Does anyone know if
the VIA timer keeps running after it interrupts at the end of a Time
Manager interval, or is there "dead" time between the end of one interval
and when the Time Manager starts timing the next?  I suspect this is the
case, since one version of my code used two 2ms tasks running 1ms out of
phase with each other.  It didn't help.

Dale Talcott, Purdue University Computing Center
aeh@j.cc.purdue.edu, {purdue,pur-ee}!j.cc.purdue.edu!aeh, aeh@purccvm.bitnet