From owner-freebsd-stable Thu Jul 22 12:42:19 1999 Delivered-To: freebsd-stable@freebsd.org Received: from shell.webmaster.com (mail.webmaster.com [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 15DFB155F6 for ; Thu, 22 Jul 1999 12:42:16 -0700 (PDT) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Thu, 22 Jul 1999 12:40:31 -0700 From: "David Schwartz" To: "Mike Smith" Cc: Subject: RE: Tuning the system's clock Date: Thu, 22 Jul 1999 12:40:31 -0700 Message-ID: <001801bed47a$0efc31a0$021d85d1@youwant.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <199907220628.XAA01044@dingo.cdrom.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > FreeBSD's internal high-precision clock seems to be based on the > > processor's instruction cycle counter. I've found that on one > machine, the > > clock is about 150 ppm fast. So I tried to reduce the machdep.tsc_freq > > value. That was bad -- instant reboot. > > The TSC is calibrated at boot time using the RTC; that calibration is > inherently limited to the accuracy of the RTC. Exactly. The RTC is accurate to maybe 150 ppm. The other problem is that this calibration occurs right after power up, when the system is 'cold'. It's not going to be representative of the system's 'warm' rate either. > The TSC is ill-suited to precision timekeeping, as the CPU clock > frequency is not particularly precise, nor is it guaranteed to remain > at any given value (many power-management schemes adjust the CPU clock > to control power consumption). The only real use for the TSC is > accounting for total elapsed clock cycles over some code fragment (and > even that's compromised by SMM). Well, I have two fairly specific problems that could be eased by being able to tune the TSC. One of them is drift inbetween when I run 'ntpdate' and when 'xntpd' has its first valid offset. If I could tune the TSC just a little bit, I could minimize that drift and make XNTP converge a lot faster. This machine has a local GPSClock 200 and is a public stratum one server (tock.gpsclock.com). It takes it about 15 minutes after a reboot to stabilize. I think I could halve this time if I could set an initial estimate of the TSC counter. > If you want to do accurate timekeeping on a PC, use add-in hardware > designed for the purpose. You will find nothing in the standard PC > architecture suited to the task. You might want to talk to Poul about > the XRPU hardware that he's been using for this very task. I think you are giving up too easily. Just because ultimate accuracy may not be possible, that's not excuse for not having the tools that let you do the best with what you have. For one thing, the TSC oscillator can be replaced with a high-precision OCXO. But that won't help you if you can't tune the TSC divisor, will it? (Of course, XNTP would be the right tool for this purpose.) In any event, tuning the TSC divisor via sysctl causes my FreeBSD-STABLE machine to reboot instantly. I've just found that NTP seems to work the best when the system is already keeping pretty good time. David Schwartz http://www.gpsclock.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message