Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#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 bonefish, 12 years ago

Blocked By: 1993 added
Resolution: duplicate
Status: newclosed

Duplicate of #1993.

comment:2 by br3wski3, 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

Note: See TracTickets for help on using tickets.