Windows Sleep Function Extremely Slow

Question

I am making a program using the Sleep command via Windows.h, and am experiencing a frustrating difference between running my program on Windows 10 instead of Windows 7. I simplified my program to the program below which exhibits the same behavior as my more complicated program.

On Windows 7 this 5000 count loop runs with the Sleep function at 1ms. This takes 5 seconds to complete.

On Windows 10 when I run the exact same program (exact same binary executable file), this program takes almost a minute to complete.

For my application this is completely unacceptable as I need to have the 1ms timing delay in order to interact with hardware I am using.

I also tried a suggestion from another post to use the select() command (via winsock2), but that command did not work to delay 1ms either. I have tried this program on multiple Windows 7 and Windows 10 PC's and the root cause of the issue always points to using Windows 10 instead of Windows 7. The program always runs within ~5 seconds on numerous Windows 7 PC's, and on the multiple Windows 10 PC's that I have tested the duration has been much longer ~60 seconds.

I have been using Microsoft Visual Studio Express 2010 (C/C++) as well as Microsoft Visual Studio Express 2017 (C/C++) to compile the programs. The version of visual studio does not influence the results.

I have also changed the compile options from 'Debug' to 'Release' and tried to optimize the compiler but this will not help either.

Any suggestions would be greatly appreciated.

#include <stdio.h>
#include <Windows.h>

#define LOOP_COUNT      5000

int main()
{
    int i = 0;

    for (i; i < LOOP_COUNT; i++){
        Sleep(1);
    }

    return 0;
}

Answer 1

I need to have the 1ms timing delay in order to interact with hardware I am using

Windows is the wrong tool for this job.

If you insist on using this wrong tool, you are going to have to make compromises (such as using a busy-wait and accepting the corresponding poor battery life).

You can make Sleep() more accurate using timeBeginPeriod(1) but depending on your hardware peripheral's limits on the "one millisecond" delay -- is that a minimum, maximum, or the middle of some range? -- it still will fail to meet your timing requirement with some non-zero probability.

The timeBeginPeriod function requests a minimum resolution for periodic timers.

The right solution for talking to hardware with tight timing tolerances is an embedded microcontroller which talks to the Windows PC through some very flexible interface such as UART or Ethernet, buffers data, and uses hardware timers to generate signals with very well-defined timing.

In some cases, you might be able to use embedded circuitry already existing within your Windows PC, such as "sound card" functionality.