On Fri, Sep 07, 2007 at 04:20:12AM +1000, Paul Mackerras wrote: > Gabriel Paubert writes: > > > On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote: > > > This changes PowerPC to use the generic time infrastructure for > > > gettimeofday et al. We register a clocksource which uses the timebase > > > register, or the RTC on the 601. > > > > > > It also gets rid of the RTC update stuff. IIRC we discussed removing > > > this some time ago but never actually did it. > > > > So who will be in charge of updating the RTC now? The update > > every 11 min is there to stay on x86(-64) it seems. > > I had an impression that ntpd would do it, but that seems to be wrong. > > I also have been unable to find where in the kernel source there is > code for x86[-64] to do the RTC updates. Do you know where it is?
It goes through CONFIG_CMOS_UPDATE, which is set to Y by default on i386/x86-64/sparc64. > > Doing the updates from timer_interrupt will no longer really be > suitable since it is not called at regular intervals any more. The > best thing would be for the ntp code to set up a timer when it reaches > synchronization. This is what CONFIG_CMOS_UPDATE does through the sync_cmos_timer variable. > > > Removing this will have strange side effects: as an example, > > your laptop clock will be good if it synchronized on NTP, > > then you put it to sleep, disconnect the network and RTC read > > on wake up returns a wrong value, giving wrong timestamps. > > No, the suspend/resume code reads the RTC on both suspend and resume, > and advances xtime by the difference between the two readings. So the > time might be out by up to a second after resume, but it shouldn't be > way off, assuming that your RTC is advancing at the right speed. Ok, I did not know this. Well, my PreP boards never sleep (not worth when doing real time data acquisition at 100-200 Hz interrupt rate) but I rely on ntp and a fairly precise time setup at boot in some cases. Actually I have slightly modified my kernels: I loop waiting for the second boundary to set the time and also use one full second of the RTC to calibrate the timebase, even that has its own issues since I cannot use the last and first second of every minute because of RTC vagaries: http://www.st.com/stonline/products/literature/an/5228.pdf and that does not describe also the calibration which shortens or lengthens also specific seconds but I can afford to systematically set the calibration factor to 0: http://www.st.com/stonline/products/literature/an/6393.pdf This is the only way I found to have reproducible timebase measurements on these machines; it means that it takes up to 3 seconds to calibrate the timebase at boot, but it's better than to have ntp error rate starting to depend on the phase of the moon (this was my impression when I first found the problem :-)), or more precisely on which second in the minute the timebase calibration is performed. > > > As someone who has a network of tens of machines using > > NTP for synchornisation I think it is a very bad idea > > unless we have a replacement. > > OK, but I think that doing it in timer_interrupt is the wrong place. Indeed, but please bring up something using the CONFIG_CMOS_UPDATE infrastructure. I'm aware that some RTC have awfully slow accesses (the more recent, the longest the latency it seems), but it is always possible to disable it through the no_sync_cmos_clock variable. Default it to 1 if you want, after all it should not be the job of the kernel if you have an hypervisor too, I don't care as long as you give me the possibility of enabling automatic RTC updates. Regards, Gabriel _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
