Return to BSD News archive
Xref: sserve comp.periphs:4135 comp.realtime:3568 comp.os.386bsd.development:1077 Newsgroups: comp.periphs,comp.realtime,comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uunet!pipex!ibmpcug!ibmpcug!jshark!joe From: joe@jshark.inet-uk.co.uk (Joe Sharkey) Subject: Re: Why fix the RTC (Real Time Control) for 386bsd Organization: Individual Network (UK) Date: Tue, 17 Aug 1993 00:24:47 GMT Message-ID: <CBvntC.Iys@jshark.inet-uk.co.uk> Keywords: RTC report References: <jmonroyCBuLr1.7L3@netcom.com> Lines: 63 Oh, no, J.Monroy, you're doing "it" all over again.... Why:-( Will we learn anything? Will we get a better OS? A nice happy feeling? In article <jmonroyCBuLr1.7L3@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes: > The text that follows is self-explainitory, > except that this is only the first 40 lines of the > report. Usually, "RTC" == "Real Time Clock". Do you mean this too? >===================================================================== >Reasons to fix the RTC. Is it broken? How? Unix has used several "Real-Time Clocks" since the PDP days - what was wrong? Why did no-one notice? If you have access to BSTJ, you may want to look at derivatives such as MERT before making a definitive answer. > At the request of Bill Jolitz and other, I have > written this report. I should note that this is NOT a request > for a Real-Time OS (Operating System). Also, I was a bit > unaware of the lack of work done in this area, RTC (Real-Time > Control). My assumption was that other had this knowledge, as > second-hand, just as John Sokol and I. Geez, Jesus, subtle you aren't! *I* thought preventing reactors going critical was in the "RTC" area - well, maybe you're a bit more laid back in California? Real-Time Operating Systems are different from UNIX: have you managed to work out why a QIC-40 driver is *so* difficult to write. > sections are broken up by a set of triple dashed lines with > the section number in the center of the line. The first > section shows that time is an issue and planning is better > than post (or run-time) analysis. The second section shows > that interrupts and the error recovery process are the main > contentions for efficient context switching and kernel > operations. So, not having a failure will greatly increase > system efficiency (This should be a Given.). Section Three > answer the popular myths about RTC. In section four are > comments from Mr. David Brown of UCSD about his > experiences with the QIC-40/80 implementation. Lastly in > Section Five are my comments and recommendations. I don't even understand the synopsis of section two :-( Jesus, are you using the same terminology as the rest of the world? >Jesus Monroy Jr joe. -- Joe Sharkey joe@jshark.inet-uk.co.uk ...!uunet!ibmpcug!jshark!joe 150 Hatfield Rd, St Albans, Herts AL1 4JA, UK Got a real domain name (+44) 727 838662 Mail/News Feeds (v32/v32bis): info@inet-uk.co.uk