From owner-freebsd-current Tue Oct 29 09:04:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08673 for current-outgoing; Tue, 29 Oct 1996 09:04:44 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA08663 for ; Tue, 29 Oct 1996 09:04:40 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA01058; Tue, 29 Oct 1996 12:04:34 -0500 Date: Tue, 29 Oct 1996 12:04:34 -0500 From: Garrett Wollman Message-Id: <9610291704.AA01058@halloran-eldar.lcs.mit.edu> To: Julian Elischer Cc: current@freebsd.org Subject: divergence of clocks In-Reply-To: <327546DD.794BDF32@whistle.com> References: <327546DD.794BDF32@whistle.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > I didi note however that the RTC is reported as producing interrupts, > so wohat would it take to set Hz to 128 and use that tick instead? > (interrupt priorities? etc? etc?) Bruce already mentioned the other problems with using the RTC as the system clock which result from its internal interrupt timer being inaccessible. There are other problems, however. The principal problem is one which you may never see in your embedded environment, but which constitutes a serious (and not truly solved) problem in a multi-user world: if the scheduling clock and the resource-usage clock run at the same rate, then it is possible to write a program such that it soaks up almost all the CPU, but then yields control immediately before a clock tick would cause its resource usage to get updated. Thus, such a program would be immune to the normal mechanisms which cause CPU hogs to gradually lose priority. FreeBSD is still subject to this problem; it's just a bit more difficult to exploit. The RTC clock has other benefits as well which make it useful even despite this fact (in particular, other programs which run synchronous to a clock without any malicious intent will get scheduled somewhat more appropriately). The PC hardware platform is just isn't sufficiently capable---it doesn't have enough programmable clocks! 4.4BSD solves this completely on platforms which have two clocks by randomizing the period of the statistical clock (that's what the random() function in the kernel was written for), thus making it next to impossible for a malicious program to run synchronously with the statistics clock. Van Jacobson (and someone else) wrote a paper about this some years back; it's available from ftp.ee.lbl.gov. If you have more control over your hardware, it would not be too difficult to set up a better interval timer scheme. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick