# System clock skew



## kdemidofff (Jun 9, 2010)

I have bought recently ASUS P5P43TD PRO mobo (I'm aware that recently ASUS start doing bad quality hardware both mobile and desktop). I installed FreeBSD 8.1-PRERELEASE #0 r208953, now after subsequent `ntpdate` I see clock skew -12 seconds after about 2 weeks of uptime without ntpd or ntpdate

Is it normal or bad hardware? Any ideas?
Thanks in advance

I use powerd with 
	
	



```
powerd_flags="-a hiadaptive -b adaptive -i 85 -r 60"
```


```
dev.cpu.0.cx_lowest=C2
dev.cpu.1.cx_lowest=C3
dev.cpu.2.cx_lowest=C3
dev.cpu.3.cx_lowest=C3
```

P.S. some time ago I used:


```
#hint.p4tcc.0.disabled=1
#hint.acpi_throttle.0.disabled=1
#hint.apic.0.clock=0
#kern.hz=100
#hint.atrtc.0.clock=0
#hw.pci.do_power_nodriver=3
```

Edit: seems clock regularly skews for some small amount


----------



## mav@ (Jun 10, 2010)

Most of systems now have several different timers. Some of them are more precise, others more oriented on high performance then precision. You may probably try different one.


----------



## Carpetsmoker (Jun 11, 2010)

Using ntpd would also solve your problem.

I would recommend using OpenBSD's OpenNTPd, it's much more simple, it's secure, and "just works". You can install it as a port: net/openntpd.


----------



## kdemidofff (Jun 12, 2010)

But how can I test if it's related to FreeBSD software or a faulty hardware clock? Can I stop system update clock and rely only on CMOS clock only? What options related to system clock stability? Is there some program that can test clock like memory?

ntpd daemon is inappropriate as there are clock errors like two seconds in two days, which insane. I have seen months of uptime without issues on old hardware and without ntpd/ntpdate; it was P4 and FreeBSD 7.2 i386

Trying to turn off C2/C3 states and powerd now.


----------



## Beastie (Jun 12, 2010)

kdulep said:
			
		

> can i stop system update clock and rely only on CMOS clock only?


You can try the i8254 or TSC instead if you want:
`# sysctl -w kern.timecounter.hardware=timer_you_chose`.

And to make it permanent, add it to /etc/sysctl.conf: 
	
	



```
kern.timecounter.hardware=timer_you_chose
```


----------



## Carpetsmoker (Jun 12, 2010)

> ntpd daemon is inappropriate as clock error like 2 seconds in 2 days which insane



Not really, these things happen. It's more or less normal that the computer clocks drifts a bit. Yes, this is a alot, but ntpd should have little problem with it as long as the drift is stable.


----------



## kdemidofff (Jun 13, 2010)

I've disabled powerd, idle states and switched to TSC clock. Now ntp drift is 21.192 PPM after about a day of measurements which is good(?). Is there a performance penalty in using TSC instead of acpi-fast?

Thanks

P.S. was looking for those fun Garmin 18x GPS solutions which is something I can try some time ) Then I can use acpi-fast? :stud


----------



## dennylin93 (Jun 13, 2010)

Beastie said:
			
		

> You can try the i8254 or TSC instead if you want:
> `# sysctl -w kern.timecounter.hardware=timer_you_chose`.
> 
> And to make it permanent, add it to /etc/sysctl.conf: *kern.timecounter.hardware=timer_you_chose*.



The -w option isn't needed:


> The -w option has been deprecated and is silently ignored.


----------



## mav@ (Jun 14, 2010)

kdemidofff said:
			
		

> I've disabled powerd, idle states and switched to TSC clock.. now ntp drift is 21.192 PPM after about a day of measurements which is good(?)
> is there performance penalty in using TSC instead of acpi-fast?



TSC clock is the fastest possible clock, as it runs inside CPU. But due to it, depending on CPU model (at least pre-Core2Duo) it can be depending on CPU power states. On SMP systems it is also not guarantied to be synchronized between cores.

TSC precision may vary on different systems, as there may be no way to precisely get CPU frequency, in which case it is approximately calibrated on boot against i8254 timer.


----------

