[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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 * moshe@pobox.com * 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


Reply to: