jec@iuvax.UUCP (08/08/86)
On of the professors here at IU is trying to get accurate timings on UNIX for user and system times. The problem is that I can't figure out a way to get accurate timings or explain the variations in timing that I get from time(1). Could some one please fill me in on what could account for the variations in timing? The following is part of the message I received: --------- The following timings were generated by repeated invokations of the script: |# |set NEW = /usr/local/bin/somecommand |time $NEW <<HERE |<some input> |HERE all within an hour. The results were ----------------------------------------- |28.4u 3.3s 0:48 65% 96+695k 6+2io 52pf+0w |26.2u 2.9s 0:47 61% 96+670k 4+2io 3pf+0w |26.1u 2.7s 0:37 76% 96+674k 4+2io 3pf+0w |28.9u 3.1s 0:57 56% 96+688k 4+2io 3pf+0w |30.2u 3.4s 0:50 66% 96+685k 3+2io 3pf+0w |30.8u 3.5s 1:04 53% 96+699k 3+2io 3pf+0w |31.5u 4.2s 1:40 35% 95+675k 4+2io 3pf+0w |30.6u 4.4s 1:46 32% 96+657k 6+3io 3pf+0w |30.7u 3.2s 1:07 50% 96+673k 6+2io 3pf+0w |32.1u 3.6s 1:04 55% 96+691k 3+2io 3pf+0w |----------------------------------------- Can you see any factors that would account for a twenty per-cent variation in user-execution time? We have similar results from MINOR variations of the object, using older routines. The effect seems to be related to the size of load-image of a particular object. Again, these are timings for IDENTICAL execution runs. --------
chris@umcp-cs.UUCP (08/10/86)
In article <1200016@iuvax.UUCP> jec@iuvax.UUCP writes: >Could some one please fill me in on what could account for the >variations in timing? Without knowing the actual system and program involved, I cannot say for certain, but it is likely that all of the variation you have observed is due to cacheing. Assuming you are on a Vax, there are two hardware caches to consider (`the cache' and the TLB), and if you do any disk I/O you are also using the Unix buffer cache. If your machine is low on memory you may experiene paging effects; and if not, the first run will take a bit more time to load the executable into memory. Subsequent runs will reclaim the pages without any disk reads. Then, too, there is the fact that the timing statistics are gathered with a 100 hz clock which is synchronised with hardware clock interrupts, which does not help any. For statistics-gathering without extra hardware, the best course seems to be to produce long-term averages under various conditions. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
badri@ur-valhalla.UUCP (Badri Lokanathan) (08/10/86)
In article <2888@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >In article <1200016@iuvax.UUCP> jec@iuvax.UUCP writes: >>Could some one please fill me in on what could account for the >>variations in timing? > A minor point: In addition to what Chris Torek said I would like to point out that time is built into csh and leads to output in a different format from /bin/time. If you use csh then time does not do *exactly* what /bin/time does. -- "It's better to burn out ^ ^ ARPA: ur-valhalla!badri@rochester.arpa Than it is to rust; . . UUCP: {bullwinkle,cmcl2,columbia,cornell, But I'll corrode ( ==@== ) harvard,ll-xn,nike,seismo,topaz} Till I turn to dust." ^^^ !rochester!ur-valhalla!badri
tgoodwin@houligan.UUCP (08/15/86)
The only way I have felt comfortable with UNIX time results is to
run on an an otherwise idle system. Due to the rather sloppy time
handling and accounting, variation on a loaded system is to be
expected.
Tom Goodwin
{sun,brl-bmd,pur-ee}!gould!tgoodwin