Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!mips!prls!pyramid!cbmvax!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: ATT Unix millisec clock Message-ID: <3984@auspex.auspex.com> Date: 29 Aug 90 22:20:38 GMT References: <13494@smoke.BRL.MIL> Organization: Auspex Systems, Santa Clara Lines: 34 >a) something like a profiler with millisecond resolution to time > how long a C-function takes to execute. > BTW, thanks to all of you who replied suggesting the times() system > call. He uses that now, though something that has a better resolution > would be more useful. Not all systems *provide* a better resolution. Systems with BSD-style "gettimeofday()" may offer a field that's the "microsecond" part of a time, but most of them don't keep that field correct to the microsecond. In a lot of systems, what you see from "times()" is what you get.... >b) a sleep() call with millisecond or tenth of second resolution. There are tricks you can pull with "poll()". In fact... > Curses has a napms() function that supposedly does exactly that, ...the "napms()" function in S5R3.1 (and probably in the S5R3.2 the original poster mentioned) uses that very technique. The call is: (void) poll((struct pollfd *)0, 0L, ms); as it appears in the S5R3.1 "curses"; "ms" is the number of milliseconds to sleep. ("select()" is used on other systems in a similar fashion.) > but I'm told it is unreliable (i.e. doesn't really nap milliseconds, > but 1 / HZ seconds). If so, it's for the same reason I mentioned under a), namely that you don't *get* millisecond resolution from all systems; you tend to get 1/HZ resolution. (Lots of UNIX systems handle time by setting up the hardware to interrupt them once every 1/HZ seconds, and bumping a counter in the interrupt routine. Some may be more sophisticated, but not all are.)