26 Reply by sarami 2025-03-11 17:52:59

  • Registered: 2011-02-20
  • Posts: 1,770

reentrant wrote:

ULONGLONG performanceFrequency = 0;
ULONGLONG performanceCounter = KeQueryPerformanceCounter(&performanceFrequency);
ULONGLONG ticksMicroSeconds = 1000000 * performanceCounter / performanceFrequency;

I implemented the following in a test version(http://forum.redump.org/post/78821/#p78821).

    LARGE_INTEGER freq = {}, current = {}, end = {};
    QueryPerformanceFrequency(&freq);
    double time = 0;

    QueryPerformanceCounter(&current);
    (Read the CD multiple times)
    QueryPerformanceCounter(&end);
    time = static_cast<double>(end.QuadPart - current.QuadPart) * 1000 / static_cast<double>(freq.QuadPart);
DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

27 Reply by Nemok 2025-03-15 04:16:30

  • Registered: 2023-03-03
  • Posts: 122

Wish I could help you, but for now that's beyond my understanding.

All I know is that BWA builder had an alleged precision of about 6 µs.

28 Reply by Nemok 2025-04-04 15:06:19

  • Registered: 2023-03-03
  • Posts: 122

I did a bit of testing with different time stamp functions. It seems that after simply iterating a printf in a for loop, clock(), QueryPerformanceCounter() in Windows, and clock_gettime() in Linux give extremely close results when CLOCK_PROCESS_CPUTIME_ID is used.

If that behavior is consistent in any situation, which needs to be checked, I find it even harder to understand how one would achieve the task of measuring DPM with these functions, unless the I/O latency is deduced, because they try to assess the same thing, that is the CPU time spent on a process, while the time NOT spent by the CPU is required for DPM (as I see it).

I wonder if calculating the difference between clock_gettime(CLOCK_MONOTONIC) and clock_gettime(CLOCK_PROCESS_CPUTIME_ID) is enough to approximate the drive's latency variations.