since /dev/rtc is verified working and since i am not running timesync at all,
it seems to me that the problem must be in the kernel and sleep (thus the
kernel's fastticks) must be running too fast.
in 60s sleep (same pace as date output), the rtc advances only 32 or 33sec
(6:44-6:11, 09:06-08:34, 09:51-09:19).
doing things the other way gives 60 rtc sec = 110 system sec.
; fn rtcmin { s = `{cat /dev/rtc} ; end = `{echo $s + 60 | hoc} ; while (! ~
`{cat /dev/rtc} $end) usleep 4}
; date ; rtcmin ; date
Mon Aug 7 20:33:25 CDT 2006
Mon Aug 7 20:35:15 CDT 2006
- erik
On Mon Aug 7 19:43:27 CDT 2006, [EMAIL PROTECTED] wrote:
> On Mon, Aug 07, 2006 at 07:12:41PM -0500, erik quanstrom wrote:
> >; cat /dev/rtc > /dev/time ; sleep 60 ; date ; date `{cat /dev/rtc}
> >Mon Aug 7 19:07:11 CDT 2006
> >Mon Aug 7 19:06:44 CDT 2006
> >; ; cat /dev/rtc > /dev/time ; sleep 60 ; date ; date `{cat /dev/rtc}
> >Mon Aug 7 19:09:34 CDT 2006
> >Mon Aug 7 19:09:06 CDT 2006
> >; ; ; cat /dev/rtc > /dev/time ; sleep 60 ; date ; date `{cat /dev/rtc}
> >Mon Aug 7 19:10:19 CDT 2006
> >Mon Aug 7 19:09:51 CDT 2006
>
> That output isn't very useful. This would be more useful:
> fn dates { date; date `{cat /dev/rtc} }
> dates; cat /dev/rtc>/dev/time; dates; sleep 60; dates; sleep 60; dates
>
> I suspect that the issue is that your clock is being synchronized to an ntp
> server which has a different time from your real time clock.
>
> --
> Kris Maglione
>
> If it would be cheaper to buy a new unit, the company
> will insist upon repairing the old one.
