Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site xios.UUCP
Path: utzoo!dciem!nrcaer!xios!greg
From: greg@xios.UUCP (Greg Franks)
Newsgroups: comp.unix.wizards
Subject: Re: beating time
Message-ID: <359@xios.UUCP>
Date: Tue, 18-Nov-86 10:22:49 EST
Article-I.D.: xios.359
Posted: Tue Nov 18 10:22:49 1986
Date-Received: Thu, 20-Nov-86 10:28:02 EST
References: <1346@PUCC.BITNET>
Reply-To: greg@xios.UUCP (Greg Franks)
Organization: Xios Systems Corp., Ottawa, Ont.
Lines: 26
Summary: 

In article <1346@PUCC.BITNET> D0430@PUCC.BITNET writes:
>Can someone tell me why the following short program keeps such lousy
>time? (metronome emulator)  I tried it under Ultrix 1.1 and 4.2.
>I would expect some granularity but not to the extent I saw.  With an
>argument of 1, for example, there are sometimes errors of as much as 50%

I am no Berserkeley expert, but I have written some real time operating
system kernels, so I can tell you that multiuser computer systems make
lousy interval timers.  You are the victim of scheduling delay.  The
signal goes off - your process gets scheduled.  Now you wait for every
one else in front of your process in the run queue to execute.  Once
they are finished you get to run.  You also have to wait for all other
interrupt processing to complete.  So if the computer is being beaten to
death by TTY's, disks and what have you, you wait.  The more users, the
worse it gets.  The infinite loop at the bottom of the program will
probably cause the scheduler to lower your process's priority probably
to the point where you run dead last (just before the machine goes to
IDLE).  I must admit that I don't know what effects signals have on
priority though. 

For accurate interval timing, use a real-time operating system designed
for the task (gasp - VAX/VMS might be useful :-), or use real hardware. 
The latter is probably the best (and cheapest) bet!

Happy hacking!
  Greg Franks