Hello Kalev, On Friday, August 8, 2008 at 3:11:02 +0300, Kalev Soikonen wrote: > about microseconds > I think it is impractical to try too hard if the result is convoluted > code. An elegant code giving inaccurate results is not an elegant 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.) At first sight, this doesn't seem very interesting to me. It seems better to provide the best possible accuracy by default, and have options like --fast to degrade it for something. However reporting the residual error of clock writes is a good idea. See the --reporterror option of hwclock 2.33: | # hwclock --systohc --reporterror | Hardware Clock set to +0.000067 seconds from intended value Of course, if it can be measured, then it can be compensated. > 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. There is a good and a bad idea. The offset correction gives a very good virtual accuracy, visible to hwclock itself, and to all applications supporting /etc/adjtime: Good. But other applications see a very wrong time: Bad. Push the bad idea a bit more: There is no need to call RTC_SET_TIME. Just record the current offset. ;-) Yes, it works well, I experimented this some time ago to solve a PIE clocksource unstability problem. Option not implemented yet, but the basic mechanism is already there. The optimal method: physically set the RTC at the best possible, and then virtually compensate any residual error. > setting system clock > If --noadjfile is given, skip tick synchronization. (max_err += 0.5) The operational reasons for using --noadjfile/--nodrift and for using --fast are completely different. Forcing those 2 features under a single option makes no sense. > Compensate for drift, offset. Just to repeat: obvious excellent idea. > Set adjtimex() tick and freq (optionally). Redundant: adjtimex and ntptime can already do this. OTOH at the level of accuracy currently reached by hwclock, the kernel clock frequency does have an influence on our operations. Marginal influence, but... I always call adjtimex first, then hwclock. Alain. -- 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
