Subject: Re: high-res timers
To: None <gdt@BBN.COM>
From: None <Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU>
List: port-alpha
Date: 12/29/1995 18:14:52
>   We're in the process of getting NetBSD/Alpha running on AXPpci33s.
> Being a time weenie, I'll be looking at cycle-counter based clocks.  I
> implemented high-resolution timers in user space under IRIX, and I'll
> take a look at your timer code as soon as time permits (probably
> within a month or two, but no promises).

cool.  It'll have probably changed a bit well before then, so you can
feel free to put it off for at least a few weeks...  8-)

> [ ... description of how you did it on IRIx ... ]

It seems that what I did was somewhat similar.  However, I don't allow
the time to be _set_ (written) via the mapped clock.

The kernel interface that i provided included the memory mapped clock
structure:

struct alpha_timedata {
        struct timeval  td_tv;  /* last time cc was sync'd. */
        u_long          td_cc;  /* cc as of last sync */
        u_long          td_cpc; /* cycles per second; convenience */
};

where the timeval is a copy of the system time, and td_cc is the value
of the cycle counter as of the last time that system time and the
cycle counter were considered "synchronized."  (it happens 64 times
per second, or something like that.)

The current value of the cycle counter is always readable from
user-land on the alpha.

I also provided some user-land functions to manipulate these values.
(They're what needs improvement, in my opinion...)

I plan to change the kernel interface, at least, to include a copy of
the kernel's "mono_time" (monotonically-increasing time) variable,
too, i think.


> In addition to calls to provide time, it would probably be good to
> provide calls to return a pointer to the counter, or return its value,
> and also to export a cycles/usec pair.

Right now, the only functions that i provide:
	(1) inits the memory-mapped clock (and returns a pointer to
	    it; calling it more than once is harmless).
	(2) gets a timestamp.  (it does more than it has to, to do
	    that, though.)

I plan to rework (2) so that it does less work, and to provide a
function to calculate the difference between two timestamps.


my goal is to have a facility with which i can:

	get get stamp (buffer N)
	get get stamp (buffer N + 1)
	get get stamp (buffer N + 2)
	get get stamp (buffer N + 3)

very quickly and with very low overhead, and which allows the to
do calculations on the timestamps outside of the gathering process.



chris