Hello Serge, > I guess this problem is due to the reset of the RTC oscillator, right?
Correct. > This holds the clock for up to a second, producing no more update nor > alarm interrupts. But the oscillator still oscillates, so periodic > interrupts should be undisturbed, during and after this procedure. > Interrupts have to be enabled during step #4 of course. I am not sure what you mean -- according to the datasheet there is no way to prevent the update from being scheduled exactly 500ms after 010 (the pattern that enables normal operation of the RTC) has been written to the divider configuration bits of Register A and the periodic interrupt is synchronised to that as far as I know. The only other patterns that do not reset the oscillator are 110 and 111, but they still do reset the countdown chain. This is at least with the Dallas DS1287A chip used on the affected platforms. Besides it would be harmful if the timer tick was held off for a second as it is used for process scheduling (and some networking stuff too). > I'm not aware of any tool using this method. What are those PIE-timer > platforms? Do you have one? A number of DEC platforms have the RTC chip as their lone source of periodic interrupts available. They include systems based on the VAX, MIPS and Alpha processors and I have a number of them (and try to support under Linux, time permitting). FYI, I had a look at NTP statistics a while ago when I worked on adding HPT support for some of these platforms that provide a high-resolution free-running counter in the chipset and it turned out these Dallas chips (as well as the piece of chipset in question), if left undisturbed by the 11-minute update, have a pretty darn good precise oscillator. I do not remember the exact numbers anymore, but I was quite astonished by the low value of dispersion reached. Maciej _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
