harv%ksuvax1.BITNET@wiscvm.arpa (Harvard Townsend) (09/23/86)
'
harv%ksuvax1.BITNET@wiscvm.arpa (Harvard Townsend) (09/27/86)
It looks like the first attempt for this message was gobbled up somewhere
along the line, so I'll try again. We are having a problem with the
11/780 clock and 4.2BSD setting the data and time when rebooting. Upon
reboot, 4.2BSD comes up with a bogus date and time - it is sometimes
a few hours off, others a few days, and others a few months. The maintenance
folks have replaced the clock module in the VAX, but the symptom persists.
Their suspicion is that it is a 4.2BSD problem (they, of course, know
nothing about UNIX - "If you were running VMS, ...", they say). Has
anyone had this problem before? If so, do you have a fix? Thanks.
(This has been cross-posted to info-vax).
______________________________________
Harvard Townsend, Systems Administrator
Kansas State University, Dept. of Computer Science
Manhattan, KS 66506 (913)532-6350
CSNET: harv@kansas-state -or- harv%kansas-state@csnet-relay.arpa
-or- harv%kansas-state@relay.cs.net
BITNET: harv@ksuvax1.bitnet -or- harv%ksuvax1.bitnet@WISCVM.WISC.EDU
UUCP: ihnp4!ltuxa!ksuvax1!harvron@BRL.ARPA (Ron Natalie) (09/28/86)
This is probably not your problem, but the DEC diagnostics almost always screw up the CLOCK settings. -Ron
chris@umcp-cs.UUCP (Chris Torek) (10/07/86)
In article <4198@brl-smoke.ARPA> harv%ksuvax1.BITNET@wiscvm.arpa (Harvard Townsend) writes: >... We are having a problem with the 11/780 clock and 4.2BSD >setting the dat[e] and time when rebooting. Upon reboot, 4.2BSD >comes up with a bogus date and time - it is sometimes a few hours >off, others a few days, and others a few months. The maintenance >folks have replaced the clock module in the VAX, but the symptom >persists. Where shall I start...? 4BSD has three sources of time information: the 780 Time Of Day Register (TODR); the interval counter; and the root file system. While booting, it reads the file system time stamp and the TODR. It assumes that the file system stamp has the right year (+/- six months), and that the TODR has the extra information needed to pin that down to day and second. It computes this value and compares it with the original file system time. If the times differ by more than two days, it gripes (but believes the time anyway). There are a few miscellaneous sanity checks as well. Whenever you set the date with date(1), the kernel resets the TODR as appropriate. While the machine is running, the time is advanced by the interval counter. The interval timer is set to interrupt every 10 ms. in 4.2 and 4.3BSD; after 100 of these it bumps the seconds counter. It is possible (but unlikely) to keep the machine at a high IPL long enough that it misses a few ticks. In this case the clock will slowly drift backward. From your description, I would say that either the Time Of Year clock is malfunctioning, or the TODR processor register is not accurately reading the TOY clock. Incidentally, when this machine reboots, we set its clock from the Naval Observatory's atomic clock: if [ -f /usr/local/lib/navclock ]; then ( if /usr/local/bin/x set_clock > /dev/null 2>&1; then echo 'Clock Set from Naval Observatory' > /dev/console else echo 'Clock not set. Call 653-1800. ;-)' > /dev/console fi ) & fi `x set_clock' dials 301 653 0351, which is the Observatory's 1200 baud machine readable clock. (This is a local call for us, and thus cheaper than a Heathkit WWV clock.) 301 653 1800 is, of course, their voice number. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
dave@onfcanim.UUCP (Dave Martindale) (10/08/86)
I've seen three different reasons for time being suddenly wrong on a VAX after a boot even when the hardware is all working properly. One is simply clock drift over time. The UNIX time of day is maintained by counting down the main CPU clock, produced by a crystal oscillator. This will drift slowly over time depending on how accurate the oscillator is, but the slow drift isn't going to surprise anyone while the machine is up. However, the time-of-year clock that provides the time at boot is driven by a separate, battery-backed-up crystal oscillator, and nobody tries to keep it in agreement with the CPU's oscillator. Over a period of several months of uptime, the CPU clock may drift in one direction while the time-of-year clock drifts, unnoticed, in the other direction. When you eventually reboot, the system time suddenly changes by several minutes relative to the correct time. (A side note: the PDP-11 clock counted 60Hz line cycles, and so was much more accurate than a VAX over a long period). Two other reasons for the clock changing suddenly are both due to DEC field service. Berkeley UNIX tries to keep the time in the same format that VMS uses for peaceful coexistence on the machine. Unfortunately, VMS uses local time while UNIX uses UTC. If field service boots VMS and it tells them the time of day is off by 5 hours (for EST, other timezones differ appropriately) they are likely to be helpful and reset it. Then when UNIX comes back up, it's time is now 5 hours off. Finally, diagnostics can completely trash the time-of-year clock.
dave@murphy.UUCP (Lerxt) (10/17/86)
In article <3723@umcp-cs.UUCP>, chris@umcp-cs.UUCP (Chris Torek) types: >While the machine is running, the time is advanced by the interval >counter. The interval timer is set to interrupt every 10 ms. in >4.2 and 4.3BSD; after 100 of these it bumps the seconds counter. >It is possible (but unlikely) to keep the machine at a high IPL >long enough that it misses a few ticks. In this case the clock >will slowly drift backward. There's another little gotcha to this technique. One time, we had a CPU board in our 780 that went borderline and had to use the console clock- margining feature (SET CLOCK SLOW) to slow down the CPU clock so that the thing would run until Field Service could track down a replacement board. Unfortunately, the interval timer derives its frequency from the CPU clock, so if you margin the clock, you time of day slows down or speeds up correspondingly. There were a lot of jokes that day about the speed of work approaching c (or is it C?), and work dialation! By the way, the same thing happens with VMS. --- It's been said by many a wise philosopher that when you die and your soul goes to its final resting place, it has to make a connection in Atlanta. Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL UUCP: ...{sun,pur-ee,brl-bmd}!gould!dcornutt or ...!ucf-cs!novavax!houligan!dcornutt ARPA: wait a minute, I've almost got it... "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."