windows 的时钟精度是多少？怎么提高

如题

这个问题呢 之前被问到过
我当时也是猜的认为可以到纳秒 ,比如sleep（1） 可以到微秒 通过特殊的手段到纳秒

还是太年轻,太相信windows 了 哈哈哈啊哈, 其实根本到不了这么高的精度

正常的一个sleep 的精度准确率在 10-15ms .

也就是说你想精准到 1毫秒 都办不到.

首先来了解下windows操作系统类型

操作系统分为 实时操作系统与非实时操作系统

常见的实时操作系统：

freeRTOS 嵌入式的一些系统

常见的非实时操作系统：

windows linux android

主要的区别是任务调度的处理方式不同, 实时操作系统一般都是 基于任务优先级的调度方式(一旦内核把资源分配给某个进程，直到该进程完成或发生某事件而被阻塞（常见的方式主动调用delay），才再把处理机分配给其他进程，否则高优先级的任务会一直运行。所以这种情况下，如果某个高优先级的任务运行时间过长最好有阻塞机制，来让出CPU使其他低优先级的任务也有机会运行。)

而非实时操作系统呢 是基于时间片的调度方式：这种方式下，所有任务的优先级相同，当内核给该进程分配的时间片结束后，内核会停止正在执行的这个进程，下一个时间片分配给其他进程执行，即便这个任务没有执行完也没有主动delay自己。

这里有人会问了 windows 也能设置线程和进程的优先级啊 ， 这里不展开描述 这个话题了（因为我也没有深入研究 ）.

看到这里 大家也基本能想到 为啥windows 的时钟精度不高了，那么怎么加高精度呢？

msdn 有一篇文章说了一下这个

https://docs.microsoft.com/en-us/archive/msdn-magazine/2004/march/implementing-a-high-resolution-time-provider-for-windows

通过 QueryPerformanceCounter 这个玩意 高精度计时器 精度可以到1~100微秒

21:23:22.296 
21:23:22.297 
21:23:22.297 
21:23:22.298 
21:23:22.298 
21:23:22.299 

那怎么到微秒和纳秒呢？

下面的我也是在网上看到了 我发一下 ,也就知道个概念就好了 没真正测试过

1. RDTSC - 粒度: 纳秒级 不推荐
   优势: 几乎是能够获得最细粒度的计数器
   抛弃理由:
   A) 定义模糊

• 曾经据说是处理器的cycle counter，但是后来似乎又不是了。
  有的机器上每秒的TSC增长值等于CPU频率，有的却是一个不对应任何配置的数。到底是什么，Intel也没解释清楚。
  B) 不准确
• 这是最重大的缺陷。再细的粒度，不准的话也没用，至少不能当时间用。
  在有的CPU上，特别是支持变频技术的笔记本CPU上，TSC增长值会随着CPU的频率改变。忙的时候跑得快，闲得时候跑得慢。

2. QueryPerformanceCounter - 粒度: 1~100微秒级 不推荐
   优势: 尽管比RDTSC粒度稍低，但是不存在RDTSC在变频CPU上的问题。
   知道这个API的人估计都倾向于用这个，因为M$对这个API给出了比较明确的定义，就是每秒钟某个计数器增长的数值。抛弃理由:还是不准确尽管没有源代码，但是从M$的帮助文档和知识库可以了解到，PerformanceCounter是依赖于主板上与PCI设备有关联的硬件。这就意味着，PerformanceCounter的结果还是会受到硬件频率，特别是总线频率的影响。
   事实上，我在EeePC上测试的时候就发现，系统采用节能模式的时候PerformanceCounter出来的结果老是偏慢很多，超频模式的时候又偏快，而且用电池和接电源的时候效果还不一样!
3. timeGetTime - 粒度: 毫秒级 推荐
   尽管粒度进一步降低，但是其无与伦比的优势就是，准确。
   在任何机器上返回的都是当前系统的启动时间，精确到1毫秒。
   使用注意事项:
   A) 在NT系统上(据说)默认精度为10ms，但是可以用timeBeginPeriod来降低到1ms
   B) 返回的是一个32位整数，所以要注意大约每49.71天会出现归零(不像前两个是64位数，要几百年才会归零)。

参考：https://zhidao.baidu.com/question/2141227584775324308.html