While many things affect a quartz oscillator in your watch, the secret
to its great time keeping is the fact that when the watch is on your
wrist it is kept at a very stable temperature (~97F). As long as you
wear the watch, the oscillator will remain stable and drift hardly at
all. Put the watch in an environment where there is significant
temperature swings (such as your car) and you will see the accuracy
degrade quickly.

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.

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.

While the accuracy of a timepiece is impressive, what also impresses me
is the extreme low power requirement that allow the circuit to run for
years on almost no power. Part of that is because of the LOW
(microamps) current requirements and the low frequency (~32KHz) of the
oscillator.

Amazing what technology one can buy for a few dollars...we really don't
appreciate the technology that is all around us.

TMT

Too_Many_Tools wrote:

snip

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.

Out of curiosity I downloaded the data sheet for the "Timekeeper RAM"
M48T59Y chip. It is quite a sophisticated device. Frequency accuracy is
better than ~20 ppm between 0 deg. C and 50 deg. C. That equates to a
maximum error of about 50 seconds per month. It also incorporates a
calibration feature through which the clock can be speeded up or slowed
down according to a 5-bit number loaded into a register. This apparently
brings the accuracy to within 2 ppm at 25 deg. C. It's a neat device. I
guess you get what you pay for - you don't find a £20 clock chip on a
£50 motherboard. Whether Sun use the calibration feature on the chip I
don't know. If anyone knows please let me know. I'm curious.

Best wishes,

Chris

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 ---

According to Christopher Tidy :
Too_Many_Tools wrote:

snip

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.

Out of curiosity I downloaded the data sheet for the "Timekeeper RAM"
M48T59Y chip. It is quite a sophisticated device. Frequency accuracy is
better than ~20 ppm between 0 deg. C and 50 deg. C. That equates to a
maximum error of about 50 seconds per month. It also incorporates a
calibration feature through which the clock can be speeded up or slowed
down according to a 5-bit number loaded into a register. This apparently
brings the accuracy to within 2 ppm at 25 deg. C. It's a neat device. I
guess you get what you pay for - you don't find a £20 clock chip on a
£50 motherboard. Whether Sun use the calibration feature on the chip I
don't know. If anyone knows please let me know. I'm curious.

Among the options to the "date" command, which can both read
and display the date, and set it, is:

================================================== ====================
-a [-]sss.fff Slowly adjust the time by sss.fff seconds
(fff represents fractions of a second). This
adjustment can be positive or negative. The
system's clock is sped up or slowed down
until it has drifted by the number of
seconds specified. Only the super-user may
adjust the time.
================================================== ====================

So -- yes, Sun does use the speed control.

This is from the man page to Solaris 10. But the same is in the
man page for "date" for Solaris 2.6 ("Solaris 10" should be "Solaris
2.10", if they had not changed the naming rules somewhere between 2.6
and 2.9. I don't have Solaris 8 (or is it Solaris 2.8?) to check
whether that was where the change was made.

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 ---

DoN. Nichols wrote:
According to Christopher Tidy :

Too_Many_Tools wrote:

snip

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.

Out of curiosity I downloaded the data sheet for the "Timekeeper RAM"
M48T59Y chip. It is quite a sophisticated device. Frequency accuracy is
better than ~20 ppm between 0 deg. C and 50 deg. C. That equates to a
maximum error of about 50 seconds per month. It also incorporates a
calibration feature through which the clock can be speeded up or slowed
down according to a 5-bit number loaded into a register. This apparently
brings the accuracy to within 2 ppm at 25 deg. C. It's a neat device. I
guess you get what you pay for - you don't find a £20 clock chip on a
£50 motherboard. Whether Sun use the calibration feature on the chip I
don't know. If anyone knows please let me know. I'm curious.


Among the options to the "date" command, which can both read
and display the date, and set it, is:

================================================== ====================
-a [-]sss.fff Slowly adjust the time by sss.fff seconds
(fff represents fractions of a second). This
adjustment can be positive or negative. The
system's clock is sped up or slowed down
until it has drifted by the number of
seconds specified. Only the super-user may
adjust the time.
================================================== ====================

So -- yes, Sun does use the speed control.

Ah yes. Thanks Don. I read about this some time ago, but have never
actually used it. Now I wonder if the machine uses the speed control
automatically (this is mentioned in the chip data sheet) to correct
deviations of the clock?

Best wishes,

Chris

According to Christopher Tidy :
DoN. Nichols wrote:

[ ... ]

Among the options to the "date" command, which can both read
and display the date, and set it, is:

[ ... man page extract ... ]

So -- yes, Sun does use the speed control.

Ah yes. Thanks Don. I read about this some time ago, but have never
actually used it. Now I wonder if the machine uses the speed control
automatically (this is mentioned in the chip data sheet) to correct
deviations of the clock?

For that, I would have to have access to the source code of the
kernel. I've got it for OpenBSD, and can easily get it for most other
BSD flavors, as well as for most linux flavors, but I don't have it for
Solaris (though I understand that it is now available for Solaris 10).

But I believe that it is. Take a look at another excerpt --
this time from the "xntpd" daemon used for maintaining system clocks in
synchronization:


================================================== ====================
driftfile filename

Specifies the name of the file used to record the fre-
quency offset of the local clock oscillator. If the file
exists, it is read at startup in order to set the ini-
tial frequency offset. Then the file is updated once per
hour with the current offset computed by the daemon. If
the file does not exist or this command is not given,
the initial frequency offset is assumed to be zero. In
this case, it may take some hours for the frequency to
stabilize and the residual timing errors to subside. The
file contains a single floating point value equal to the
offset in parts-per-million (ppm). The file is updated
by first writing the current drift value into a tem-
porary file and then using rename(2) to replace the old
version. This implies that xntpd must have write permis-
sion for the directory the drift file is located in, and
that file system links, symbolic or otherwise, should
probably be avoided.
================================================== ====================

So -- it would appear that it is tuning the clock chip to track
the master system.

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 ---

Too_Many_Tools wrote:

Amazing what technology one can buy for a few dollars...we really
don't appreciate the technology that is all around us.

Every day I'm thankful for living in the era of flush toilets. I know the
alternative... ;-)

-- Mark

DoN. Nichols wrote:
According to Christopher Tidy :

DoN. Nichols wrote:


[ ... ]


Among the options to the "date" command, which can both read
and display the date, and set it, is:


[ ... man page extract ... ]


So -- yes, Sun does use the speed control.

Ah yes. Thanks Don. I read about this some time ago, but have never
actually used it. Now I wonder if the machine uses the speed control
automatically (this is mentioned in the chip data sheet) to correct
deviations of the clock?


For that, I would have to have access to the source code of the
kernel. I've got it for OpenBSD, and can easily get it for most other
BSD flavors, as well as for most linux flavors, but I don't have it for
Solaris (though I understand that it is now available for Solaris 10).

But I believe that it is. Take a look at another excerpt --
this time from the "xntpd" daemon used for maintaining system clocks in
synchronization:


================================================== ====================
driftfile filename

Specifies the name of the file used to record the fre-
quency offset of the local clock oscillator. If the file
exists, it is read at startup in order to set the ini-
tial frequency offset. Then the file is updated once per
hour with the current offset computed by the daemon. If
the file does not exist or this command is not given,
the initial frequency offset is assumed to be zero. In
this case, it may take some hours for the frequency to
stabilize and the residual timing errors to subside. The
file contains a single floating point value equal to the
offset in parts-per-million (ppm). The file is updated
by first writing the current drift value into a tem-
porary file and then using rename(2) to replace the old
version. This implies that xntpd must have write permis-
sion for the directory the drift file is located in, and
that file system links, symbolic or otherwise, should
probably be avoided.
================================================== ====================

So -- it would appear that it is tuning the clock chip to track
the master system.

Enjoy,
DoN.

Thanks for the interesting information. It does explain, I think, why
Suns keep pretty good time compared to many PCs!

Chris

Christopher Tidy wrote:

DoN. Nichols wrote:

from the "xntpd" daemon used for maintaining system
clocks in synchronization:

+ driftfile filename
+
+ Specifies the name of the file used to record the
+ frequency offset of the local clock oscillator. If the
+ file exists, it is read at startup in order to set the
+ initial frequency offset. Then the file is updated once
+ per hour with the current offset computed by the daemon.

+ The file contains a single floating point value equal
+ to the offset in parts-per-million (ppm).

So -- it would appear that it is tuning the clock chip
to track the master system.

Thanks for the interesting information. It does explain,
I think, why Suns keep pretty good time compared to many PCs!

Many PCs *running Windows*. Those same PCs have the
synchronization scheme described above if they are
running BSD or Linux.

DoN. Nichols wrote:
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.

snip

I'm surprised you think SUN clock hardware is accurate. Though, I
haven't worked on anthing more recent than a Sparc 10. SUN Sparcs
are notorious for having really bad clock hardware. The only way to
keep a Sparc clock accurate is to NTP sync it. BTW, that clock
chip is only read at boot time, the running clock is done somewhere
else.

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.


If you forget your password, you have to replace the chip to get back
into the box. Another way is to use a rom burner to make the chip
checksum bad so the system will use default settings when it comes
up. Most people end up replacing the chip because they don't the
equipment to write to the ROM.

- Mooron