Re: CPU ID & speed - OS2

This is a discussion on Re: CPU ID & speed - OS2 ; 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 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Re: CPU ID & speed

  1. Re: CPU ID & speed

    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.

  2. Re: CPU ID & speed

    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 


  3. Re: CPU ID & speed

    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


  4. Re: CPU ID & speed

    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.

  5. Re: CPU ID & speed

    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.

  6. Re: CPU ID & speed

    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


  7. Re: CPU ID & speed

    [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

  8. Re: CPU ID & speed

    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.

  9. Re: CPU ID & speed

    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


  10. Re: CPU ID & speed

    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.]


  11. Re: CPU ID & speed

    [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

+ Reply to Thread