According to Too_Many_Tools :
[ ... ]
This same reason is why computer clocks are off so much...the machine
is on and off enough that the temperature the oscillator see changes
significantly.
That is indeed the problem.
While I have not seen the time keeping circuitry of a SUN station, I
would wager that they had a small oven for the oscillator that kept the
quartz crystal at a stable temperature.
Nope! It is in a 28-pin chip which contains some CMOS RAM, the
clock chip, the crystal, and a 3V cell -- all potted together.
Power comes from the system while it is on, and Sun workstations
normally are kept on 24/7, as they do housekeeping work during the
middle of the night, so the internal temperature is pretty stable.
Only when the computer is off will power be drawn from the
battery, both to run the clock, and to back up the information in the
CMOS RAM, which contains various settings for the system, plus the
ethernet hardware address and the system ID number. Everything but
those last two can be changed from the command line -- either with the
system booted (logged in as root), or with the system at the OpenBoot
PROM level. In case anyone cares, here are the settings from a typical
Ultra-2 (now obsolete):
================================================== ====================
tpe-link-test?=true
scsi-initiator-id=7
keyboard-click?=false
keymap: data not available.
sbus-probe-list=e0123
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
mfg-mode=off
diag-level=max
#power-cycles=85
system-board-serial#: data not available.
system-board-date: data not available.
fcode-debug?=false
output-device=screen
input-device=keyboard
load-base=16384
boot-command=boot
auto-boot?=true
watchdog-reboot?=true
diag-file: data not available.
diag-device=net
boot-file: data not available.
boot-device=/sbus@1f,0/SUNW,fas@e,8800000/sd@0,0:a disk
local-mac-address?=false
ansi-terminal?=true
screen-#columns=80
screen-#rows=34
silent-mode?=false
use-nvramrc?=false
nvramrc: data not available.
security-mode=none
security-password: data not available.
security-#badlogins=0
oem-logo: data not available.
oem-logo?=false
oem-banner: data not available.
oem-banner?=false
hardware-revision: data not available.
last-hardware-update: data not available.
diag-switch?=false
================================================== ====================
Note that the text strings which label the settings are not
stored in there -- they are provided by either the OpenBoot PROM, or the
EEPROM program on the booted system. And most of the values are stored
in single bytes, except the complex strings like "boot-device=". The
"whatever?" ones contain true or false values. The ones like
"screen-#columns" contain a single byte of data (0-255). If
"security-mode?" is set to other than false, security-password is stored
in an area, but is *never* displayed. And the "security-#badlogins"
keeps count of attempts to boot the system without the password. The
"security-mode?" can be "none", "command" or "full". With it in
"command" mode, the system can be booted normally, but any attempt to
boot it from tape, CD-ROM, net, or floppy will require a password, as
will any attempt to change any of the stored values.
Since this is in a home, and I'm not handling secure
information, there is no point to setting the security mode to other
than "none".
And -- there is no jumper to allow it to forget the settings,
unlike with a normal PC.
Enjoy,
DoN.
--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. |
http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---