OpenServer 5 Clock Slippage
Karim Kamara
problem in that the system clock keeps losing time, some times up to 20
minutes per hour.
Any suggestions welcome.
Karim Kamara
r.z...@strhold.it
Hi.
As far as I know, OpenServer tries to get the kernel clock (software) in
sync with the RTC (hardware) every minute; if the "difference" is greater
than 2 secs, the software clock (whose "resolution" is set by the HZ env
variable) gets adjusted as reported by the RTC.
You could have a defective/bad RTC; have a look at the output of
cat /dev/rtc
and compare it to what it's returned by an external source (eg, a stopwatch
of your wrist watch). If the clock skew (sp?) turns out to be a significant
value, then you'd better check your HW.
Hope this helps !
Best,
Roberto
--
---------------------------------------------------------------------
Roberto Zini email : r.z...@strhold.it
Technical Support Manager -- Strhold Evolution Division R.E. (ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)
Bill Vermillion
>> We are running Informix 7.2 on SCO Openserver 5.0.4. We have a strange
>> problem in that the system clock keeps losing time, some times up to 20
>> minutes per hour.
>> Any suggestions welcome.
>As far as I know, OpenServer tries to get the kernel clock
>(software) in sync with the RTC (hardware) every minute; if the
>"difference" is greater than 2 secs, the software clock (whose
>"resolution" is set by the HZ env variable) gets adjusted as
>reported by the RTC.
>You could have a defective/bad RTC; have a look at the output of
> cat /dev/rtc
>and compare it to what it's returned by an external source (eg,
>a stopwatch of your wrist watch). If the clock skew (sp?) turns
>out to be a significant value, then you'd better check your HW.
In that case why not just take the setclk out of the crontab
and run a time daemon from some other source. Given the state of
many RTCs' that will give you more reliability.
Many things use the HZ variable - and it's pretty much HW dependant
so you'd not want to screw around with that.
As to the resolution the standard flag to setclk in the crontab
file is -rd1800 - which says don't reset the time if it is off by
over 30 minutes. And if you clock is slippery you probably just
want to set it to the net.
I use the closest upstream router that will let me - usually your
ISP will - as you dont need the microsecond resolution returned by
the higher up systems in most instances.
Bill
--
Bill Vermillion - bv @ wjv . com
Karim Kamara
Thanks for the help. I monitored the /dev/rtc device and found that it keeps
time perfectly but the Operating System clock still seems to lose time. Do
you know what process/daemon synchronises the OS with the time reported by
/dev/rtc?
Regards,
Karim Kamara
Umm Al-Jawaby Oil Service Company Limited
Email.: kka...@jawaby.co.uk
<r.z...@strhold.it> wrote in message news:3CC00483...@strhold.it...
Bill Vermillion
>Thanks for the help. I monitored the /dev/rtc device and found
>that it keeps time perfectly but the Operating System clock
>still seems to lose time. Do you know what process/daemon
>synchronises the OS with the time reported by /dev/rtc?
Perhaps you have some processes that are causing this to happen.
Clocks have been know to lose time when certain thinkgs stop
interupts - while they need to do something that can't be
interupted.
r.z...@strhold.it
>
> "Kamara, Karim" wrote (in a private message):
>
> # crontab -l |grep setclk
> 1 3 * * * /etc/setclk -rd1800 > /dev/null 2>&1
>
> # echo $HZ
> 100
>
> # setclk -vp
> RTC 02/04/29 16:08:11 DST
> SYS 02/04/29 15:59:52 DST RTC-SYS=499
>
> Is this what you would expect?
>
Yes, it is.
I've just checked against a system of ours here which got installed with
SCO OpenServer 5.0.5 and the main settings are the same, except for the
"setclk -vp" output which shows that both clocks are "in synch".
The $HZ variable tells you the number of clock interrupts per second and
it's got the correct value (100).
The "in kernel" clock is a "software" clock whereas the RTC is a hardware
one; since the software clock is driven by software by means of $HZ interrupts,
it's __likely__ that your system manages to miss some interrupts, perhaps
due to heavy activity. As far as I know, some device drivers are able to
protect critical pieces of code by "masking" (ie, disabling) interrupt so
that they can execute without the risk of being "pre-empted" by the kernel.
If your device driver is poorly written or the system is extremely busy/loaded,
the software clock goes our of sync and this is the reason for setclk to be
executed via cron.
Assuming the RTC reports back the correct time, what if you change the
crontab file which executes setclk as to have it executed on a more
frequently basis (eg, once per minute) ? I know, this is not the solution
you'd have expected (it's only a workaround) but give it a run.
John DuBois
>The "in kernel" clock is a "software" clock whereas the RTC is a hardware
>one; since the software clock is driven by software by means of $HZ interrupts,
>it's __likely__ that your system manages to miss some interrupts, perhaps
>due to heavy activity. As far as I know, some device drivers are able to
>protect critical pieces of code by "masking" (ie, disabling) interrupt so
>that they can execute without the risk of being "pre-empted" by the kernel.
>
>If your device driver is poorly written or the system is extremely busy/loaded,
>the software clock goes our of sync and this is the reason for setclk to be
>executed via cron.
Note that this is no longer true as of 5.0.6a - on machines that have a TSC
(which showed up in the Pentium II or thereabouts), the kernel clock uses the
TSC for timekeeping and so will not slip due to interrupt masking. This also
allows for greater precision in timekeeping.
John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
Bela Lubkin
Actually the TSC first showed up in some oddball late models of 80486,
but the control register bit that _tells_ an OS that it's present
doesn't appear until the Pentium, so OSR5 doesn't attempt to use any
early half-baked TSCs. All Pentia and most clone processors with
aspirations to "5" or higher have working TSCs.
>Bela<