【发布时间】：2018-08-27 19:01:55
【问题描述】：
我正在尝试通过拉取 QueryPerformanceCounter (QPC) 来测量串行协议握手的响应时间。我的目标系统是 Asrock D1800b Intel Dual Core 上的 win7，使用最新版本的 MinGw (6.3.0-1) 编译。
为了测试 QPC，我有这个代码：
#include <windows.h>
#include <stdio.h>
void main()
{
//performance timers
LARGE_INTEGER StartingTime, EndingTime, ElapsedMicroseconds;
LARGE_INTEGER Frequency;
QueryPerformanceFrequency(&Frequency);
for (int i = 0 ; i < 10 ; i++)
{
QueryPerformanceCounter(&StartingTime);
Sleep(10); //ms
QueryPerformanceCounter(&EndingTime);
ElapsedMicroseconds.QuadPart = EndingTime.QuadPart - StartingTime.QuadPart;
ElapsedMicroseconds.QuadPart *= 1000000; //first scale up counts
ElapsedMicroseconds.QuadPart /= Frequency.QuadPart; //then convert to us
printf("elapsed=%li\n", ElapsedMicroseconds.QuadPart);
}
}
在目标系统上运行时，我得到：（没有其他负载）
经过=5341
经过=14086
经过=13818
经过=14322
经过=15305
经过=8867
经过=12162
经过=14225
经过=13333
经过=14751
但是在开发系统（Win10，Intel i5）上运行时，我得到了非常一致的结果
经过=11326
经过=11556
经过=12630
经过=11583
经过=11749
经过=12644
经过=12562
经过=11690
经过=11726
经过=11664
以上两个结果都是更大运行的示例。
预期结果在 10000us 以上。
那么，对目标系统上发生的事情有什么想法吗？
【问题讨论】：
-
目标系统是否经历了一些恒定且相当大的负载变化？
-
尝试 50 毫秒。 10 ms 接近 sleep 方法的不可靠性极限。好吧，我想 sleep 在这里是为了举例吧？
-
旁白：注意关于
printf中格式类型说明符的编译器警告。 -
这里的底线是，Windows 不是一个实时操作系统，并且绝对没有作为一个实时操作系统的自负。特别是
Sleep()不能保证它会延迟执行多长时间。你会尽最大努力，但仅此而已。QueryPerformanceCounter()相当准确，但如果我可以打个比方，您在这里所做的类似于使用千分尺测量用斧头手工切割的原木的大小。 -
我知道 windows 不是 RTOS，但我认为最好的睡眠会导致更长的等待，而不是更短的等待。
标签： c performance time timer mingw