我的linux服务器时间每天慢10来分钟

感觉是驱动问题，导致系统对主板时钟晶振的频率对应的时间产生了差错？

Linux 开机后的时间是系统自己维护的，不以主板时间为准。这样系统自己维护的时间如果晶振频率的部分有问题，那肯定时间会不准。

不行你就设置每 30 分钟从主板对时一下吧。

转换误差2.      时钟不稳定3.      时钟频率不对

1.转换误差

现在我们可以获取到cycles的计数值，也知道了HZ=50M，那么根据公式很容易就得到系统时间了。

times_elapse= cycles_interval / frequency

但是，因为内核中使用除法不太方便，所以将这个公式转换成了乘法与移位 *** 作

times_elapse = cycles_interval * mult >>shift

关于这个转换有个专门的内核函数，可以由frequency和精度值计算出mult和shift

后面再贴。

从上面clocksource_timebase的定义已经看到shift=22， mult=0(后续计算) 了，看一下mult的计算。

在clocksource_init 函数中找到mult的初始化

clock->mult= clocksource_hz2mult(tb_ticks_per_sec,clock->shift)

打印出来这个值为clock->mult =83886080

现在shift和mult的值都有了，那我们来验证一下转换的误差

就以times_elapse = 1s为例，则cycles_interval = frequency = 50000000

按照公式：

times_elapse = cycles_interval * mult >>shift

>>>(50000000*83886080)>>22

1000000000L = 1s

由此可见，将除法转换成乘法并未带来误差。

2.时钟频率不对

前面的计算都是按照CCB Clock 8分频50M来计算，但是这个50M是否准确？

那就看看这个50M到底从哪来的

time_init (/arch/powerpc/kernel/time.c)

-->ppc_md.calibrate_decr() == generic_calibrate_decr(void)

-->get_freq("timebase-frequency",1, &ppc_tb_freq)

此处获取到的ppc_tb_freq = 50M

get_freq是从设备树中读取的，但实际的设备树中并没有timebase-frequency这个选项

最终找到uboot中 fdt.c (arch/powerpc/cpu/mpc85xx)

void ft_cpu_setup(void *blob, bd_t *bd)

{

do_fixup_by_prop_u32(blob,"device_type", "cpu", 4,

"timebase-frequency",get_tbclk(), 1)

}

由do_fixup_by_prop_u32将get_tbclk()的值填入"timebase-frequency"，原来是uboot创建了这个选项，继续查找50M的来历，看看get_tbclk函数

à

#ifndef CONFIG_SYS_FSL_TBCLK_DIV

#define CONFIG_SYS_FSL_TBCLK_DIV 8

#endif

unsigned long get_tbclk(void)

{

unsigned long tbclk_div = CONFIG_SYS_FSL_TBCLK_DIV

return (gd->bus_clk + (tbclk_div >>1)) / tbclk_div

}

àget_clocks

gd->bus_clk = sys_info.freqSystemBus

àget_sys_info

unsigned long sysclk = CONFIG_SYS_CLK_FREQ

sysInfo->freqSystemBus= sysclk

sysInfo->freqSystemBus *= (in_be32(&gur->rcwsr[0]) >>25) &0x1f

上面代码可以看出get_tbclk()的原始值是从CONFIG_SYS_CLK_FREQ得来的

cpu_p1020.h(include/configs)中的定义

#define CONFIG_SYS_CLK_FREQ     66666666

而实际上外部时钟是66.0M，原来是配置文件指定错了。

系统实际参数

外部时钟        =  66.0M

CCB Clock        =  396M

SYSCLK          =  792M

DDR                   =  396M

ppc_tb_freq    =  49500000

clock->mult     =  84733414

clock->shift       =  22

重新计算一下转换误差：

times_elapse = cycles_interval * mult >>shift

>>>(49500000*84733414)>>22

999999998L

误差为每秒2ns，已经很小了

不会是ntpdate 同步时间自动修改了吧？

tomcat 的时间变化，那有可能是程序代码出问题了。

有代码误调用了 TimeZone.setDefault ， 这个是比较常见的，特别是有格式化时间的代码处。格外小心，仔细查查吧，我以前被这个坑过。

import java.util.Date

import java.util.TimeZone

public class Test {

public static void main(String[] args) {

System.out.println(new Date().toString())

TimeZone.setDefault(TimeZone.getTimeZone("0"))

System.out.println(new Date().toString())

}

}

//Thu May 25 11:44:47 CST 2017

//Thu May 25 03:44:47 GMT 2017

---