Just some thoughts. busy looping Nanosleep... What guarantees does linux make in the face of clock resets? A sched_yield() would busy loop but play nice with other tasks? Hmm. about microseconds RTC drift can be largely compensated but the residual error is still likely to measure in milliseconds. The clock speed may depend on ambient temperature which may have a daily cycle, etc. I think it is impractical to try too hard if the result is convoluted code. There could be a --tolerance option. Sandwich the rtc reads/writes between gettimeofday()'s and max_err += time_diff(a, b). Have utility return failure if tolerance could not be met. Never restart operations. (Actually I don't like tolerance as an option, but debug could show max_err.) writing the rtc There is no need to wait until [half] second. Just write it down and record fractions of second in adjfile. If adjfile contains both drift and this offset, the error can later be corrected. setting system clock If --noadjfile is given, skip tick synchronization. (max_err += 0.5) Compensate for drift, offset. Set adjtimex() tick and freq (optionally). Kalev -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
