Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site amdahl.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!amdcad!amdahl!mat
From: mat@amdahl.UUCP (Mike Taylor)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: timing loops
Message-ID: <2817@amdahl.UUCP>
Date: Thu, 20-Feb-86 11:20:19 EST
Article-I.D.: amdahl.2817
Posted: Thu Feb 20 11:20:19 1986
Date-Received: Fri, 21-Feb-86 07:43:38 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <2795@amdahl.UUCP> <221@myrias.UUCP>
Organization: Amdahl Corp, Sunnyvale CA
Lines: 24
Xref: watmath net.arch:2575 net.micro.mac:4742 net.micro.68k:1501

In article <221@myrias.UUCP>, cmt@myrias.UUCP (Chris Thomson) writes:
> In article <2795@amdahl.uucp> Mike Taylor writes:
> > Well, on a *real* computer, you just set the TOD clock comparator for
> > now+2.2 us. and go do something useful while you wait.  Sorry, couldn't
> > resist.
> 
> C'mon Mike!  Even a 5860 takes >5 us to context switch (twice).

Yes, but context switching isn't useful! Actually, just trying to point
out that for timing like 2.2 us., regardless of how good your timing
facility is (S/370 architecturally has 244 picosecond resolution), you can't
ignore instruction timing.  Fielding the external interrupt when the
clock comparator "hits," even without a full context switch, will take quite
a few cycles to save registers, etc. before being able to do any useful
work.  What is even worse is the more or less unpredictable timing
delays due to cache effects, (consistency, misses) to say nothing of
EC level changes (a cycle here or there...)  It is probably true to
say that you can't usefully time anything to a resolution better
than plus or minus 20 cycles (300 ns.) even on a machine which has good
timing facilities.
-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]