Hello Ondrej, On Tuesday, September 11, 2007 at 14:50:54 +0200, Ondrej Certik wrote:
> HWCLOCKPARS="--directisa" > How about using this by default so that I don't have to make this > change manually? The --directisa RTC access method has some drawbacks: - It wastes processor cycles by busy-waiting for the clock tick, instead of sleep-waiting for the update ended interrupt. - It is in practice much less accurate in detecting this clock tick, as soon as the system is not purely idle. Busywaiting for a 2 milliseconds event, when at HZ=100 several timeslices of 10 ms can be preempted by other processes, well... this can happen to fail completely ;-). Note that Bryan Henderson's latest hwclock 2.30 uses memory locking and realtime priority to minimize this problem. - It can be used by root only. And it is "dirty" (!), because clean applications are expected to never access the hardware directly, but thru a device driver. So people using normal hardware and good kernels with proper RTC interrupts don't want to use --directisa. Setting it by default would work everywhere, but with degraded functionality for the majority. It would be a pity. I'm not sure what can be done. Perhaps: - Make HWCLOCKPARS="--directisa" option easyier to find and setup. Propose it during installation. Set it inside a simple config file, sourced from /etc/init.d/hwclock.sh. See David's bug report #439593. - Enhance detection of interrupt failures, and enhance automatic fallback methods to detect tick in code. Today only few failure scenarios are detected, some are detected too late, and the fallback method (busywait for change of time) seems to be much less accurate than with --directisa itself (busywait for UIP fall). Testing this fallback method gave me the tick detected between 8 and 20 ms late, when normal methods stay in a 10 µs range... That's only 2000 times worse. - Check interrupt failure during installation script, and then install with --directisa option. But those are only random ideas: I can't test nor discuss this seriously, because none of my machines have interrupt problems. However I think we should not just fail, or poorly fallback. We should not require the impacted users to notice, understand, and fix the problem. Instead, we should detect and fix it ourselves. If not at runtime, then at install. Alain.
