ntpd lagging some 4...5 min behind true time

[OS2-User]

Since about a week I noticed that the Clock 2.28.0 panel applet is somewhere between some 30sec up to about 4min behind the true ntp time on my laptop running Helena, depending on how long the system is already running.
There may another one or two weeks before that, when the time started to run out of sync with the ntp servers unnoticed. Before that, the ntpd time synchronisation was working fine, since Helena first became available.

Since I didn't make any recent changes to the time server settings, I can only suspect, that it might be related with the latest update to "Kernel 2.6.31-21-generic i686 (32 bit) Distro Linux Mint 8 Helena - Main Edition" around that time or any of the other updates, suggested by MintUpdate, since then.

Do others lately see problems in that area as well?

After googling around for a while, I found the following bits and pieces:

$ sudo /etc/init.d/ntp restart <-- does not resync the time.
However: $ sudo /etc/init.d/ntp stop --> $ sudo ntpdate-debian pool.ntp.org
adjusts the time as expected, but the time seems to be running off again rather quickly, if I interpret the following correctly:

$ sudo hwclock && date
Sa 24 Apr 2010 21:18:57 CDT -0.548274 Sekunden
Sa 24. Apr 21:20:36 CDT 2010
$ sudo ntpdate-debian pool.ntp.org
24 Apr 21:21:01 ntpdate[21395]: step time server 207.171.30.106 offset 0.869317 sec
$ sudo ntpdate-debian pool.ntp.org
24 Apr 21:26:10 ntpdate[21415]: step time server 131.188.3.222 offset 2.291199 sec

$ sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource
acpi_pm pit jiffies tsc
$ sudo cat /sys/devices/system/clocksource/clocksource0/current_clocksource
jiffies

$ cat /var/lib/ntp/ntp.drift
0.000

$ grep ^server /etc/ntp.conf
server constellation.ecn.uoknor.edu
server wuarchive.wustl.edu
server 0.us.pool.ntp.org
server ntps1-2.uni-erlangen.de

$ sudo ntptime
ntp_gettime() returns code 5 (ERROR)
time cf7e6c04.c2fa3f84 Sun, Apr 25 2010 2:21:40.761, (.761631059),
maximum error 16000000 us, estimated error 16000000 us
ntp_adjtime() returns code 5 (ERROR)
modes 0x0 (),
offset 0.000 us, frequency 0.000 ppm, interval 1 s,
maximum error 16000000 us, estimated error 16000000 us,
status 0x2040 (UNSYNC,NANO),
time constant 0, precision 0.001 us, tolerance 500 ppm,

$ sudo /etc/init.d/ntp restart
* Stopping NTP server ntpd [ OK ]
* Starting NTP server ntpd [ OK ]

$ sudo ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
ip72-215-225-9. .INIT. 16 u - 64 0 0.000 0.000 0.000
insularum.seas. .INIT. 16 u - 64 0 0.000 0.000 0.000
point2.adamants 64.73.32.134 3 u - 64 1 66.987 158693. 3.906
ntp2.rrze.uni-e .INIT. 16 u - 64 0 0.000 0.000 3.906

$ sudo /etc/init.d/ntp status
* NTP server is running.

I'm still far from understanding the inner workings of the Linux clock and time syncing and am not even sure, to what degree the above results might be helpful for troubleshooting.
But what I do know is, that I need substantial help in order to find out, why my system time now suddenly has a serious, increasing drift and what I can do, to fix that.

[Biker]

I think this is nothing more than a simple port issue. Ensure port 123 is open on your router and firewall. That's it.

[OS2-User]

I don't think that this is the cause, since the syncing seems to be working just fine when initiated manually. It also doesn't explain the clock drifting off again by almost 3sec within the first 5 min after re-syncing.
By now I'm suspecting some issue with the used time/clock base or whatever, which must have changed somehow and not a problem with ntpd per se any more.
I now think that the max. system time drift of almost 5 min against the true time I'm experiencing here, just happens to be the maximum possible between ntpd re-syncing intervals.

[OS2-User]

To test, if my current clock problems are actually kernel related, I'd like to give it a try and downgrade to the previous Kernel 2.6.31-20-generic.
But how exactly am I supposed to do that?

Everywhere I look, f.e. in Synaptic or at http://ubuntuupdates.org/packages/show/159767, I am told to install "the linux[-backports-modules]-generic meta-package, which will ensure that upgrades work correctly, and that supporting packages are also installed."

Only problem: I cannot find any trace of those obscure "meta-packages" anywhere.

So, where are they hiding and how does manual up-/downgrading to another kernel version actually work?

[spegru]

I had a similar or at least related problem with my AMD 3200 processor system. After an update around two months ago the clock would run crazily fast and cursor would be incontrollable, impossible to double click etc. Also caused skype to fail, presumably due to completely out of sync clocks
I've had this problem before with previous distros (but it had gone away for at least a year - don't know why it suddenly came back), so I knew a couple of fix ideas.
The one I used last time was to add the term clock=tsc to the grub boot parameters, but this time that fix caused the system clock to run very slow instead, and skype still didnt want to work.
SO now a bit of googling has revealed another fix. Also within grub boot parameters, but this time the command is clock=pmtmr and this now works fine.
Seems to be an AMD hardware related issue

[OS2-User]

Spegru, thanks for your reply. In fact my laptop is running on an Athlon XP-M, so that connection to AMD CPUs might be quite interesting.
I'd like to give your solution a try here as well, but am not yet familiar enough with Linux to get to it right away.
Could you please give detailed instructions, what to edit where and how to make those GRUB changes active?

[spegru]

I just found this entry in syslog

Sep 13 17:51:57 stephen-desktop kernel: [ 83.380155] Marking TSC unstable due to cpufreq changes
Sep 13 17:51:57 stephen-desktop kernel: [ 83.380233] Switching to clocksource acpi_pm

Seems to explain my previous problem and possibly why they have gone away now. Anyway try adding clocksource acpi_pm to youe boot parameters.
In the first intance you shoul dbe able to interrupt grub by pressing esc and then edit using the on screen prompts.
If that works then add it permanently to your grub setup

[DrHu]

The clock on the OS (Ubuntu/Mint) is always or seems to be recently updating tzdata

You could try another ntp daemon, openntpd if you wished...

Code: Select all

apt search tzdata
i   tzdata                          - time zone and daylight-saving time data
 apt search ntpd
p   cyrus-nntpd-2.2                 - Cyrus mail system (NNTP support)
v   cyrus21-nntpd                   -
v   cyrus22-nntpd                   -
i   ntpdate                         - client for setting system time from NTP se
p   openntpd                        - OpenBSD NTP daemon p

ntpdate is rough sync of the time data..
http://www.linuxhomenetworking.com/wiki ... NTP_Server
--see sync sections..
http://www.groupsrv.com/linux/post-171017.html