[lkml]   [2006]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/14] RTC: Remove RTC UIP synchronization on x86

> Remove RTC UIP synchronization on x86
> Reading the CMOS clock on x86 and some other arches currently takes up
> to one second because it synchronizes with the CMOS second tick-over.
> This delay shows up at boot time as well a resume time.
> This is the currently the most substantial boot time delay for
> machines that are working towards instant-on capability. Also, a quick
> back of the envelope calculation (.5sec * 2M users * 1 boot a day * 10 years)
> suggests it has cost Linux users in the neighborhood of a million
> man-hours.

Heh, nice manipulation attempt. Note you are also introduced timing
error of about 114 years total.

> In my view, there are basically four cases to consider:
> 1) networked, need precise walltime: use NTP
> 2) networked, don't need precise walltime: use NTP anyway
> 3) not networked, don't need sub-second precision walltime: don't care
> 4) not networked, need sub-second precision walltime:
> get a network or a radio time source because RTC isn't good enough anyway

Eh, very nice, so I should get radio time source for my notebook?

> So this patch series simply removes the synchronization in favor of a
> simple seqlock-like approach using the seconds value.

What about polling RTC from timer interrupt or something like that, so
that you get error in range of 5 msec instead of 500 msec? You can do
the calibration in parallel, then...
Thanks, Sharp!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-03-21 16:15    [W:0.082 / U:1.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site