freiss@nixpbe.UUCP (the hacker) (08/03/90)
This is posted for a friend who does not have usenet access. Please reply to me, freiss.pad@nixdorf.com So far, only SECOND resolution is permitted through the ATT Unix OS to time the elapsed time of a job. Millisecond resolution (or better) accessed from a .c executable is desired. I am running ATT Unix Version System 5 Version 3.2 on a Motorola 68020 based machine. System interrupts? Shell commands? Any solution to this thorny problem would be greatly appreciated... Sincerely, Nick Kiyoshi KAWAGUCHI
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/06/90)
In article <freiss.649671180@peun33> freiss@nixpbe.UUCP (the hacker) writes:
-So far, only SECOND resolution is permitted through the ATT Unix OS to time
-the elapsed time of a job. Millisecond resolution (or better) accessed
-from a .c executable is desired. I am running ATT Unix Version System 5
-Version 3.2 on a Motorola 68020 based machine.
-System interrupts? Shell commands? Any solution to this thorny problem would
-be greatly appreciated...
Unfortunately, you have not stated a problem, but rather a desired SOLUTION.
If we knew what the real problem to be solved was, perhaps we could suggest
something helpful.moeller@uniol.UUCP (Klaus Moeller) (08/09/90)
freiss@nixpbe.UUCP (the hacker) writes: >So far, only SECOND resolution is permitted through the ATT Unix OS to time >the elapsed time of a job. Millisecond resolution (or better) accessed >from a .c executable is desired. I am running ATT Unix Version System 5 >Version 3.2 on a Motorola 68020 based machine. >System interrupts? Shell commands? Any solution to this thorny problem would >be greatly appreciated... We faced the same problem, finer than one-second resolution, here before. We use SysV3.1 on a 68020 type too (with some BSD enhancements). IF you have the select call on your machine, you can build yourself a fine tuneable sleep call. Simply build an empty file set and select on it with the numbber of milliseconds you want to sleep. Since the call has nothing to select, it will time out and your program will resume after that number of millseconds. If you want to have a millisecond - precise clock or somthing like that, I'm sorry, I can offer no help. Klaus Moeller -- / Klaus Moeller, Leiteweg 2, 2940 Wilhelmshaven, West - Germany \ < moeller@uniol.uucp 078326@DOLUNI1.BITNET > \ Fill what's empty, empty what's full and scratch where it itches /
freiss@nixpbe.UUCP (the hacker) (08/09/90)
In <13494@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In article <freiss.649671180@peun33> freiss@nixpbe.UUCP (the hacker) writes: >-So far, only SECOND resolution is permitted through the ATT Unix OS to time >-the elapsed time of a job. Millisecond resolution (or better) accessed >-from a .c executable is desired. I am running ATT Unix Version System 5 >-Version 3.2 on a Motorola 68020 based machine. >-System interrupts? Shell commands? Any solution to this thorny problem would >-be greatly appreciated... >Unfortunately, you have not stated a problem, but rather a desired SOLUTION. >If we knew what the real problem to be solved was, perhaps we could suggest >something helpful. Right :-) ok, what Nick Kawaguchi wants is 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. b) a sleep() call with millisecond or tenth of second resolution. Curses has a napms() function that supposedly does exactly that, but I'm told it is unreliable (i.e. doesn't really nap milliseconds, but 1 / HZ seconds). My guess is it's impossible, but then I'm not very wizardly concerning UN*X. All hints are appreciated. Thanks, -Martin freiss.pad@nixdorf.com
thomas@uplog.se (Thomas Tornblom) (08/09/90)
In article <3213@uniol.UUCP> moeller@uniol.UUCP (Klaus Moeller) writes: freiss@nixpbe.UUCP (the hacker) writes: >So far, only SECOND resolution is permitted through the ATT Unix OS to time >the elapsed time of a job. Millisecond resolution (or better) accessed >from a .c executable is desired. I am running ATT Unix Version System 5 >Version 3.2 on a Motorola 68020 based machine. >System interrupts? Shell commands? Any solution to this thorny problem would >be greatly appreciated... We faced the same problem, finer than one-second resolution, here before. We use SysV3.1 on a 68020 type too (with some BSD enhancements). IF you have the select call on your machine, you can build yourself a fine tuneable sleep call. Simply build an empty file set and select on it with the numbber of milliseconds you want to sleep. Since the call has nothing to select, it will time out and your program will resume after that number of millseconds. If you want to have a millisecond - precise clock or somthing like that, I'm sorry, I can offer no help. Klaus Moeller -- / Klaus Moeller, Leiteweg 2, 2940 Wilhelmshaven, West - Germany \ < moeller@uniol.uucp 078326@DOLUNI1.BITNET > \ Fill what's empty, empty what's full and scratch where it itches / Check out times(2). The return value is the number of ticks (interrupts) "from an arbitrary point in the past". The tick frequency can be obtained from <sys/param.h> as HZ. Normally it will be between 50 and 100 so you wont get ms accuracy. 50 to 100 times better than seconds anyhow. Nowhere in my manual can I find anything saying that the RESOLUTION is in seconds, only that the times are reported in seconds. On our machines we have at least one decimal yielding 100ms resolution. Thomas -- Real life: Thomas Tornblom Email: thomas@uplog.se Snail mail: TeleLOGIC Uppsala AB Phone: +46 18 189406 Box 1218 Fax: +46 18 132039 S - 751 42 Uppsala, Sweden
guy@auspex.auspex.com (Guy Harris) (08/10/90)
>We faced the same problem, finer than one-second resolution, here before. >We use SysV3.1 on a 68020 type too (with some BSD enhancements). Such as the "select()" call you used.... >IF you have the select call on your machine, you can build yourself a >fine tuneable sleep call. Or try the same trick with "poll()", if you don't have "select()". >If you want to have a millisecond - precise clock or somthing like that, >I'm sorry, I can offer no help. If you want the wall-clock time to higher resolution, you need an extension such as "gettimeofday()" (some systems, including S5R4, have this). If you want alarms delivered with finer-than-one-second granularity, you need an extension such as "setitimer()" (some systems, including S5R4, have this). If you want to compute the *interval* between two events with finer-than-one-second resolution, check out the "times()" call - it runs the number of clock ticks (as defined by HZ in <sys/param.h>) since some unspecified event in the past (typically, but not necessarily, the time at which the machine was booted). You can subtract two of those return values to get the interval with finer-than-one-second resolution.
guy@auspex.auspex.com (Guy Harris) (08/30/90)
>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.)