#9277 closed bug (duplicate)
Date/Time Skew Depending on CPU Frequency Stepping Policy
Reported by: | br3wski3 | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | - General | Version: | R1/alpha4.1 |
Keywords: | cpu frequency date time skew CPUFrequency | Cc: | |
Blocked By: | #1993 | Blocking: | |
Platform: | All |
Description
Hi,
I noticed that the date clock time has been falling behind with respect to the real time. I have tracked this down to a dependence on the CPU frequency. When I have the stepping policy with CPUFrequency set to Dynamic performance or Low energy or explicitly set the state to a lower than maximum frequency, the system clock time falls behind. When I have the policy set to High performance or the max frequency, the system time seems to keep up.
Here is an example of setting the time and checking the time skew at various points with the policy set to Low energy which demonstrates the severe skew. The time is retrieved/parsed from time.gov in the first call and then compared subsequently a handful of times. I should also note that the CPU max frequency is 1.6 GHz while the Low energy state puts it at 600 MHz.
~> date -s `curl 'http://www.time.gov/timezone.cgi?Eastern/d/-5' | grep -v 'meta http-equi' | grep '..:..:..' | sed -e 's/.*<b>//' -e 's/<.*//'` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4869 0 4869 0 0 35003 0 --:--:-- --:--:-- --:--:-- 40915 Sun Dec 9 17:00:05 GMT 2012 ~> curl 'http://www.time.gov/timezone.cgi?Eastern/d/-5' | grep -v 'meta http-equi' | grep '..:..:..' | sed -e 's/.*<b>//' -e 's/<.*//'; date % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4869 0 4869 0 0 11902 0 --:--:-- --:--:-- --:--:-- 12613 17:00:07 Sun Dec 9 17:00:06 GMT 2012 ~> curl 'http://www.time.gov/timezone.cgi?Eastern/d/-5' | grep -v 'meta http-equi' | grep '..:..:..' | sed -e 's/.*<b>//' -e 's/<.*//'; date % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4869 0 4869 0 0 16115 0 --:--:-- --:--:-- --:--:-- 18100 17:00:27 Sun Dec 9 17:00:13 GMT 2012 ~> curl 'http://www.time.gov/timezone.cgi?Eastern/d/-5' | grep -v 'meta http-equi' | grep '..:..:..' | sed -e 's/.*<b>//' -e 's/<.*//'; date % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4869 0 4869 0 0 31541 0 --:--:-- --:--:-- --:--:-- 47735 17:41:59 Sun Dec 9 17:22:49 GMT 2012 ~> curl 'http://www.time.gov/timezone.cgi?Eastern/d/-5' | grep -v 'meta http-equi' | grep '..:..:..' | sed -e 's/.*<b>//' -e 's/<.*//'; date % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4869 0 4869 0 0 52009 0 --:--:-- --:--:-- --:--:-- 64920 17:55:03 Sun Dec 9 17:27:54 GMT 2012
As can be seen, the deviation increases steadily over the course of about fifty-five minutes.
Now, a similar example sequence but with the Stepping policy in CPUFrequency set to High performance.
~> date -s `curl 'http://www.time.gov/timezone.cgi?Eastern/d/-5' | grep -v 'meta http-equi' | grep '..:..:..' | sed -e 's/.*<b>//' -e 's/<.*//'` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4869 0 4869 0 0 18269 0 --:--:-- --:--:-- --:--:-- 30242 Sun Dec 9 18:05:26 GMT 2012 ~> curl 'http://www.time.gov/timezone.cgi?Eastern/d/-5' | grep -v 'meta http-equi' | grep '..:..:..' | sed -e 's/.*<b>//' -e 's/<.*//'; date; % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4869 0 4869 0 0 29417 0 --:--:-- --:--:-- --:--:-- 34531 18:05:33 Sun Dec 9 18:05:32 GMT 2012 ~> curl 'http://www.time.gov/timezone.cgi?Eastern/d/-5' | grep -v 'meta http-equi' | grep '..:..:..' | sed -e 's/.*<b>//' -e 's/<.*//'; date; % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4869 0 4869 0 0 19713 0 --:--:-- --:--:-- --:--:-- 32245 18:26:30 Sun Dec 9 18:26:29 GMT 2012
As can be seen, over the course of more than twenty minutes, the system/clock time remains in-line with time.gov.
I could not find any other ticket reporting this. Also, I do not know if there is something specific about my system causing this but I'd be happy to dig up any additional information that may be needed. The laptop running Haiku R1 Alpha 4.1 from HD is a Dell Inspiron 600m.
Thanks! Brendan
Change History (2)
comment:1 by , 12 years ago
Blocked By: | 1993 added |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
comment:2 by , 12 years ago
Ok, thanks. I never would've been able to realize that ticket #1993 encapsulated this issue until now that I've read it!
Thanks, Brendan
Duplicate of #1993.