System clock skew

kdemidofff

Member

Reaction score: 7
Messages: 94

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
Code:
powerd_flags="-a hiadaptive -b adaptive -i 85 -r 60"
Code:
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:

Code:
#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@

Aspiring Daemon
Developer

Reaction score: 218
Messages: 702

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

Daemon

Reaction score: 184
Messages: 1,012

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.
 
OP
OP
K

kdemidofff

Member

Reaction score: 7
Messages: 94

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

Daemon

Reaction score: 503
Messages: 2,229

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:
Code:
kern.timecounter.hardware=timer_you_chose
 

Carpetsmoker

Daemon

Reaction score: 184
Messages: 1,012

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.
 
OP
OP
K

kdemidofff

Member

Reaction score: 7
Messages: 94

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

Aspiring Daemon

Reaction score: 109
Messages: 783

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@

Aspiring Daemon
Developer

Reaction score: 218
Messages: 702

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.
 
Top