Jonathan de Boyne Pollard wrote:
> PW> Are you perhaps planning to display the CPU frequency as well?
>
> JdeBP> The CPUID instruction does not provide information about the
> JdeBP> CPU frequency. Determining the CPU frequency reliably is
> JdeBP> impossible in a Pure 32-Bit OS/2 application. One has to resort
> JdeBP> to 16-bit device drivers in order to do so. I'm not about to write
> JdeBP> a 16-bit device driver just for that.
>
> FB> freqcpu_r111.zip on Hobbes (with source) creates a dll and is
> FB> accurate as AFAIK.
>
> Then you don't know enough. It isn't accurate. I'll say it again: It
> is impossible to reliably determine the CPU frequency in a Pure 32-Bit
> OS/2 application. In order to do that, one *must* do things which can
> only be done by kernel-mode code.
>
> FB> APIs: DosPerfSysCall and DosTmrQueryTime.
>
> Didn't the word "estimate" in the function name "DosEstimateFreqCPU"
> give you a clue?
>
> In *no* multitasking protected mode operating system is the CPU
> frequency reliably determined by application code. In the operating
> systems where one has utilities that report the CPU frequency, what
> actually happens is that kernel-mode code measures the CPU frequency
> beforehand (usually as part of system initialization) and stores the
> value somewhere (the registry, the underlying storage for a /proc
> pseudo-file, or whatever). All that the applications that supposedly
> measure the CPU frequency actually do is simply read that value out.
>
> An application that does what DosEstimateFreqCPU() does is inherently
> unreliable, because the method is quite simply flawed, and will
> non-deterministically yield incorrect answers.

I don't want to beat this dead horse any longer but, as I pointed out,
this simply cannot be correct for OS/2 or Windows since the Windows app
CPU-Z running on either OS/2 with ODIN or Windows reliably provides the
CPU frequency in real time for Intel Speedstep systems where the CPU
frequency can be varied after startup. The ODIN libraries and the CPU-Z
app are both all 32-bit as far as I know and there is no way that a real
time indication of CPU frequency could be provided if the frequency were
only available when the system was initialized. Obviously these and
other similar apps have found some way to do that.


--
Posted with OS/2 Warp 4.52
and IBM Web Browser v2.0.3 

Jonathan de Boyne Pollard wrote:

> In *no* multitasking protected mode operating system is the CPU
> frequency reliably determined by application code. In the operating
> systems where one has utilities that report the CPU frequency, what
> actually happens is that kernel-mode code measures the CPU frequency
> beforehand (usually as part of system initialization) and stores the
> value somewhere (the registry, the underlying storage for a /proc
> pseudo-file, or whatever). All that the applications that supposedly
> measure the CPU frequency actually do is simply read that value out.
>
To quote someone else, "you don't know enough". Just because you
aren't familiar with methods that reliably measure CPU frequency from
pure Ring 3 code doesn't mean such methods don't exist.


Michal

JdeBP> In *no* multitasking protected mode operating system is the CPU
JdeBP> frequency reliably determined by application code. In the
JdeBP> operating systems where one has utilities that report the CPU
JdeBP> frequency, what actually happens is that kernel-mode code measures
JdeBP> the CPU frequency beforehand (usually as part of system
JdeBP> initialization) and stores the value somewhere (the registry, the
JdeBP> underlying storage for a /proc pseudo-file, or whatever). All that
JdeBP> the applications that supposedly measure the CPU frequency actually
JdeBP> do is simply read that value out.

MN> To quote someone else, "you don't know enough". Just because you
MN> aren't familiar with methods that reliably measure CPU frequency from
MN> pure Ring 3 code doesn't mean such methods don't exist.

Actually, I do know enough. I know how one measures CPU frequency in a
reliable manner, I know the restrictions that protected mode operating
systems put upon application code to prevent it from being able to take
over the system, and I know that they conflict. And I've said as much
for - oh - three messages in a row, now.

JdeBP> In *no* multitasking protected mode operating system is the CPU
JdeBP> frequency reliably determined by application code. In the
JdeBP> operating systems where one has utilities that report the CPU
JdeBP> frequency, what actually happens is that kernel-mode code measures
JdeBP> the CPU frequency beforehand (usually as part of system
JdeBP> initialization) and stores the value somewhere (the registry, the
JdeBP> underlying storage for a /proc pseudo-file, or whatever). All that
JdeBP> the applications that supposedly measure the CPU frequency actually
JdeBP> do is simply read that value out.
JdeBP>
JdeBP> An application that does what DosEstimateFreqCPU() does is
JdeBP> inherently unreliable, because the method is quite simply flawed,
JdeBP> and will non-deterministically yield incorrect answers.

DTJ> I don't want to beat this dead horse any longer but, as I pointed
DTJ> out, this simply cannot be correct for OS/2 or Windows

Nonetheless, it is.

DTJ> since the Windows app CPU-Z running on either OS/2 with ODIN
DJT> or Windows reliably provides the CPU frequency in real time for
DTJ> Intel Speedstep systems where the CPU frequency can be varied
DTJ> after startup.

.... when *you* run it (and aside from the very limited sample size there
are other problems with your experimental method, noted later). As I
said, the method generally employed by applications that claim to
reliably measure CPU frequency (and I point out again that the
DosEstimateFreqCPU() function is careful to have the word "estimate" in
there) is flawed, and will non-deterministically yield incorrect
answers. Franz Bakan, in this very thread, has already given an example
of DosEstimateFreqCPU() going wrong.

DTJ> there is no way that a real time indication of CPU frequency
DTJ> could be provided if the frequency were only available when the
DTJ> system was initialized.

The fact that the application is displaying a number that varies doesn't
mean that that number is *correct*.

DTJ> Obviously these and other similar apps have found some way to do that.

No, that's not obvious. But overlooking your testing methodology for
now, there are only two things that they could be doing instead of
reading some kernel-supplied data:

1. Reading the motherboard chipset hardware configuration space. This
is possible, although it hardly makes for a future-proof and universally
applicable program, since it has to be chock-full of chipset-specific
code that needs to be maintained as the hardware changes. The fact that
such a utility won't necessarily work on chipsets that the author hasn't
heard about or supported is another, different, aspect of being
unreliable, of course.

2. Using some new extension to the CPUID instruction for obtaining
processor frequency that wasn't there when last I checked the
AMD/Cyrix/Intel documentation on the subject. A quick Google search
yields no indication that there's been such an addition to CPUID.

The non-chipset-specific DosEstimateFreqCPU() method of determining CPU
frequency, of comparing a hardware clock against the CPU clock, can
*only* be performed reliably by kernel mode code.

Jonathan de Boyne Pollard wrote:

> Actually, I do know enough. I know how one measures CPU frequency in a
> reliable manner, I know the restrictions that protected mode operating
> systems put upon application code to prevent it from being able to take
> over the system, and I know that they conflict. And I've said as much
> for - oh - three messages in a row, now.
>
OK, have it your way. I'm just saying that I have code that can
reliably measure CPU speed from Ring 3, but you don't have to take
my word for it.


Michal

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek
], who wrote in article :
> OK, have it your way. I'm just saying that I have code that can
> reliably measure CPU speed from Ring 3, but you don't have to take
> my word for it.

OK, I bite. It is easy to test that you were not interrupted when you
ran some busy loop to pass time; but how to you test that you were not
interrupted *during* the call to fetch-time API?

Puzzled,
Ilya

Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was NOT [per weedlist] sent to
> Michal Necasek
> ], who wrote in article :
>
>> OK, have it your way. I'm just saying that I have code that can
>>reliably measure CPU speed from Ring 3, but you don't have to take
>>my word for it.
>
> OK, I bite. It is easy to test that you were not interrupted when you
> ran some busy loop to pass time; but how to you test that you were not
> interrupted *during* the call to fetch-time API?

I think Michal is cheating. He can get IOPL in Ring 3 and simply
disable interrupts.

Marty wrote:
>
> I think Michal is cheating. He can get IOPL in Ring 3 and simply
> disable interrupts.
>
We don't do that. You know where the code lives, take a look at it


Michal

Michal Necasek wrote:
> Marty wrote:
>
>>
>> I think Michal is cheating. He can get IOPL in Ring 3 and simply
>> disable interrupts.
>
> We don't do that. You know where the code lives, take a look at it

Ok. It looks like you boost up to TC +31, then loop while checking a
timestamp. You loop "long enough" to drive any inaccuracies to a
relatively low percentage. But how does this work if another TC +31
thread happens to execute? Or do TC +31 threads never get interrupted
until they willingly yield? Fuzzy on the details.

--
[Reverse the parts of the e-mail address to reply.]

[A complimentary Cc of this posting was sent to
Marty
], who wrote in article <8c6dncQ9BMh16XHcRVn-rw@comcast.com>:
> > We don't do that. You know where the code lives, take a look at it
>
> Ok. It looks like you boost up to TC +31, then loop while checking a
> timestamp.

But it is exactly the question: how to check a timestamp? MS counter?
Too low granularity. And any API call talking to hardware will yield
CPU to other TC +31 threads... And even if checking a timestamp: if
timestamp was updated, then interrupt happened, so time could have
been stolen from your thread.

But actually, you do not need to keep you thread running, so stolen
time is not an issue; if you have a reliable way to check a timestamp,
then you can sleep(), then check timestamp and the processor tick
counter. So if the error given by granularity of MS counter is
permissible, then indeed there *is* a way to be sure that the data you
got is legitimate. And while probabilic, the algorithm should
converge very soon.

However, if you want something more precise, then you need to
timestamp via an API call, and this call can make as long as several
ticks if there are competing threads...

Puzzled,
Ilya