Bonjour :-)
Serge Bets wrote:
> Spoon wrote:
>
>> systohw reads the current system time, then sleeps until the next
>> whole second, then writes that date to the RTC.
>
> Not good: systohw should sleep until a second and a half, then write the
> (old) plain second to the RTC. Half a second later, the RTC will update
> to the next second, and start ticking at 1 Hz.
>
> Not exactly half a second: The first tick (UIP fall and interrupt) comes
> roughly 502 milliseconds after oscillator restart,
Could you provide a reference discussing this ~500 ms reset latency?
Would it be in the data sheet for my south bridge?
(Is this in fact where the RTC is implemented these days?)
> which is the last step of ioctl(RTC_SET_TIME) operations.
In the rtc.c driver source code, I see:
case RTC_SET_TIME:
{
...
save_control = CMOS_READ(RTC_CONTROL);
CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
preempt_disable();
CMOS_WRITE(yrs, RTC_YEAR);
CMOS_WRITE(mon, RTC_MONTH);
CMOS_WRITE(day, RTC_DAY_OF_MONTH);
CMOS_WRITE(hrs, RTC_HOURS);
CMOS_WRITE(min, RTC_MINUTES);
CMOS_WRITE(sec, RTC_SECONDS);
preempt_enable();
CMOS_WRITE(save_control, RTC_CONTROL);
CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
spin_unlock_irq(&rtc_lock);
return 0;
}
Does the RTC reset when I write RTC_FREQ_SELECT?
> The exact delay depends on the
> machine, is of course affected by the usual drift during half a second
> (typically up to some tens of microseconds), and is additionally
> affected by some quite important dispersion (typical range of a few
> hundreds of µs). The exact width of this dispersion range also depends
> on the machine.
>
> Note that the error and dispersion when *reading* the RTC is way lower
> than when writing. This permits an interesting feedback scheme, where
> you measure the error just after writing, and negate it when later
> reading. This scheme is implemented in the latest hwclock 2.30 from
> Bryan Henderson, and gives incredibly good results. Like writing then
> reading the time with a mean offset of 0 µs +-10.
>
> For comparison the older hwclock from util-linux-ng 2.13 gave results
> like mean offset -2500 µs +-170. And the ugly eleven minutes mode in
> a synced kernel gives a mean offset of -2150 µs +-5000 (!!).
I noticed the 500-ms error when I used util-linux-2.12q hwclock
(which I thought at the time was the latest version).
http://www.kernel.org/pub/linux/utils/util-linux/
STEP 1: Synchronize system clock within 50 ms
# ntpdate -bv 145.238.110.68
26 Sep 13:38:41 ntpdate[875]: ntpdate [EMAIL PROTECTED] Fri Mar 16 10:45:44
UTC 2007 (1)
26 Sep 13:38:41 ntpdate[875]: step time server 145.238.110.68 offset
0.000146 sec
STEP 2: Write the system time to the RTC
# hwclock --debug --utc --noadjfile --systohc
hwclock from util-linux-2.12q
Using /dev/rtc interface to clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2007/09/26 13:38:45
Hw clock time : 2007/09/26 13:38:45 = 1190813925 seconds since 1969
Time elapsed since reference time has been 0.502395 seconds.
Delaying further to reach the next full second.
Setting Hardware Clock to 13:38:45 = 1190813925 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Not adjusting drift factor because it has been less than a day since the
last calibration.
STEP 3: Set the system time from the RTC
# hwclock --debug --utc --noadjfile --hctosys
hwclock from util-linux-2.12q
Using /dev/rtc interface to clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2007/09/26 13:38:56
Hw clock time : 2007/09/26 13:38:56 = 1190813936 seconds since 1969
Calling settimeofday:
tv.tv_sec = 1190813936, tv.tv_usec = 0
tz.tz_minuteswest = 0
STEP 4: Check to see if the system time is correct
# ntpdate -bv 145.238.110.68
26 Sep 13:39:04 ntpdate[878]: ntpdate [EMAIL PROTECTED] Fri Mar 16 10:45:44
UTC 2007 (1)
26 Sep 13:39:04 ntpdate[878]: step time server 145.238.110.68 offset
-0.497497 sec
There's the ~500 ms error right there.
IIUC this is a bug in the util-linux-2.12q hwclock?
I will give BJH's 2.30 version a try immediately.
>> it seems like the RTC raises the IRQ when the fraction of a second is
>> 0.5, not when it is 0.
>
> Near end of each second the RTC raises UIP, begins updating its
> registers, and roughly 2 ms later the update ends: UIP is negated, and
> the interrupt is triggered. This marks the beginning of the new RTC
> second.
Thanks for the explanation.
>> systohw reads the current system time = 1190736224.657174984 then
>> sleeps until 1190736225 (it wakes up at 1190736225.000003988)
>
> Nearly 4 µs of retard: not so good. Better wake earlier, and busywait
> for the right time.
I understand your point.
I'm not quite sure you can use "retard" in this context in English ;-)
Cordialement.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
