Re: [RFC][PATCH] new timeofday i386 hooks (v.A0)

[George Anzinger <george@mvista.com>]

Ulrich Windl wrote:
> On 2 Sep 2004 at 18:44, George Anzinger wrote:
> 
> 
~

>>>+#endif
>>> 
>>>+void sync_persistant_clock(struct timespec ts)
>>>+{
>>>+	/*
>>>+	 * If we have an externally synchronized Linux clock, then update
>>>+	 * CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
>>>+	 * called as close as possible to 500 ms before the new second starts.
>>>+	 */
>>>+	if (ts.tv_sec > last_rtc_update + 660 &&
>>>+	    (ts.tv_nsec / 1000)
>>>+			>= USEC_AFTER - ((unsigned) TICK_SIZE) / 2 &&
>>>+	    (ts.tv_nsec / 1000)
>>>+			<= USEC_BEFORE + ((unsigned) TICK_SIZE) / 2) {
>>>+		/* horrible...FIXME */
>>>+		if (efi_enabled) {
>>>+	 		if (efi_set_rtc_mmss(ts.tv_sec) == 0)
>>>+				last_rtc_update = ts.tv_sec;
>>>+			else
>>>+				last_rtc_update = ts.tv_sec - 600;
>>>+		} else if (set_rtc_mmss(ts.tv_sec) == 0)
>>>+			last_rtc_update = ts.tv_sec;
>>>+		else
>>>+			last_rtc_update = ts.tv_sec - 600; /* do it again in 60 s */
>>>+	}
>>>+
>>
>>I have wondered, and continue to do so, why this is not a timer driven function. 
> 
> 
> I think it depends on how reliable timers are regarding in-time triggering. This 
> code has to be executed on-time to make sense. Really.

Granted, but if we are late we can easily skip to the next second.  The 60s 
thing is rather arbitrary.  If we are always late, well, there are lots of user 
aps that rely on timers being on time most of the time. So we need to get that 
right.

-g
> 
> 
>>  It just seems silly to check this every interrupt when we have low overhead 
>>timers for just this sort of thing.
>>
>>I wonder about the load calc in the same way...
> 
> 
> That's completely different.
> 
> ...
> 
> Regards,
> Ulrich
> 
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml