[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Feb 8 20:42:09 2003 
Subject:Re: (forwarded for Brian Logan) Poplog timers ... 
From:Roger . Evans 
Volume-ID:1030208.01 

I suspect the answer is simply 'no'. This is an OS constraint that 
poplog can do nothing about. I just checked back some ancient history 
(seems to be my role on this list :-) ), and discovered in the COGS 
$poplocal some libraries from 1985 which addressed exactly this problem 
- but that that was in the days when the standard pop functions had a 
resolution of 1 second, and the libraries externally load the c 
setitimer routines, which allow the time to be specified in 
microseconds, but have an effective clock of 100ths of a second. In 
other words, what you see in the current system is the effect of those 
libraries having migrated their way into poplog, sometime in the 
intervening 17 years!

The only thing I can suggest is that averaging over multiple runs of 
your code would give you higher resolution figures...

Roger

Aaron Sloman wrote:

>Non-member submission from [Brian Logan <bsl@cs.nott.ac.uk>]
>
>I have been trying to write some procedures to time the execution of Poplog
>code.
>
>systime has fairly poor resolution (1/100th of a second), so I happily wrote
>some timing procedures using sys_timer and trap procedures.  This didn't
>work, and on closer reading of REF TIMES I discovered that the maximum
>resolution of the asynchronous trap procedures created by sys_time is also
>1/100th of a second.
>
>usecs_or_false -> sys_timer(ast_p, flags)
>usecs_or_false -> sys_timer(ast_p)
>        This  procedure  and  its  updater  provide  multiple  real   or
>        `virtual'  interval  timers,  each  attached  to  a   particular
>        asynchronous trap procedure ast_p that  gets run when the  timer
>        expires.
>
>and then ...
>
>        usecs may  be  a  biginteger, the  largest  time  allowed  being
>        pop_max_int seconds plus 999999  microseconds (i.e. the  seconds
>        part of usecs must be within the range of a simple integer). The
>        smallest time allowed is 0, but assigning a non-zero time  value
>        smaller than the resolution of the system clock sets a timer for
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        that resolution (e.g. 1/100th second on VAXen and Sun-4 systems,
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        1/50th sec on MC68000  systems, etc). A  zero time value  causes
>        the timer to expire immediately.
>
>which is what seems to happen.  When I created timers with what I thought
>was microsecond resolution, I was surprised how fast my programs seemed to
>be running (based on the number of timer ticks).  When scaled four orders of
>magnitude, things made more sense.
>
>Is there any way to get better than 1/00th of a second resolution timing in
>Poplog?
>
>Thanks
>
>
>-- Brian
>
>  Brian Logan,  School of Computer Science & IT, University of Nottingham
> Email: bsl@cs.nott.ac.uk,  Phone: +44 115 846 6509, Fax: +44 115 951 4254
>
>
>  
>