Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!orsvax1!pyrnj!caip!seismo!rochester!ritcv!ccice5!ccivax!rb
From: rb@ccivax.UUCP (rex ballard)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: timing loops
Message-ID: <448@ccivax.UUCP>
Date: Wed, 5-Mar-86 22:22:59 EST
Article-I.D.: ccivax.448
Posted: Wed Mar  5 22:22:59 1986
Date-Received: Sat, 8-Mar-86 21:31:29 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <6780@boring.UUCP> <9645@amdcad.UUCP> <6790@boring.UUCP> <443@ucsfcca.UUCP>
Reply-To: rb@ccivax.UUCP (What's in a name ?)
Organization: CCI Telephony Systems Group,  Rochester NY
Lines: 20
Xref: watmath net.arch:2727 net.micro.mac:5009 net.micro.68k:1549

In article <443@ucsfcca.UUCP> dick@ucsfcca.UUCP (Dick Karpinski) writes:
>In article <6790@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes:
>>
>I thought someone suggested a solution:  Build a timing loop, but
>set its constant (how many cycles) using some other, possibly low
>precision, timer to see how fast the loop is _today_ with this
>compiler/clock/cpu-chip/whatever.  I _think_ that one can usually
>count on those things remaining constant _during_ this run of the
>program, i.e. between reboots of the OS.  I have heard of systems
>which change their cpu clock on the fly, but you probably know
>that when you write the device driver.  Is that enough?
>
>Dick
>-- 
This works ok UNLESS you have a high speed cache (like the 68020)
AND are servicing non-maskable interrupts.  The timing in a tight
loop can wander all over the place, depending on how often the
interrupts scramble your cache.  Problems can ALSO occur when
co-processors or multiple DMA devices are sharing the bus and your
processor has low priority.