oldlinux-files/distributions/386BSD/0.1/386BSD/ANSS2

	report.	 The next paragraph is an outline on the report.



		This  is a breakdown of the sections below.  The

	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.



		    -----------o0o--------------



		Before starting I will define some words:



		Clock	    Time giver; this device always has the

current time in a real-time format, but

not necessarily a earth-time format.

(I.E. hours/minutes/seconds)



		Timer	    This should be like a stop/start watch.

The purpose is to measure elapsed time,

and signal (precision alarms).



		Counter	    This will be a hardware/software counter.

The purpose of which is to count the

passage of time in a sliced fashion; in

this way it just counts and is not

referenced to anything in general.





		    -----------o1o--------------

		    -----------o1o--------------

		    -----------o1o--------------



			Why fix the RTC

			---------------



		Speed is our paradox as end users ask for flexibility

	and better services.  Those of us involved with the technology

	know that more speed is available,  such that the applicator

	to this, will ask for this, volante, and more.	The disjointed

	questions, listed below, arise:



		How do we plan for the unknown?



		What historical facts may lead us toward the right

		decisions?



		Is having more than one clock necessary?



		If so, what functionality is needed?



		How is this of benefit to the QIC-40/80?



		Who will decide these issues?





		Strangely enough I will say this may already be decided

	for 386bsd.  Even more strange, I plan not to discuss, in

	depth, the aspects of RTC (Real Time Control) of a Non-real

	time OS, like 386bsd. [1]



		What will follow are: reasons for a functional RTC

	(Real Time Clock) and Reasons for the new temporal

	(time-related) system calls.  In addition, before starting I

	should say that these notes may also be released with "RTC

	Notes", articles in which I plan to explain the exploit of

	the RTC (clock).  A few persons have expressed interest

	in writing this driver, they include:



		gordon@sneaky.lonestar.org	  Gordon L. Burditt

		sokol@reyes.stanford.edu	  John L. Sokol





			-----------o1o--------------





		To start off with it is best that I quote someone.





		"Time is fundamentally different from the state

		 components of a computing machine.  For all we

		 know, time is continuous, monotonic and

		 divergent, and program variables generally

		 happen not to have any of these characteristics.

		 Only if we recognize the special status of time

		 will we be able to find and exploit the

		 intricacies of providing time properties and

		 avoid pitfalls like "Zeno" behaviors, which
78M8	should say that these notes may also be released with "RTC78M8	(time-related) system calls.  In addition, before starting I78M8	(Real Time Clock) and Reasons for the new temporal78M8		What will follow are: reasons for a functional RTC78M878M8	time OS, like 386bsd. [1]78M8	depth, the aspects of RTC (Real Time Control) of a Non-real78M8	for 386bsd.  Even more strange, I plan not to discuss, in78M8		Strangely enough I will say this may already be decided78M878M878M8		Who will decide these issues?78M878M8		How is this of benefit to the QIC-40/80?78M878M8		If so, what functionality is needed?78M878M8		Is having more than one clock necessary?78M878M8		decisions?78M8		What historical facts may lead us toward the right78M878M8		How do we plan for the unknown?78M878M8	questions, listed below, arise:78M8	to this, will ask for this, volante, and more.	The disjointed78M8	know that more speed is available,  such that the applicator78M8	and better services.  Those of us involved with the technology78M8		Speed is our paradox as end users ask for flexibility78M878M8			---------------78M8			Why fix the RTC78M878M8		    -----------o1o--------------78M8		    -----------o1o--------------78M8		    -----------o1o--------------78M878M878M8			    referenced to anything in general.78M8			    this way it just counts and is not78M8			    passage of time in a sliced fashion; in78M8			    The purpose of which is to count the78M8		Counter	    This will be a hardware/software counter.78M878M8			    and signal (precision alarms).78M8			    The purpose is to measure elapsed time,78M8		Timer	    This should be like a stop/start watch.78M878M8			    (I.E. hours/minutes/seconds)78M8			    not necessarily a earth-time format.78M8			    current time in a real-time format, but78M8		Clock	    Time giver; this device always has the78M878M8		Before starting I will define some words:78M878M8		    -----------o0o--------------78M878M8	Section Five are my comments and recommendations.


78M8	experiences with the QIC-40/80 implementation.	Lastly in78M8	comments  from	 Mr. David Brown of UCSD  about his78M8	answer the popular myths about RTC. In section four are78M8	system efficiency (This should be a Given.).  Section Three78M8	operations.  So, not having a failure will greatly increase