My newyear's resolution is...

[Matthew Dillon]

   Holy cow, that's a lot of work you did, and very interesting work at
   that!  I'll adapt your patch that makes the partial fix to deal with
   the minimum tick requirement (at least one tick must be slept) and
   commit that, and I look forward to your additional investigations.

   In regards to changing the kernel timing precision, there are many
   possible solutions there.  I don't think we want to follow FreeBSD's
   solution there.  In fact, I think all the timercounter code needs to
   be rewritten to rip out the dynamic-changing feature and instead just
   using a fixed timer (8254, ACPI timer, or APIC timer) and a frequency
   determined at boot time, then store native timeouts based on the
   selected frequency.

   Note that the various hardware timers available on PCs are generally not
   synchronized with each other.  They will all drift relative to each
   other.  The most consistent timer for short delay timing is the 8254
   (once you get a rough approximation of its frequency by using the real
   time clock chip to time it).  The 8254 also tends to drift slowly and
   so is not suitable for wall-clock timekeeping over long periods of time.

   Each timer source has its problems.  The ACPI timer might have bit errors
   due to the actual flip flop clocking not being synchronized with bus reads
   of the timer register, and the APIC timer might physically stop counting
   or slow down when a cpu is placed in a lower power or lower clock rate 
   mode.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>


:...nano!
:
:There are some minor bugs in the clock code that produce
:interesting results.  For background info, have a look at:
:
:  http://www.frenchfries.net/paul/dfly/nanosleep.html
:
:There are still some open problems that I haven't gotten to yet,
:such as the clock aliasing, but I thought I'd share my tinkering
:with the fine folks on the list before I go on vacation and see
:what sticks.  I also have other longer term ideas such as
:decreasing the precision of most kernel timing from micro seconds
:to nano (or perhaps even atto).  Most of the internal work now
:still seems to be done in struct timevals (microseconds.)
:
:Anyway, there is a patch burried on the page to correct one of the
:problems with tvtohz(). It works fine, but it probably shouldn't be
:commited as is, because there are other places in the kernel that
:use tvtohz() that should be (re)adjusted for the change in ticks.
:
:Comments, questions, and/or discussion is welcome!
:
:Happy new year!
:-Paul.