anh@relay.eu.net (Andrew Harker) (11/17/89)
I have a problem relating to SUN OS3.5 kernel device drivers. I want to measure the performance of the driver by calling a routine at certain points in the driver which records a timer value in a buffer somewhere. Outside the kernel, the obvious answer is to use gettimeofday(), but this is no good inside the device driver. Is there a way of accessing the SUN's timer register from within the kernel? Is there an easier way?
tep@suntan.west.sun.com (Tom Perrine x426) (12/03/89)
In sun-spots V8#207, Andrew Harker <tots!nosc!relay.eu.net!larch!anh writes: > I have a problem relating to SUN OS3.5 kernel device drivers. I want to > measure the performance of the driver by calling a routine at certain > points in the driver which records a timer value in a buffer somewhere. > Outside the kernel, the obvious answer is to use gettimeofday(), but this > is no good inside the device driver. > > Is there a way of accessing the SUN's timer register from within the > kernel? Is there an easier way? I needed to do almost the exact same thing last year. I was working on a driver and needed to do some performance measurement, from a user program written in Ada. The easiest way to do this was to write an ioctl in the driver that returned the data I wanted with a timestamp of when the data snapshot was taken. The easiest place to find a timestamp was go straight to the source so I read the clock chip. This works on a Sun 3/260 under SunOS 3.5 (and 3.5.2): #include "../sun3/clock.h" ... /* time stamp structure - derived from struct intersil7170 in clock.h * The important difference is that all fields are longword-aligned longwords. * This makes interfacing to Ada easier (via representation clauses) */ struct rts_timestamp { long tms_hsec; /* counter - hundredths of seconds 0-99 */ long tms_hour; /* counter - hours 0-23 (24hr) 1-12 (12hr) */ long tms_min; /* counter - minutes 0-59 */ long tms_sec; /* counter - seconds 0-59 */ long tms_mon; /* counter - month 1-12 */ long tms_day; /* counter - day 1-31 */ long tms_year; /* counter - year 0-99 */ long tms_weekday; /* counter - week day 0-6 */ }; ... /* set a pointer to the clock chip onboard registers */ struct intersil7170 *clock = CLKADDR; ... static get_timestamp(now) struct rts_timestamp *now; { /* EXAMINE AND UNDERSTAND everthing in clock.h before modifying this * procedure!! Especially the part about latching via clk_hsec! */ now->tms_hsec = (long)clock->clk_hsec; now->tms_hour = (long)clock->clk_hour; now->tms_min = (long)clock->clk_min; now->tms_sec = (long)clock->clk_sec; now->tms_mon = (long)clock->clk_mon; now->tms_day = (long)clock->clk_day; now->tms_year = (long)clock->clk_year; now->tms_weekday = (long)clock->clk_weekday; } ... The note about latching via clk_hsec refers to the fact that reading clk_hsec latches the time in all the other bytes so you get a consistent time. To see any changes in the other fields, you must read clk_hsec again. READ THE clock.h COMMENTS and make sure you understand what is going on or you may get inconsistent timestamps (or if you were to loop waiting for a fields to change, you could loop forever at elevated priority). Beware of comparing timestamps from this method to those returned by any other method, including gettimeofday(). You will be reading the clock chip registers, which are munged to produce the "system date"; there are offsets, corrections, adjustmants and other things going on. Let me know how this works out for you. Tom Perrine (tep) Logicon (Tactical and Training Systems Division) San Diego CA (619) 455-1330 Internet: tots!tep@LOGICON.ARPA GENIE: T.PERRINE UUCP:{nosc,ucsd}!snoopy!tots!tep -or- nosc!hamachi!tots!tep -or- sun!suntan!tots!tep
danzig@ucbarpa.berkeley.edu (12/08/89)
In article <3295@brazos.Rice.edu> you write: >X-Sun-Spots-Digest: Volume 8, Issue 207, message 12 of 16 > >I have a problem relating to SUN OS3.5 kernel device drivers. I want to >measure the performance of the driver by calling a routine at certain >points in the driver which records a timer value in a buffer somewhere. >Outside the kernel, the obvious answer is to use gettimeofday(), but this >is no good inside the device driver. > >Is there a way of accessing the SUN's timer register from within the >kernel? Is there an easier way? Here at UCB we built a microsecond resolution timer that plugs into the DES chip of 3/50,3/60,3/160,3/260,4/110,4/260 class systems. You'll have a hard time using Sun's 20 (or 10) millisecond clock to instrument device driver code. Contact me for the schematic or to buy a finished timer and device driver. Peter Danzig danzig@ucbarpa.berkeley.edu
smb@research.att.com (12/21/89)
There are easier things to do than reading the clock chip. For one thing, there's an external struct timeval named 'time'; it's the variable the gettimeofday() system call uses to return the current time. (As such, of course, it's limited to the precision of that call.) Actually, that's not quite true; there's a subroutine uniqtime() that takes a struct timeval* as a parameter; it returns that structure, but will increment the low-order bit (i.e., the microsecond value) to ensure that no two calls yield the exact same time.