RDTSC 读取不准确这个应该算是CPU的BUG,由TSC的计数方式,多核等影响。多核TSC的问题目前MS和AMD 通过软件补丁的方式来解决了。而SpeedStep以及CPU频率变化的影响Intel已经对TSC进行修正了。
RDTSC 毕竟是比较快速的读取方法,使用ACPI PM Timer 需要保护模式切换也会变成一个问题。
TSC 的计数方式。
(I)variant TSC 该方式下TSC是由CPU的频率决定,每个CPU Clock TSC 加1 Pentium M处理器 (family [06H], models [09H, 0DH]); Pentium 4以及志强处理器中(family [0FH], models [00H, 01H, or 02H]);和P6家族的处理器,TSC增加的频率都是会随着处理器的时钟变化而变化的
(II)Invariant TSC Pentium 4和志强处理器(family [0FH], models [03H and higher]); Core Solo and Core Duo处理器 (family [06H], model[0EH]); 志强处理器5100系列和Core 2 Duo处理器(family [06H], model [0FH]),TSC都不会随着SpeedStep的频率变化而变化
计算机(包括pc server和很多嵌入系统)一般都有一个rtc(real time clock) 可以读出比较精确的时间 一年也就差1两秒那种 但是那一般是一个外设 通过比较慢的总线访问 比如我搞的一个嵌入系统 rtc通过i2c总线访问 平均要1ms才能读一次数据 pc的我没具体测试过 但是在linux下输入hwclock就知道了 延时是人能感觉到的 所以系统日常记时一般是用中断源 OS都有定时的中断 每次中断都把内存里的系统时钟值做累加(也有的cpu有专门记时的寄存器 每若干时钟周期自动加一) 这种时钟的特点就是精度做短期记时还行 万分之几的样子 长时间积累就很够呛了 基本上rtc就是在开机的时候读一下 同步到系统时钟(linux下就是用hwclock --hctosys)在一个一般的分时OS里 即使没有smp 想达到精确到ms的记时也是很困难的 rtc读取的时间延迟就很难控制 而且就算这个问题能解决得很完美 system call返回到进程被唤醒之间的时间 是由调度器决定的 在一个非实时OS里 这个时间是非常不确定的 如果这个系统里有多个线程而且都比较忙 或者正好发生了别的硬件中断 就可能产生一个远远长于1ms的延迟 所以就算时钟很精确 系统调用的结果也是不可依赖的 除非用dos 或者vxworks :-)
恩,这问题做MMO 基于物理仿真REALTIME同步时候就更厉害,能挣死人.
最后是的答案是这样: 想依靠timeGetTime, GetTickCount,GetPerformanceCount,rtsc 得到准确时钟方法是不存在的.
因为超线程CPU受负荷影响,多核,BIOS BUG等一系列因素.导致没有正常途径可以得到全世界PC都相同的时钟.某些情况下(HT),GetPerformanceCount错得更厉害.
不少论坛有讨论.
得到所有PC都准确得毫秒级别时钟是可能的. 但是驱动级的编程.NT CORE下 非administrator动态加载核心驱动也是不可能的.
所以,只能靠一系列补偿算法和一个能得到比较准确时钟的SERVER.