Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!lll-lcc!qantel!hplabs!pesnta!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch,net.micro.mac,net.micro.68k Subject: Re: timing loops Message-ID: <1980@peora.UUCP> Date: Mon, 24-Feb-86 09:06:33 EST Article-I.D.: peora.1980 Posted: Mon Feb 24 09:06:33 1986 Date-Received: Wed, 26-Feb-86 07:43:15 EST References: <156@motatl.UUCP> <530@hoptoad.uucp> <2795@amdahl.UUCP> <221@myrias.UUCP> <2817@amdahl.UUCP> <689@well.UUCP> Organization: Concurrent Computer Corporation, Orlando, Fl Lines: 35 Xref: linus net.arch:2414 net.micro.mac:4841 net.micro.68k:1453 > I admit to knowing little about the S/370, but a 4 GHz clock rate? > Can someone verify this, please? I don't remember seeing any microwave > plumbing in a 370... :-) Actually this involves a really interesting aspect of the nature of "time" on a computer. Suppose you have (hopefully without loss of generality :-)) a machine all of whose instructions take the same amount of time to execute. Suppose it can execute 32,768 instructions per second. Now, suppose you have a clock that counts in 1/65536ths of a second. Then, as far as you are concerned, it's impossible to tell the clock is running that fast... depending on when you began execution relative to the counter in the clock, the low-order bit will always be a zero or one every time you look at it. Although it's possibly not as obvious, the same thing happens if you don't have such "round" numbers... if the timer is counting faster than your CPU's basic cycle time (and if the CPU runs with a fixed-rate clock) then the timer's counter will appear to be being incremented by some constant value, and there's no way to tell it's going faster than that. So, you can replace the faster timer with a much slower one that increments its counter by this integer, and no one will be able to tell the difference. Of course, this assumes that the timer doesn't do anything else, e.g., control some external devices which rely on the faster clock rate. Actually this generalizes to an even more interesting idea, viz., that if a CPU doesn't have any kind of reliable external clock to measure time against, then if you stop the CPU's clock occasionally, or make it run irregularly, the CPU's "idea" of time will be such that events external to it that are happening at a constant rate will appear to the CPU to be occurring irregularly. So you get to experiment a little with the relativistic nature of time this way. -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCUR.UUCP CCUR DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642