OSDev.org

I think the problem with that is, this is something you can't really do once a full multitasking OS is up and running, with its full complement of interrupt handlers etc. You can't guarentee, for example, that the time between two RTC interrupts is constant unless it's the only interrupt handler currently not masked. You can do this easily at boot time, but once you get the point where you can interact with the user, you've lost the ability to get accurate reads, and can't regain it without essentially putting the whole OS on hold. Not necessarily a good idea. OTOH, this is a really easy check to make at boot...

bkilgore:

Curufir wrote: ...

with a boot option to redetect (For large configuration changes, eg dumping the hardrive in a different computer)

...

That would include changing processor, since that IS a large configuration change.

Dreamsmith:

I was thinking more along the lines of picking up the time from CMOS (Hence the 1 second resolution, and the need to have an extended period between rtdsc's). That clock shouldn't (I haven't looked into it too deeply, so maybe I'm wrong) be affected by system interrupts. It's not going to result in a hugely accurate measure of frequency, but IMO an accuracte reading is not actually required. An error of +/- 10Mhz is perfectly acceptable given that clock frequencies are mostly in 33Mhz steps.

Curufir wrote:That clock shouldn't (I haven't looked into it too deeply, so maybe I'm wrong) be affected by system interrupts.

No, but the code attempting to read it will be. You see the clock tick once, you see it again. Without careful control of interrupts, you cannot know anything about the time interval between other than 1.0 <= t < 3.0. Granted, it's much more likely to be 1.001 than 2.999, but both are possible. I prefer things to be a little more deterministic. Since this can be easily achieved at bootup, why not?

True, but my argument would be that the code being executed between the two readings doesn't actually matter.

The rdtsc counter ticks at a constant rate no matter what is happening (Aside from clock speed alterations due to power saving, but I'll ignore that for the time being). So if I take one rdtsc reading at T[sub]0[/sub] and another at T[sub]1[/sub] then so long as I disable interrupts for the short period the readings actually take place I'll come up with a reasonable result so long as T[sub]1[/sub] - T[sub]0[/sub] is suitably large.

IE What I'm suggesting is that since installation is going to take a while anyway it can be used to provide a large enough difference in CMOS time to get half-decent accuracy, which can be improved by rounding up/down to the nearest existing clock frequency.

In my example I suggested installation might take 5 minutes.

With a 1 second resolution on the clock, the max error for T[sub]1[/sub] - T[sub]0[/sub] is going to be +/- 2 seconds.

Error calculation has never been a particular strong suit of mine, but if I take an example of a 500Mhz processor over a 5 minute installation we get something like:

Delta(rdtsc) = (500,000,000 * 300) -> Assume negligible error
Delta(CMOS time) = 300 +/- 2

Delta(rdtsc)/Delta(CMOS time) = Frequency

Roll the dice and we get a freqency of 500Mhz +/- 4Mhz which is well within the error limit I defined.

In fact it would hold within my desired errors even beyond 2Ghz, at which point I'd be rounding to the nearest 100Mhz anyway.

I'd agree that this is a pretty crude way of getting the clock frequency, but since the opportunity is there at installation time, and people don't change processor very often, I just don't see why it should be done at boot time.

Nobody, IMHO, changes hardware so often that they require constant boot-time detection. I'm quite confident that I can get away with a policy of one-time detection, whilst relying on the user/administrator to perform redection as required.

What do you intend to use the CPU speed for once you've found it out? The only use I can see is that you could adjust the frequency of scheduling so that the same amount of work gets done in each time slice no matter what the CPU, but does that really matter?

Pete

Pete wrote:What do you intend to use the CPU speed for once you've found it out?

Um...

Oh come on! It's cool! Do we need any more reason than that? ;D

Pete wrote:What do you intend to use the CPU speed for once you've found it out?

Well let's say (As an example) my OS allows for a certain amount of process informed scheduling.

In my mythical scheduler a task can ask to be run uninterrupted for a minimum of X cyles at a specified time. (Let's leave aside for a sec how it finds out how many cycles it needs )

If I know the clock frequency my scheduler can work out how long it needs for X cycles (Adding a bit more as an error margin) and can schedule approximately that amount of contiguous processor time.

This would allow for a much tighter scheduling of critical processes whilst maintaining the obligations the OS has to them, simply because the scheduler can have prior knowledge of how long they need to run.

Eg The process in question might be my audio server, which has to receive a certain number of cycles every so often to keep the sound card supplied with data. If that schedule isn't kept then sound starts skipping.

***

Well that stretches my imagination, and you could do the same thing more elegantly by allowing cooperative scheduling in trusted processes.

Then again my original answer was "It looks pretty" ;D.