Re: Terrible Clock Skew
On 12/8/10, Dave Cundiff wrote: > Hi everyone, > > I posted this to the forum as well but figured I'd try here since the > same people might not subscribe to both. > > I've been experiencing some terrible clock skew and just can't figure > it out. By terrible I mean I'm losing 30 minutes a day. The loss only > occurs when I bring the system under heavy load. The load is multiple > Rsync backups to a ZFS pool(with gzip compression) backed by a 16 disk > Raid50. I'm using a hardware Raid controller for battery backed write > caching. > > Mobo: Supermicro X8DTL > CPU: Dual Intel 5620 quad cores > Raid: Areca 1620 > > I have ntp enabled but the skew happens to fast and it stops trying. > I've tried a bunch of stuff from the various lists. I tried all my > clock sources. TSC(-100) HPET(900) ACPI-fast(1000) i8254(0). I tried > changing the kern.hz flag lower. I also tried disabling the enhanced > speed step feature of this chip as per the FAQ on the site. Nothing > works. > > Currently I'm defaults except the following settings. > > EIST Disabled in BIOS > kern.hz="100" > kern.timecounter.hardware=i8254 > > Is there anything else I could do to debug this? I can't really blame > the hardware because I have these same boards/chips running in Linux > with no clock issues. In the man page for ntpd, you might look into "The huff-n'-puff Filter". Not saying it will help, but it seems like you've tried everything else. -Modulok- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Terrible Clock Skew
Hi, Dave-- On Dec 8, 2010, at 12:01 PM, Dave Cundiff wrote: > Hi everyone, > > I posted this to the forum as well but figured I'd try here since the > same people might not subscribe to both. I'm not sure which forum you're mentioning here, although it proves you right about the conclusion you'd made here. :-) > I've been experiencing some terrible clock skew and just can't figure > it out. By terrible I mean I'm losing 30 minutes a day. The loss only > occurs when I bring the system under heavy load. The load is multiple > Rsync backups to a ZFS pool(with gzip compression) backed by a 16 disk > Raid50. I'm using a hardware Raid controller for battery backed write > caching. That kind of slew rate is well past what ntpd can deal with; it suggests possibly that you're losing timer interrupts, or maybe that the "time of day" clock on the motherboard is broken or dead. Output of "vmstat -i" might be informative for the former, for the latter check whether the BIOS can keep the clock sane while in the BIOS menu-- there should be a small Li battery on the motherboard which might be replaceable. You might also double-check that you've got the latest BIOS version update, but that's less likely to help. For a workaround, you can fire off "ntpdate -b" from cron every 5 minutes or similar to keep the clock from drifting too far. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Terrible Clock Skew
On Wed, Dec 8, 2010 at 3:01 PM, Dave Cundiff wrote: > Hi everyone, > bad button battery maybe? when the system is under load, it's diverting what ever processor time to correct for the skew elsewhere (guessing). If it is a bad battery, setup NTP to reset your system clock more frequently. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Terrible Clock Skew
Hi everyone, I posted this to the forum as well but figured I'd try here since the same people might not subscribe to both. I've been experiencing some terrible clock skew and just can't figure it out. By terrible I mean I'm losing 30 minutes a day. The loss only occurs when I bring the system under heavy load. The load is multiple Rsync backups to a ZFS pool(with gzip compression) backed by a 16 disk Raid50. I'm using a hardware Raid controller for battery backed write caching. Mobo: Supermicro X8DTL CPU: Dual Intel 5620 quad cores Raid: Areca 1620 I have ntp enabled but the skew happens to fast and it stops trying. I've tried a bunch of stuff from the various lists. I tried all my clock sources. TSC(-100) HPET(900) ACPI-fast(1000) i8254(0). I tried changing the kern.hz flag lower. I also tried disabling the enhanced speed step feature of this chip as per the FAQ on the site. Nothing works. Currently I'm defaults except the following settings. EIST Disabled in BIOS kern.hz="100" kern.timecounter.hardware=i8254 Is there anything else I could do to debug this? I can't really blame the hardware because I have these same boards/chips running in Linux with no clock issues. -- Dave Cundiff System Administrator A2Hosting, Inc http://www.a2hosting.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
