> > The closest you will find is hw.cpu_mhz, via sysctl.
> Not on my 4.2-STABLE, late February vintage. I could parse
> hw.model, but that reports 533MHz, while dmesg reports 531MHz.
> In a followup, Mike mentioned fluctuations of clock frequency. Any
> idea, by how much this fluctuation can be? percentage of MHz, kHz?
> In general, I am not too fussed about these fluctuations, as I can
> take some fine grained samples using cycle counters together with more
> coarse grained once obtained from gettimeofday().
> However, to get an estimate for cycles per second, I was looking for a
> programmatic way to access above mentioned variables instead of
> providing them as command line arguments. I'll just add an appropriate
> sysctl to get cycles_per_sec. If people are interested, I'll submit a
It's unlikely that you will be able to do what you want the
way you want to do it.
In particular, it's possible for your program to be context
switched in the middle of your calculation, or for the system
to take interrupts, etc., wihch will result in serious skew
of your numbers.
When I did this task, I cheated tremendously.
Minimally, you will require periodic resynchornization with
the kernel drift information stored in timer structure. You
should see /sys/i386/isa/clock.c and the timer code in the
Tracking through this code is actually pretty miserable, since
it uses the aforementioned structure as a template, so there's
no global place you can go to retrieve the syncronization data
in the kernel, since it's hidden on the other side of a pointer.
I wish this code were better documented as to its intended
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message