home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sgi / 18337 < prev    next >
Encoding:
Text File  |  1992-12-25  |  2.9 KB  |  68 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!venezia!penev
  3. From: penev@venezia (Penio Penev)
  4. Subject: Re: How Accurate Is The System Clock
  5. References: <AJ3U.92Dec24203137@larch.cs.virginia.edu>
  6. Sender: nobody@ctr.columbia.edu
  7. Organization: Rockefeller University
  8. Date: Fri, 25 Dec 1992 18:59:31 GMT
  9. X-Newsreader: TIN [version 1.1 PL6]
  10. Message-ID: <1992Dec25.185931.28426@sol.ctr.columbia.edu>
  11. Reply-To: penev@venezia.rockefeller.edu
  12. X-Posted-From: venezia.rockefeller.edu
  13. NNTP-Posting-Host: sol.ctr.columbia.edu
  14. Lines: 52
  15.  
  16. Asim Jalis (aj3u@larch.cs.virginia.edu) wrote:
  17. : What I am concerned about is not the accuracy of the clock, so
  18. : much as the length of the delay between calling the time function
  19. : and getting a response.  This delay could be produced if the
  20. : scheduler unschedules my process before the clock daemon has
  21. : responded to its query, or it could be produced if the clock
  22. : daemon was woken when the clock interrupt occurred because the
  23. : cpu was doing something else that was important, or for some
  24. : other reason arising out of the multi-process environment.
  25. : 
  26. : Testing could be used to get a general idea of how large this
  27. : delay can be.  However, I want to get more confidence about this.
  28.  
  29. I just tested this with the following FORTH code:
  30. : TARA FOR 0 DROP NEXT ; 
  31. : CLOCK  FOR 0 TIME NEXT ; ok
  32.  
  33. COUNTER 5000000 CLOCK TIMER 51000 ok
  34. COUNTER 5000000 TARA  TIMER 1000 ok
  35.  
  36. The numbers are miliseconds, the resolution is 1 second. Timing is the
  37. overall timing (not user) on an unburdened system. This gives 
  38. ~ 10 microseconds per time(2) call. On my 33MHz R3000 this equivalent
  39. to ~ 330 instructions. Subtract 10 ( the FORTH overhead). This seems
  40. a little bit high for a decision making, address check and return of a
  41. variable, but seems low enough for the designers of the OS to have been
  42. tempted to multitask.
  43.  
  44. This of course does not answer Your questions.
  45.  
  46. : (1) Do the specifications of the operating system provide some
  47. : kind of a guarantee about timing accuracy in its multi-process
  48. : environment?  (2) Is the code of the operating system public
  49. : domain? (3) If not, then is the scheduler's design similar enough
  50. : to Unix so that Unix sources can be studied for an answer to my
  51. : problem.
  52.  
  53. Suppose the following situation: The specifications of the operating
  54. system _does_ provide a guarantee about timing accuracy. That means,
  55. that Your time variable is accurate a few instructions after the
  56. system time(2) of itimer(2) calls. This means nothing, because _after_
  57. the call Your process might be suspended in favor of other processes.
  58.  
  59. What You really need (IMHO) is a specification of the occasions in
  60. which control is switched between processes and a semaphore for the
  61. processor, so You might say smth. like that:
  62. PROCESSOR GET  < do time-accuracy critical job > PROCESSOR RELEASE
  63.  
  64. As far as my knowledge spreads, this has never been a design goal of
  65. UNIX.
  66.  
  67. -- Penio.
  68.