Re: Clock Skew Due to CPU Frequency Management? (was Re: Dual-core system will not create NTP peers)

2008-02-25 Thread Lennart Sorensen
On Tue, Feb 19, 2008 at 07:37:32AM -0600, Moshe Yudkowsky wrote:
 I had a very kind private communication from a list member. Let me 
 reformulate my question.
 
 On the AMD64 dual-core platform, the system clock has far too much drift 
 even though the hardware clock seems well behaved. I don't seem to be 
 experiencing the double-speed clock problem that I see references to 
 on the net as of a few years ago, but I am experiencing some other odd 
 behavior. The most likely culprit, as far as I can tell from research, 
 is some interaction between the hardware's ability to adjust CPU clock 
 speed to save power/control temperature (which then influences the 
 system clock's theory of what a CPU tick means in terms of actual time 
 passing) with the dual-core mode.
 
 But that seems rather wacky. I find it hard to believe that a kernel 
 release  wouldn't work on dual core CPUs.
 
 But if the problem really is that's the case, I would like to know what 
 boot-time settings I can use to test this hypothesis. For that matter 
 I'd like to know why the kernel itself isn't picking up on this 
 theoretical problem -- ISTR reading about an enhanced CPU clock mode 
 that could solve this problem, but I can't find references to it or how 
 to build a kernel or modules from source that would include this capability.
 
 I've spent a substantial amount of time on this problem, and I can't 
 come to any conclusion. I have to wonder if it's a problem with NTP 
 itself, but if so it's a problem that only manifests itself on the AMD64 
 box, although I continue to fiddle with NTP settings.

Someone here at work was having trouble getting NTP working on their
system a few weeks ago.  Disabling spread spectrum in the BIOS solved
the problem.

Of course as far as I know disabling spread spectrum violate emmisions
certifications in europe, but I could be wrong about that since I don't
actually live there (anymore at least).

Spread spectrum clocking really screws with the timings NTP depends on.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Clock Skew Due to CPU Frequency Management? (was Re: Dual-core system will not create NTP peers)

2008-02-25 Thread Moshe Yudkowsky

Len,

Thanks for writing with the spread-spectrum idea.

I don't know if you saw the final email in this thread, but it turns out 
that (as far as I can tell) adjtimexconfig made a bad estimate when it 
was installed, and put a TICK value of 9750 in /etc/defaults/adjtimex, 
which of course works out to a clock that's always 2.5% slow.



--
Moshe Yudkowsky * [EMAIL PROTECTED] * www.pobox.com/~moshe
 Poor Mexico -- so far from G-d and so near the United States.
   -- President Porfirio Diaz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Clock Skew Due to CPU Frequency Management? (was Re: Dual-core system will not create NTP peers)

2008-02-19 Thread Moshe Yudkowsky
I had a very kind private communication from a list member. Let me 
reformulate my question.


On the AMD64 dual-core platform, the system clock has far too much drift 
even though the hardware clock seems well behaved. I don't seem to be 
experiencing the double-speed clock problem that I see references to 
on the net as of a few years ago, but I am experiencing some other odd 
behavior. The most likely culprit, as far as I can tell from research, 
is some interaction between the hardware's ability to adjust CPU clock 
speed to save power/control temperature (which then influences the 
system clock's theory of what a CPU tick means in terms of actual time 
passing) with the dual-core mode.


But that seems rather wacky. I find it hard to believe that a kernel 
release  wouldn't work on dual core CPUs.


But if the problem really is that's the case, I would like to know what 
boot-time settings I can use to test this hypothesis. For that matter 
I'd like to know why the kernel itself isn't picking up on this 
theoretical problem -- ISTR reading about an enhanced CPU clock mode 
that could solve this problem, but I can't find references to it or how 
to build a kernel or modules from source that would include this capability.


I've spent a substantial amount of time on this problem, and I can't 
come to any conclusion. I have to wonder if it's a problem with NTP 
itself, but if so it's a problem that only manifests itself on the AMD64 
box, although I continue to fiddle with NTP settings.


--
Moshe Yudkowsky * [EMAIL PROTECTED] * www.pobox.com/~moshe
 If, after hearing my songs, just one human being is inspired to
  say something nasty to a friend, it will all have been worthwhile.
-- Tom Lehrer


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]