Linux SMP

Here's something that isn't currently in the FAQ:

SMP system clock drift in kernel 2.0.x (lesser so in 2.2.x)

When under load (interrupts rather than cpu), the SMP linux clock drifts. xntpd is designed to fix systematic drifts and not this random drift (load correlated). Here's a couple of solutions:

Solution 1. externel-clock -> system clock

Use ntpdate to sync to other machines:

This or from Adoram Rogel <[email protected]>

My solution is to have all the UP machines run xntpd and sync to the world,
while my SMP machines have the following in their crontab:

*/5 * * * * root /usr/sbin/ntpdate -st 20 ntp-server-1 ntp-server-2 ntp-server-3

Solution 2. RTC -> system clock

Use the RTC via I/O instructions to set the system clock:

*/5 * * * * root /sbin/hwclock --utc --hctosys --directisa

Solution 3. RTC -> system clock

Use the RTC via /proc/rtc to set the system clock:

*/5 * * * * root /sbin/hwclock --utc --hctosys

Solution 4. RTC -> system clock

Use the RTC via /proc/rtc to set the system clock: Matthew Hixson - CIO, FroZenWave Communications, http://www.frozenwave.com. This is a script I wrote that I run from cron every 5 minutes.

# This fixes the time drifting problem on SMP Linux machines.
*/5 * * * * root date -s "`gawk '/rtc_time/ {print $3} /rtc_date/ {print $3}' /proc/rtc`"

SMP RTC corruption in kernel 2.2.x

A further complication is that the kernel RTC interface can break which corrupts the RTC.

In 2.2.13 and below, if you did run xntpd, you might get messages like this logged:

machine kernel: set_rtc_mmss: can't update from 157 to 34

Solution A. system clock -> RTC

The fix is to set the RTC via I/O instructions to set the system clock:

*/5 * * * * root /sbin/hwclock --utc --systohc --directisa

Solution B. system clock -> RTC

You'll find that the kernel RTC corruption results in the I/O instructions failing (see note below), so remove RTC kernel support, then use A. above

Solution C. manually set the RTC in the BIOS before every boot

BUT, the hwclock still hangs!!! So there is no way to set the RTC - use the BIOS to correct the time every boot! Arhhh.

Conclusion: drift + RTC corruption = externel-clock -> system clock . BIOS RTC every boot

With SMP, you cannot trust the system clock or the RTC, with the kernel RTC code corrupting your RTC, and xntpd resulting in kernel errors being logged.

Answer: Do not run xntpd, remove /proc/rtc support from the kernel, and instead, use 1. and C. to fix these.

*/5 * * * * root /usr/sbin/ntpdate -st 20 ntp-server-1 ntp-server-2 ntp-server-3

Might work

I had hoped the following would work, but alas the hwclock hangs and then your machine will fill-up with them. It could be that you get more mileage out this - perhaps it only needs a sleep 60 between the two commands ....

*/5 * * * * root /usr/sbin/ntpdate -st 20 ntp-server-1 ntp-server-2 ntp-server-3 ; /sbin/hwclock --utc --systohc --directisa

Notes:

I found that once a machine has this kernel RTC corruption, hwclock will hang (even though it's not using /proc/rtc), so you will have to reboot quickly after installing the crontab for the first time.
I have heard that the i386 kernel periodically flushes system clock to RTC (I guess it uses /proc/rtc so it can only do this if you compiled in /proc/rtc support - as you are recommended to for SMP)
Specific system details for two SMP machines with this problem - 450Mhz PII, ASUS MB, kernels 2.2.13,2.2.12,2.2.11,2.2.10
N.B. A similar way of specifying these cron times is
```
	0,5,10,15,20,25,30,35,40,45,50,55 * * * *
	
```