Windows Scheduler Latency after WinAPI "Sleep"-Command or Timers - Programmer

This is a discussion on Windows Scheduler Latency after WinAPI "Sleep"-Command or Timers - Programmer ; Dear all, I have detected a very strange behaviour of the Windows scheduler concerning its latency. This can be illustrated by the code segment at the end of this mail. The code should simply read the system time in milliseconds ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Windows Scheduler Latency after WinAPI "Sleep"-Command or Timers

  1. Windows Scheduler Latency after WinAPI "Sleep"-Command or Timers

    Dear all,

    I have detected a very strange behaviour of the Windows scheduler concerning
    its latency. This can be illustrated by the code segment at the end of this
    mail.

    The code should simply read the system time in milliseconds (using WinAPI's
    GetTickCount) then sleep for a specified number of milliseconds and repeat
    this loop for a given number of cycles. In the end, it presents the mean
    value of the time needed per loop - which should be more or less the time
    specified with the Sleep() command as the rest of the commands should take
    much time.

    On various PCs with different configurations (Intel and Athlon, different
    boards, but all on WinXP) we find that the code is running as expected. When
    setting SleepTime to 1 ms, 10 ms, and 100 ms, we receive messages that tell
    us that the cycle time was 1 ms, 10 ms, and 100 ms, respectively. On other
    PCs (also with XP), however, we get the following cycle times:

    SleepTime = 1 ms --> CycleTime = 15 ms
    SleepTime = 10 ms --> CycleTime = 15 ms
    SleepTime = 100 ms --> CycleTime = 109 ms

    The strange thing is, that on all PCs that were tested with this straneg
    behaviour, the resulting times are exactly the same. Moreover, we found that
    some PCs showed the wrong times but were ok after a they were rebooted.

    For your own tests, you can compile the code below as a plain WinAPI or
    console programme. In our case, Visual C++ 6.0 and Visual .net (2003)
    produced the same results. BTW: Results were equal when using timers instead
    of Sleep

    Could anyone give me some information on what's going wrong here?

    Regards,

    John

    ------------------------------

    #include
    #include

    const int SleepTime = 100;

    int main(){
    int NewTime;
    int OldTime;
    int CycleTime = 0;
    int Cycles = 100;
    int i;
    int SleepTime = 1;
    char TextBuffer[256];

    OldTime = GetTickCount();
    Sleep(SleepTime);
    for(i = 0; i < Cycles; i++){
    NewTime = GetTickCount();
    CycleTime += (NewTime-OldTime);
    OldTime = NewTime;
    Sleep(SleepTime);
    }
    sprintf(TextBuffer, "CycleTime: %d\n", CycleTime/Cycles);
    MessageBox(NULL, TextBuffer, "TickTest", MB_OK);
    return 0;
    }



  2. Re: Windows Scheduler Latency after WinAPI "Sleep"-Command or Timers

    In comp.os.ms-windows.programmer.misc John Lafrowda wrote:
    : On other
    : PCs (also with XP), however, we get the following cycle times:
    :
    : SleepTime = 1 ms --> CycleTime = 15 ms
    : SleepTime = 10 ms --> CycleTime = 15 ms
    : SleepTime = 100 ms --> CycleTime = 109 ms
    :
    : Could anyone give me some information on what's going wrong here?

    Aren't you simply seeing the effect of the underlying hardware
    tick rate? That varies between different PCs, is often 100 Hz
    but can be significantly lower. When you request a Sleep the
    time will be rounded up to the next integer number of ticks.
    So if the hardware tick rate was 64 Hz a Sleep(1) and Sleep(10)
    would both sleep for 1 tick period (15.6 ms) and a Sleep(100)
    would sleep for 7 tick periods (109.4 ms).

    You may find it instructive to monitor the values returned from
    GetTickCount. You will typically find that, although increasing
    monotonically at an average rate of 1000 counts per second, many
    values are missing.

    Richard.
    http://www.rtrussell.co.uk/
    To reply by email change 'news' to my forename.

  3. Re: Windows Scheduler Latency after WinAPI "Sleep"-Command or Timers

    Dear Richard,

    your figues are correct and I see that I am running on a clock rate of
    15.625 ms really.
    Inspired by Pavel, however, I wonder why I cannot change this rate using the
    NtSetTimerResolution command (see
    http://www.sysinternals.com/Informat...ionTimers.html) as this
    should allow me to change timer resolution in between 15.625 and 1.000 ms.
    Any comments are welcome.

    Regards,

    John

    schrieb im Newsbeitrag
    news:dsvdma$a47$2@nntp0.reith.bbc.co.uk...
    > In comp.os.ms-windows.programmer.misc John Lafrowda
    > wrote:
    > : On other
    > : PCs (also with XP), however, we get the following cycle times:
    > :
    > : SleepTime = 1 ms --> CycleTime = 15 ms
    > : SleepTime = 10 ms --> CycleTime = 15 ms
    > : SleepTime = 100 ms --> CycleTime = 109 ms
    > :
    > : Could anyone give me some information on what's going wrong here?
    >
    > Aren't you simply seeing the effect of the underlying hardware
    > tick rate? That varies between different PCs, is often 100 Hz
    > but can be significantly lower. When you request a Sleep the
    > time will be rounded up to the next integer number of ticks.
    > So if the hardware tick rate was 64 Hz a Sleep(1) and Sleep(10)
    > would both sleep for 1 tick period (15.6 ms) and a Sleep(100)
    > would sleep for 7 tick periods (109.4 ms).
    >
    > You may find it instructive to monitor the values returned from
    > GetTickCount. You will typically find that, although increasing
    > monotonically at an average rate of 1000 counts per second, many
    > values are missing.
    >
    > Richard.
    > http://www.rtrussell.co.uk/
    > To reply by email change 'news' to my forename.




+ Reply to Thread