Very Computer

Hi and thanks to all who read and respond.

I have an SCO 5.0.2 system running on an ALR Revolution ST. (300 mhz
Pentium II)
The time changes, moves a head rapidly.  So fast in fact that the
midnight backup starts at 3:00pm.  I have reset the date using date, but
the next day when I login the time is all wrong.  In addition, someone
on site has been changing the date with asktime and now if you get both
date and asktime to report the same time then wait and login later the
system reports two different times.  The systems has not been shutdown
or rebooted.

The hardware mfr says to replace the CMOS battery.  Can this be true
that on a powered up system a low battery can cause the clock to keep
bad time?

Any tips, explanations or  leads are appreciated.

TIA,

Ben Rosenthal
Retail/Optical Point of Sale Systems

Ben,

When I worked at SCO, I had this same problem with
a 5.0.0 and 5.0.2 system.  I was running a Dell
Optiplex DGX dual P133 system.

I always had time problems, and reported it (informally)
to a few of the engineers...  Nobody believed me.  That's
the EXACT issue I saw.  Time would "race ahead" rapidly.
I could do a "date" and show the time, then 1 hour
later, do a "date" again, and time would show 16 hours
ahead of the last "date" I executed.

I replaced the CMOS battery twice, and still had the
problems.

I found that if I was running Network Time Protocol
(xntpd), this happened all of the "time".  I turned off
xntpd, and just ran off the local battery and things
seemed okay.  I was pointing my xntpd stuff at an
OpenServer 5.0.0 host, which got it's time off our
core Cisco router, which in turn got it's time off
2 of the Stratum 1 servers.

You should turn off xntpd; if you're running it, then
reboot the system.  When asked, supply the correct time.

v/r
Shane

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

               Monterey Bay Aquarium Research Institute

         "We need to understand that man belongs to Earth;
                and not that Earth belongs to man."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Quote:>Hi and thanks to all who read and respond.
>I have an SCO 5.0.2 system running on an ALR Revolution ST. (300
>mhz Pentium II) The time changes, moves a head rapidly. So fast
>in fact that the midnight backup starts at 3:00pm. I have reset
>the date using date, but the next day when I login the time is all
>wrong. In addition, someone on site has been changing the date with
>asktime and now if you get both date and asktime to report the same
>time then wait and login later the system reports two different
>times. The systems has not been shutdown or rebooted.

Are you certain that no one has diddled with the HZ value.  I've
seen people think this has to AC power cycles and chip speed.

Have you tried changing the routine in crontab NOT to write the
data to the CMOS clock.  Then you can check on it - to see if
it will be in an acceptable range - and just read it every so
often.

Also build a script that sets the CMOS ONLY when you run that
script and use it for discrepancy checking.  This way you can set
the date and the CMOS at the same time.   I've seen some CMOS
clocks that are accurate to about 1 minute day.  Others have
their own concept of what time is really like.

--

Ben,

OpenServer 5 systems maintains its time in the System Clock.
The System Clock is read from the CMOS RTC at boot time
(see /etc/bcheckrc).

There is a cron job that writes the System clock to the RTC
at 3:01am each day. The function of this job is to ensure that
the RTC (localtime) is updated on the switch to/from DST.

There is also a kernel function (fixtimed) that checks the
difference between the System Clock and the RTC once a minute
and if the difference between the two is more than 2 seconds
it drifts the system clock to the value of the RTC.

You can turn off this tracking by setting track_rtc to 0
in /etc/conf/pack.d/kernel/space.c, relinking the kernel
and then rebooting your system.

This will allow you to determine if the RTC is at fault

John

Quote:

> Hi and thanks to all who read and respond.

> I have an SCO 5.0.2 system running on an ALR Revolution ST. (300 mhz
> Pentium II)
> The time changes, moves a head rapidly.  So fast in fact that the
> midnight backup starts at 3:00pm.  I have reset the date using date, but
> the next day when I login the time is all wrong.  In addition, someone
> on site has been changing the date with asktime and now if you get both
> date and asktime to report the same time then wait and login later the
> system reports two different times.  The systems has not been shutdown
> or rebooted.

> The hardware mfr says to replace the CMOS battery.  Can this be true
> that on a powered up system a low battery can cause the clock to keep
> bad time?

> Any tips, explanations or  leads are appreciated.

> TIA,

> Ben Rosenthal
> Retail/Optical Point of Sale Systems

John Boland typed (on 20Oct):
|
| There is also a kernel function (fixtimed) that checks the
| difference between the System Clock and the RTC once a minute
| and if the difference between the two is more than 2 seconds
| it drifts the system clock to the value of the RTC.
|
| You can turn off this tracking by setting track_rtc to 0
| in /etc/conf/pack.d/kernel/space.c, relinking the kernel
| and then rebooting your system.

Hmm. I never knew that.  Is it mentioned in any man page or manual?

Shouldn't I want to turn off this tracking since I'm getting ntp
time once a day from my ISP?

--

Oh swell.  That explains some really strange things I've seen trying to
impliment a GPS based (NEMA-183) clock.

The following script should detect and divergence between the RTC and
the system clock.  Improvements (or total re-writes) are welcome.

:


#
clear
while :
do
  echo "        Month Day Hr Min Sec Year"
  echo "From CMOS clk: \c"
  bleh=`/etc/cmos 8 | cut -d" " -f2; /etc/cmos 7 | cut -d" " -f2; \
  /etc/cmos 4 | cut -d" " -f2; /etc/cmos 2 | cut -d" " -f2; \
  /etc/cmos 0 | cut -d" " -f2; /etc/cmos 9 | cut -d" " -f2`
  echo $bleh
  echo "Software Time: \c"
  date '+%m %d %H %M %S %y'
  echo "Hardware Time: \c"
  cat /dev/clock
  echo "\n"
  sleep 5
  clear
done

--
Jeff Liebermann  150 Felker St #D  Santa Cruz CA 95060
(831)699-0483 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl   WB6SSY

Jeff Liebermann typed (on 21Oct):

|
| >There is also a kernel function (fixtimed) that checks the
| >difference between the System Clock and the RTC once a minute
| >and if the difference between the two is more than 2 seconds
| >it drifts the system clock to the value of the RTC.
| >
| >You can turn off this tracking by setting track_rtc to 0
| >in /etc/conf/pack.d/kernel/space.c, relinking the kernel
| >and then rebooting your system.
|
| Oh swell.  That explains some really strange things I've seen trying to
| impliment a GPS based (NEMA-183) clock.
|
| The following script should detect and divergence between the RTC and
| the system clock.  Improvements (or total re-writes) are welcome.
|
|
| :


| #
| clear
| while :
| do
|   echo "        Month Day Hr Min Sec Year"
|   echo "From CMOS clk: \c"
|   bleh=`/etc/cmos 8 | cut -d" " -f2; /etc/cmos 7 | cut -d" " -f2; \
|   /etc/cmos 4 | cut -d" " -f2; /etc/cmos 2 | cut -d" " -f2; \
|   /etc/cmos 0 | cut -d" " -f2; /etc/cmos 9 | cut -d" " -f2`
|   echo $bleh
|   echo "Software Time: \c"
|   date '+%m %d %H %M %S %y'
|   echo "Hardware Time: \c"
|   cat /dev/clock
|   echo "\n"
|   sleep 5
|   clear
| done

If you're trying to cut (pun intended) things finely, you shouldn't call
cmos six times, since the values could change during those calls:

cmos | mawk '
/^0 /   {S=$2}
/^2 /   {M=$2}
/^4 /   {H=$2}
/^7 /   {d=$2}
/^8 /   {m=$2}
/^9 /   {y=$2}
END     {printf "/etc/cmos: %2d %2d %2d %2d %2d %2d\n", m, d, H, M, S, y}
'
date '+/bin/date: %m %d %H %M %S %y'
echo "dev/clock: `cat /dev/clock`"

--

Jean-Pierre Radley typed (on 21Oct):
|
| cmos | mawk '
| /^0 / {S=$2}
| /^2 / {M=$2}
| /^4 / {H=$2}
| /^7 / {d=$2}
| /^8 / {m=$2}
| /^9 / {y=$2}
| END   {printf "/etc/cmos: %2d %2d %2d %2d %2d %2d\n", m, d, H, M, S, y}
| '
| date '+/bin/date: %m %d %H %M %S %y'
| echo "dev/clock: `cat /dev/clock`"
|

 Revised:

#!/bin/sh
cmos | mawk '
/^0 /   {S=$2}
/^2 /   {M=$2}
/^4 /   {H=$2}
/^7 /   {d=$2}
/^8 /   {m=$2}
/^9 /   {y=$2}
END     {printf " /etc/cmos: %02d %02d %02d %02d %02d %02d\n",m,d,H,M,S,y}
'
echo "/dev/clock: `cat /dev/clock |sed '
s-\(..\)\(..\)\(..\)\(..\)\(..\)-\1 \2 \3 \4    \5-
'`"
date '+ /bin/date: %m %d %H %M %S %y'

--

SCOForum

I'm curious as well as I'm looking into synchronizing all of our servers
with NTP (exact time is very important for our work).  Presumably I want to
turn off this setting as well as have something to set the RTC clock to the
system clock at shutdown?

---------------------------------------------------------------------------

BVT Associates, 250 Arapahoe Avenue, Boulder, CO 80302

Whoops - had lost the start of the thread where this applies to OSR 5, I'm
using UW7 but am still curious.

See tickadj(ADMN), specifically the -s option.  5.0.5 now
includes this when starting xntpd.

-----

Quote:>Ben,
>OpenServer 5 systems maintains its time in the System Clock.
>The System Clock is read from the CMOS RTC at boot time
>(see /etc/bcheckrc).
>There is a cron job that writes the System clock to the RTC
>at 3:01am each day. The function of this job is to ensure that
>the RTC (localtime) is updated on the switch to/from DST.

The OS does a good job of handling the switch.  I try to keep the
varioius flavored Unix systems I work with all running
with UCT (The timezone previously known as GMT).

Quote:>There is also a kernel function (fixtimed) that checks the
>difference between the System Clock and the RTC once a minute
>and if the difference between the two is more than 2 seconds
>it drifts the system clock to the value of the RTC.

This is in addition to the things done in cron?  

I've noted in the past that some Unix systems appear to keep time
more reliably than some system's real time clocks.  

The only really good real-time clocks I've noted appear in high-end
routing products.

--

Bill Vermillion typed (on 24Oct):

|
| The OS does a good job of handling the switch.  I try to keep the
| varioius flavored Unix systems I work with all running
| with UCT (The timezone previously known as GMT).

It's UTC, not UCT...

--

I've seen it both way.  With the proper French acronym, and the
anglicized acronym.  I alway thought the French way of describing
attributes with the major item first and details after made more
sense than the English way with the attributes first and then
subject of those attributes being last.

Universal Co-oridinated Time fits with the typical English useage.

The CCITT is another acronym that gets mangled into a different
form when use in discussion.

Do you think that if the GMT had been in the standard French
notational format it would have been TGM ?

Bill
--

UTC is not a French acronym (afaik) but an English one: Universal
Time/Corrected or Universal Time/Coordinated. Corrected in the sense
that it's being kept close to UT1 by adding or substracting leap-seconds.
UT1 is a timescale based on astronomical observations, corrected for
fluctuations in earth rotation.
See http://www.apparent-wind.com/gmt-explained.html

--

                                             | web:        www.echelon.nl
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax:   +31 (0)53 43 36 222