Hello Karel, On Thursday, August 7, 2008 at 12:50:54 +0200, Karel Zak wrote: > I have tried to play with nanosleep() and it's possible minimize the > busy wait. See the experimental patch below Problem. The delay loop randomly does one of three things: -1) Sleep, wake before target time, busywait a little complement, exit in perfect time. All is well. -2) Don't sleep. Busywait all the time, during around half a second. -3) Sleep, wake too late by several milliseconds, resync, and then busywait during an whole second. The overshoot in sleeping was expectable. The theory may well say one timeslice max, but practice doesn't agree. Experiments show that a margin of 22 milliseconds seems necessary to be safe on most platforms. > Maybe we need something like > foo = set_hardware_clock_prepare() > do > .... > while (newhwtime == sethwtime + (int) (tdiff + 0.5)) > set_hardware_clock(newhwtime, universal, testing, foo) Probably insuficient. Between the loop and RTC_SET_TIME, it's a time critical path. Any single instruction left there is an instruction too much. Optimally the loop should be at the closest, inside of set_hardware_clock_rtc(). And for --directisa inside of cmos_set_time(), just before the restart of the oscillator (but outside of atomic()). Granted, this will surely make resync and re-prepare much less simple. OTOH in case of resync, we probably gain one whole second to do the job in time. Note hwclock 2.33 doesn't allow for a resync. Instead, it chooses the target minimum 100 ms in the future. Preparation takes (much) less than 100 ms even on the slowest machine. The delay loop then has to wait between 0.1 and 1.1 seconds. And RTC_SET_TIME is called *immediatly*, at the microsecond. Overshoots don't normally happen. But the accidental overshoot does a warning, not a resync. Kalev's absolut shortest delay with resync approach seems potentially nicer. But it has to deal with the re-prepare problem. 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
