home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / wizards / 5336 < prev    next >
Encoding:
Text File  |  1992-12-25  |  1.6 KB  |  39 lines
  1. Newsgroups: comp.unix.wizards
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!caen!uvaarpa!murdoch!murdoch.acc.virginia.edu!aj3u
  3. From: aj3u@larch.cs.virginia.edu (Asim Jalis)
  4. Subject: Does Unix Guarantee Limits on Delays
  5. Message-ID: <AJ3U.92Dec25152444@larch.cs.virginia.edu>
  6. Sender: usenet@murdoch.acc.Virginia.EDU
  7. Organization: University of Virginia, Charlottesville, VA 22903
  8. Distribution: comp
  9. Date: Fri, 25 Dec 1992 20:24:44 GMT
  10. Lines: 27
  11.  
  12. The problem that I am working with is this.  I want to time the
  13. interval between the occurrence of two mouse events.  I want to
  14. have some confidence in the accuracy of my readings, independent
  15. of the number of other processes running on the system or their
  16. nature.
  17.  
  18. Does Unix guarantee, either explicitly, or implicitly through the
  19. way it is designed, that a call to the clock daemon will return
  20. within a certain fixed upper limit amount of time?  Possible
  21. sources of delays could be task-switching by the scheduler, or
  22. the clock daemon not responding immediately for some reason;
  23. there might be others that people here could suggest.  Also,
  24. consider the same question but with this time querying about
  25. bounds on the execution of each ordinary instruction.
  26.  
  27. If Unix does not provide such guarantees then I would like
  28. suggestions on how testing could establish a worst case upper
  29. bound on this delay.  For example, I could have N1 infinite loop
  30. processes running and N2 processes that repeatedly call the clock
  31. daemon and N3 i/o processes etc.  Are there any other classes of
  32. processes that could make a significant difference in how the
  33. scheduler and the clock daemon behave?
  34.  
  35. Any help would be much appreciated.
  36.  
  37.  
  38. Asim Jalis.
  39.