2260
社区成员
1.7w+
社区内容
- 主页
winxp上在运行某些程序时系统时钟变快
cxiaobao 2009-10-07 05:15:54 我有一组程序，在运行的时候，有些机器的系统时钟（time-of-day）明显变快，大概每20分钟到1小时差不多快1秒（我使用直接读cmos端口的方式，取得CMOS中的时钟，与系统当前的时间比较）。情况与下面三个连接说的情况非常相似。
http://blog.csdn.net/liuzhengkang/archive/2009/09/07/4528232.aspx
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500388
http://support.microsoft.com/kb/821893/en-us/
但上面连接不同的是，我的程序是用vc6写的，通过监视SSDT，也没有发现频繁的NtSetTimerReslution调用。但我的程序的确出现了相似的情况，各位可知道除了上面列的情况，还有其它的方式引起这个状况？
http://blog.csdn.net/liuzhengkang/archive/2009/09/07/4528232.aspx
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500388
http://support.microsoft.com/kb/821893/en-us/
但上面连接不同的是，我的程序是用vc6写的，通过监视SSDT，也没有发现频繁的NtSetTimerReslution调用。但我的程序的确出现了相似的情况，各位可知道除了上面列的情况，还有其它的方式引起这个状况？
...全文
xwsn007 2009年10月11日
牛，顶！
cxiaobao 2009年10月07日
[Quote=引用 8 楼 lfchen 的回复:]
1. 我监视了SSDT中NtSetTimerReslustion，事实上没有发现有程序来调用这个服务（timeBeginPeriod是去调用这个的）
//看解决方案中，似乎是要求你去调用timeBeginPeriod，以便HAL去校时。
非也，在解决方案中，他说可能是timeBeginPeriod引起了这个问题，建议使用QueryPerformenceCounter来代替，但我搜查了我的代码，并未发现该调用。
2. 我读取CMOS时钟只是用于和系统时钟进行比较，事实上，上述情况只影响系统时钟，而cmos时钟还是准确的。
//CMOS中时间是有硬件中断直接控制的。你调用了CMOS的时间中断，是否导致系统HAL漏了一些时间中断？
不是由于我读cmos时钟引起该问题，而是在出现了该我问题后，我使用这种方法来与系统时钟对比进行调试。
[/Quote]
att
1. 我监视了SSDT中NtSetTimerReslustion，事实上没有发现有程序来调用这个服务（timeBeginPeriod是去调用这个的）
//看解决方案中，似乎是要求你去调用timeBeginPeriod，以便HAL去校时。
非也，在解决方案中，他说可能是timeBeginPeriod引起了这个问题，建议使用QueryPerformenceCounter来代替，但我搜查了我的代码，并未发现该调用。
2. 我读取CMOS时钟只是用于和系统时钟进行比较，事实上，上述情况只影响系统时钟，而cmos时钟还是准确的。
//CMOS中时间是有硬件中断直接控制的。你调用了CMOS的时间中断，是否导致系统HAL漏了一些时间中断？
不是由于我读cmos时钟引起该问题，而是在出现了该我问题后，我使用这种方法来与系统时钟对比进行调试。
[/Quote]
att
supconsupcon 2009年10月07日
顶
一条晚起的虫 2009年10月07日
1. 我监视了SSDT中NtSetTimerReslustion，事实上没有发现有程序来调用这个服务（timeBeginPeriod是去调用这个的）
//看解决方案中，似乎是要求你去调用timeBeginPeriod，以便HAL去校时。
2. 我读取CMOS时钟只是用于和系统时钟进行比较，事实上，上述情况只影响系统时钟，而cmos时钟还是准确的。
//CMOS中时间是有硬件中断直接控制的。你调用了CMOS的时间中断，是否导致系统HAL漏了一些时间中断？
//看解决方案中，似乎是要求你去调用timeBeginPeriod，以便HAL去校时。
2. 我读取CMOS时钟只是用于和系统时钟进行比较，事实上，上述情况只影响系统时钟，而cmos时钟还是准确的。
//CMOS中时间是有硬件中断直接控制的。你调用了CMOS的时间中断，是否导致系统HAL漏了一些时间中断？
cxiaobao 2009年10月07日
[Quote=引用 6 楼 supconsupcon 的回复:]
学习...
之前我在一个项目中遇到过客户端时间跳变的问题，最后查到原因是：
QueryPerFormanceCounter()这个函数调用问题，我当时电脑是多核的，
用两次这个函数调用的结果之差来计算时间再和时间服务器进行同步，
但是QueryPerFormanceCounter()这个函数在多核情况下两次调用取的
不一定是同一个CPU的晶振振动次数（两个CPU晶振的次数由可能是不同的），
导致时间差计算错误，导致时间错掉了，也是只有部分电脑会出现（都是DELL的），
解决的办法是：调用的QueryPerFormanceCounter()的线程绑定到一个固定的CPU上，
结果就再没出现过时间跳变的问题了，不知能否给你点提示。
[/Quote]
这个问题我是知道的，但单纯的调用QueryPerFormanceCounter并不引起时钟跳变，你可能是依赖这个值去计算时间然后去设置了系统时钟。但在我的程序里从来没有主动去设置过系统时钟。
学习...
之前我在一个项目中遇到过客户端时间跳变的问题，最后查到原因是：
QueryPerFormanceCounter()这个函数调用问题，我当时电脑是多核的，
用两次这个函数调用的结果之差来计算时间再和时间服务器进行同步，
但是QueryPerFormanceCounter()这个函数在多核情况下两次调用取的
不一定是同一个CPU的晶振振动次数（两个CPU晶振的次数由可能是不同的），
导致时间差计算错误，导致时间错掉了，也是只有部分电脑会出现（都是DELL的），
解决的办法是：调用的QueryPerFormanceCounter()的线程绑定到一个固定的CPU上，
结果就再没出现过时间跳变的问题了，不知能否给你点提示。
[/Quote]
这个问题我是知道的，但单纯的调用QueryPerFormanceCounter并不引起时钟跳变，你可能是依赖这个值去计算时间然后去设置了系统时钟。但在我的程序里从来没有主动去设置过系统时钟。
supconsupcon 2009年10月07日
学习...
之前我在一个项目中遇到过客户端时间跳变的问题，最后查到原因是：
QueryPerFormanceCounter()这个函数调用问题，我当时电脑是多核的，
用两次这个函数调用的结果之差来计算时间再和时间服务器进行同步，
但是QueryPerFormanceCounter()这个函数在多核情况下两次调用取的
不一定是同一个CPU的晶振振动次数（两个CPU晶振的次数由可能是不同的），
导致时间差计算错误，导致时间错掉了，也是只有部分电脑会出现（都是DELL的），
解决的办法是：调用的QueryPerFormanceCounter()的线程绑定到一个固定的CPU上，
结果就再没出现过时间跳变的问题了，不知能否给你点提示。
之前我在一个项目中遇到过客户端时间跳变的问题，最后查到原因是：
QueryPerFormanceCounter()这个函数调用问题，我当时电脑是多核的，
用两次这个函数调用的结果之差来计算时间再和时间服务器进行同步，
但是QueryPerFormanceCounter()这个函数在多核情况下两次调用取的
不一定是同一个CPU的晶振振动次数（两个CPU晶振的次数由可能是不同的），
导致时间差计算错误，导致时间错掉了，也是只有部分电脑会出现（都是DELL的），
解决的办法是：调用的QueryPerFormanceCounter()的线程绑定到一个固定的CPU上，
结果就再没出现过时间跳变的问题了，不知能否给你点提示。
cxiaobao 2009年10月07日
[Quote=引用 4 楼 lfchen 的回复:]
//和第三个链接的提到的情况类似，软件调用(改变)了时间中断，导致HAL遗漏了几个时间中断
//按照它给出的解决方法试试。
//
1、Modify the program to call the timeBeginPeriod function at startup and to call the timeEndPeriod function on exit. This workaround eliminates repeated time increment changes.
或者
2、Modify the program to use the QueryPerformanceCounter() API
//建议第二个。不知道你将CMOS时间与系统时间比较是为什么？
[/Quote]
1. 我监视了SSDT中NtSetTimerReslustion，事实上没有发现有程序来调用这个服务（timeBeginPeriod是去调用这个的）
2. 我读取CMOS时钟只是用于和系统时钟进行比较，事实上，上述情况只影响系统时钟，而cmos时钟还是准确的。
//和第三个链接的提到的情况类似，软件调用(改变)了时间中断，导致HAL遗漏了几个时间中断
//按照它给出的解决方法试试。
//
1、Modify the program to call the timeBeginPeriod function at startup and to call the timeEndPeriod function on exit. This workaround eliminates repeated time increment changes.
或者
2、Modify the program to use the QueryPerformanceCounter() API
//建议第二个。不知道你将CMOS时间与系统时间比较是为什么？
[/Quote]
1. 我监视了SSDT中NtSetTimerReslustion，事实上没有发现有程序来调用这个服务（timeBeginPeriod是去调用这个的）
2. 我读取CMOS时钟只是用于和系统时钟进行比较，事实上，上述情况只影响系统时钟，而cmos时钟还是准确的。
一条晚起的虫 2009年10月07日
//和第三个链接的提到的情况类似，软件调用(改变)了时间中断，导致HAL遗漏了几个时间中断
//按照它给出的解决方法试试。
//
1、Modify the program to call the timeBeginPeriod function at startup and to call the timeEndPeriod function on exit. This workaround eliminates repeated time increment changes.
或者
2、Modify the program to use the QueryPerformanceCounter() API
//建议第二个。不知道你将CMOS时间与系统时间比较是为什么？
//按照它给出的解决方法试试。
//
1、Modify the program to call the timeBeginPeriod function at startup and to call the timeEndPeriod function on exit. This workaround eliminates repeated time increment changes.
或者
2、Modify the program to use the QueryPerformanceCounter() API
//建议第二个。不知道你将CMOS时间与系统时间比较是为什么？
cxiaobao 2009年10月07日
[Quote=引用 1 楼 jennyvenus 的回复:]
“有的机器”，不知道这些机器有共性吗？俺知道有一种机器品牌是昂达，对usb的兼容性不好。
[/Quote]
是的，看起来并非所有的机器都这样，但其比例也不小。机器都是dell的。根据ms的说明，好象跟ACPI有关。实际上我在网上查到，一些linux系统也有同样的问题，以至于它们要在内核启动参数里加上noapci选项。
“有的机器”，不知道这些机器有共性吗？俺知道有一种机器品牌是昂达，对usb的兼容性不好。
[/Quote]
是的，看起来并非所有的机器都这样，但其比例也不小。机器都是dell的。根据ms的说明，好象跟ACPI有关。实际上我在网上查到，一些linux系统也有同样的问题，以至于它们要在内核启动参数里加上noapci选项。
cxiaobao 2009年10月07日
说明一下，我程序中用到了ACE，我对ACE不熟悉，不知道这个问题跟它有没有关系
智能卡_Snooper 2009年10月07日
“有的机器”，不知道这些机器有共性吗？俺知道有一种机器品牌是昂达，对usb的兼容性不好。