On 02/27/2009 07:46 PM, Rashkae wrote:
> NoOp wrote:
>> On 02/27/2009 06:55 PM, Rashkae wrote:
>>> NoOp wrote:
>>>> I recall that thread:
>>>> [Computer loosing time]
>>>> might be worth looking at again.
>>> Not really,, That thread led me to believe the problem was with my power
>>> supply, which I replaced, and declared success. However, my success was
>>> very short lived. It was afterwards that I discovered I can fix it by
>>> changing my clocksource from tsc to acpm, but this was something so
>>> obscure, (and it seemed, not bothering anyone else) that I never
>>> bothered posting about it.
>> But shouldn't it switch automatically to acpi_pm if tsc is not stable?
>> For instance, on the Thinkpad A21M that I receive the dmesg of:
>> Clocksource tsc unstable (delta = -87685142 ns)
> yes, it should. but stable doesn't really have much to do with
> accurate... TSC is not accurate, it's not even meant to be. (I'm not
> sure exactly what kinds of problems make it unstable. I used to think
> it was synchronization between cpu cores, but apparently, there is more
> to it than that.)
> On systems where it works, however, TSC is very performance friendly. I
> guess the reasoning is, having an 8 core super server with dozens of
> vm's is all fine and good, unless all your processes get stuck
> contending for the one timer chip on your mobo.
Found out what TSC stands for: Time Stamp Counter
3.4. TSC timer synchronization on Opteron CPUs
The current generation of AMD64 Opteron processors are susceptible to a
large gettimeofday skew when cpufreq is enabled while using the Time
Stamp Counter (TSC). MRG Realtime provides a method to prevent this on
Opteron systems by forcing all processors to simultaneously change to
the same frequency. As a result, the TSC on a single processor never
increments at a different rate than the TSC on another processor.
$ man gettimeofday
is interesting... again, don't understand it all, but it is interesting :-)
ubuntu-users mailing list
Modify settings or unsubscribe at: