Kernel clock issue "Clocksource tsc unstable"

[Ray Parrish]

Rashkae wrote:
> Ray Parrish wrote:
>
>   
>> Hello,
>>
>> Sorry to butt in here, but I also receive the error messages about 
>> clocksource tsc being unstable. I ran the command for available 
>> clocksources and got the following output. "acpi_pm pit jiffies tsc" My 
>> system switches to acpi_pm after the error message, but I would like to 
>> read about the other available clocksource files before making a 
>> decision on which to try to use from the menu.lst file.
>>     
>
> Sorry, this is really deep magic stuff where mortals were really never
> meant to thread.  You practically have to dig through the kernel source
> to find any scraps of useful information.  I just got a crash course
> about 6 months ago when I was trying to solve a clock drift issue.  I'll
> try to provide the cliff notes, but keep in mind, this is just my
> understanding of things and I might be wrong about a fact or 2.
>
> acpi_pm is the one I know least about, other than it works on my
> computer, seems to be the standard default on recent hardware and it's
> accurate.
>
>
> pit - Programmable interrupt Timer, is the classic standard timer chip
> that was at one time required on all 386 (and maybe all XT) class
> hardware.  In essence, the kernel can program it to tic at a given
> interval, and software counts the tics (from CPU interrupts) to keep
> track of time.
>
> hpet - An intel and Microsoft joint standard, stands for high precision
> event timer, was supposed to be a replacement for pit.  According to
> some kernel development noise I hear, it does become a bottleneck in
> modern multi-threaded systems if multiple processes try to access the
> timer.
>
> jiffies - This is 'hardwareless' timer.  The software keeps track of
> time on it's own based on cpu clock cycles.  Probably not good for
> system performance, and I doubt it's accurate.  My understanding is that
> jiffies was never actually meant to be used.
>
>
> tsc - I forget what the letters stand for.. tsc is part of your actual
> CPU.  I don't know what tsc was really meant for when designed, but it's
> a poor choice for timer when time accuracy is important, because, well,
> it's simply not accurate.  When my system was using tsc, I would notice
> time drift of almost 1 minute every hour.  This seems to be considered
> 'ok' by people because you can just configure your computer to adjust
> clock daily with ntp. Asside from the problem that tsc time will drift
> depending on your system load, if you have a multi-core system, tsc will
> drift from itself on different cores.  Some multi-core cpu's will
> synchronize tsc (I think the Intel Core 2 series, for example, but don't
> quote me),, whereas other CPU's will lead to tsc being unstable and the
> system switching to something else.  (although, this should all happen
> automagically, a system throwing a hairball over it should be considered
> a bug.)
>   
Thanks Rashkae!

I had tried at an earlier date to use the kernel load line to load acpi 
as the default clocksource, as that is the name it appears under in my 
log files, but it didn't work as I did not know the full name was 
actually acpi_pm. Now that I've used your command to ferret out the 
actual name, and also with the help of your tutorial here in this thread 
I can now change it over.

After reading the links provided in this thread, I'm wondering if it 
would even be that big of a deal on my system for tsc to remain enabled, 
as I have only a single core cpu, so it shouldn't suffer from the 
synchronization problem like a multi core cpu, if I'm understanding the 
problem correctly.

But then the system marks it unstable anyway, and switches to acpi, so 
to get rid of the error message I'll change it over in menu.lst.

It would be difficult to slip very far out of time on here considering 
how often my ntp daemon polls the time servers, which is every couple of 
minutes. I haven't yet discovered how to control the frequency of those 
polls. When running Windows on this T3410 Emachine I only have one daily 
time server synchronization just after boot up, and it has always kept 
time to within 30 seconds a day drift or often much less, so I wonder 
what they are using for a clocksource?

Thanks again, Later, Ray Parrish

-- 
Human reviewed index of links about the computer
http://www.rayslinks.com
Poetry from the mind of a Schizophrenic
http://www.writingsoftheschizophrenic.com/