Announcement

Collapse
No announcement yet.

AMD C1E: wrong system time

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMD C1E: wrong system time

    Hello,

    when I enable C1E in the BIOS my cpu temps get a few degrees lower with Phenom II X2, but the problem is that my system time goes wrong now.
    The mainboard is a GA-MA78GM-UD2H from Gigabyte with 780G.

    It's an offline PC so otherwise you could sync more often with NTP I guess. Any idea how to solve or workaround this and keep the benfits of C1E (energy saving, lower noise, more potential longevity of chips and fans)?

    thanks in advance

  • #2
    Very strange. I wonder if C1E is tied into the same timer as the CMOS? Otherwise I have no idea. I have exactly the same board as you, so I'm gonna take a look into this and see if I can duplicate the clock problem. I dont have the ability to fix it, but maybe we can troubleshoot the problem together.

    Comment


    • #3
      Check which clock is used in /sys/devices/system/clocksource/clocksource0/current_clocksource. If it's not "hpet", make sure it's enabled in the bios, If it is, you could try one of the other clocks listed in /sys/devices/system/clocksource/clocksource0/available_clocksource.

      You could also try to periodically sync your system clock to the hardware clock (with hwclock -s) as a workaround.

      Comment


      • #4
        thank you and sorry for the delay

        Surprisingly, the clock seems to work perfectly now after setting the correct time again with linux.
        I remember that linux can correct systematic time drift with software and tries to detect that drift automatically when the time is set manually, at least this was so in a Debian release a few years ago.

        Problems with C1E and clock were reported here too, on windows, (so I decided to post it also on phoronix without much further thought):
        I was debugging my system why clock drifts occurs so badly. It has gotten to a point that I have to update every 30 minutes in order to update clock every 30 minutes to correct shift in clock that is more than 3 minutes delta. What I noticed recently is that the clock drift does not occur in the...

        http://www.silentpcreview.com/forums...ic.php?t=57951 (comment by "bottom")
        --

        Interesting information, chefkoch. On my Ubuntu 10.04 32bit

        current_clocksource is tsc,
        available_clocksource is tsc hpet acpi_pm


        So hpet doesn't seem to be the default, is it advisable to change it?...I will look a bit on the internet.


        PS just for the record, when leaving the system in idle several hours, the clock was late approximately half an hour

        Comment


        • #5
          tsc as a clocksource is pretty unstable on my own system, so it now uses acpi_pm for clocksource. TSC tends to drift wildly and not sure what is the underlying cause

          Comment


          • #6
            I checked syslog which shows that the clocksource had been changing several times to hpet without me noticing. It said "clocksource tsc unstable" and eg. delta = 300014646454 ns.

            Everything is still working fine at the moment. I think the automatic linux drift correction I've mentioned has nothing to do with it because the /etc/adjtime file is not present. (maybe something changed here in recent Ubuntu releases though)

            But I've read TSC access is the fastest. I don't know how relevant this is for a desktop system, though.

            Comment


            • #7
              TSC is the best choice when you have the constant_tsc cpu-flag -which all modern phenom have. Second best choice is hpet.
              One of the worst methods is acpi pm_timer.

              The kernel chooses the best available timesource. If it detects a constant tsc it will use that.

              Don't change it.

              And don't listen to advice that was good 3 years ago.

              Comment

              Working...
              X