> Another, separate problem is the issue of arbitrary drift caused by > console messages. It is my understanding that some unices turn off all > interrupts when dumping messages to the console and as such can cause the > timer to miss a beat. Such is the reason for timed and many other > collaborative clock management daemons. > > I would propose a more subtle mechanism where the system could be told to > gain or lose a certain number of seconds, but with an inbuilt maximum rate > of change (say one second every minute). This would allow for gradual > corrections that are arbitrary on top of a system for guarding against > constant drift. "I need to make up 13 seconds." -> timetrim( 13 ). > > This could all be layered on top of the existing Linux adjtimex however I > don't know what the limits of it are (i.e. could you make a system gain an > hour every second). You would also need some method for re-setting the > time adjustment back to the 'no adjustment' adjustment when the desired > change has been made. Before you reinvent the wheel or try to change any kernel interfaces related to time synchronization, I'd suggest you take a look at http://www.eecis.udel.edu/~ntp, which includes a complete description of the Internet-standard Network Time Protocol and how it works, including a reference implementation. This is perhaps the single most important program that actually _uses_ those interfaces, and it uses them to do fairly complex corrections that allow the time to be readjusted while still being monotonically increasing. -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu> Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:14:45 PDT