This document is intended help Guru administrators to understand the importance of maintaining correct time on Cassini Testers, Guru Servers and Virtual Workstations. If there are symptoms, this helps identify the affected objects and implement corrective actions. In very specific scenario's the CreationID and CreationDate attributes may differ.
Definitions:
ri.sys.CreationID - (aka "CID") Generated by combining the Guru ID with a timestamp based on Guru Time. When sorted alphabetically, creation ID is also in chronological order. This is the global unique ID used by Guru to retrieve and process objects.
ri.sys.CreationDate - standard ISO 8601 string representation of the local system time in YYYY-MM-DD-HH-MM-SS.0000. Guru time is never used to generate the creation date string.
local system clock - Time is maintained in the OS and is displayed in local time (not GMT). The OS should be configured to connect to a network time provider (ntp protocol) on the LAN that would update the system clock at startup periodically (defaults to every 720 minutes). See
Clock Synchronization Settings.Guru Time - The date and time used to generate the Creation ID.
To prevent time related issues, Guru will update the internal time it uses based on the time the Guru Server reports. When a Guru client connects to Guru Server (in UTC) via an update connection, the client will use the server's UTC time to set the local guru time until the local guru is restarted. Guru Time is only updated once, when the connection is made. It increments based on the local system clock. If a guru connection is never made, the system clock is used. If the local time and Guru time differ, the CreationID will not use the same time as the CreationDate, potentially causing issues later.
Symptom: Guru will not start.
Solution: Update to the latest Guru verison. Since Guru Server v74.28, this issue can be identified at corrected at startup.
Symptom: System Clock is in the past after EPC Restart.
Solution: Replace the CMOS battery. Create a schedule to replace the EPC CMOS battery every 5 years for each EPC and update the CMOS Replace schedule when an EPC is swapped. Set the local time zone and set valid time synchronization (NTP) configuration.
Symptom: "OLD" DIB Cal data is loaded instead of the most recent.
Solution: Before calibrating the DIB, make sure the local time is correct. If it is not correct, check the CMOS battery and setup time synchronization before updating the system clock.
Explantation:
The root cause is that the local time on the EPC was incorrect when the DIB Cal data is created. If the CMOS battery is depleted (dead), the EPC will loose the correct time when the it is powered off. The EPC will boot with an invalid date (in the past). If the DIB Cal is performed with the date in the past, it will not be loaded as "latest." The Creation ID of the DIB Cal Data object (ri.sys.ObjClass = RiDibCalibration) is generated in a way that, when sorted alphabetically, proceeds the DIB Cal Data that was created in the past. This causes Cassini to load what it thinks is the latest cal date, even though the ri.sys.CreationDate value is in the future.
Corrective Actions: Contact [email protected] for assistance. A command line utility can be used to identify and adjust any affected objects. Please notify [email protected] when/if this script is run. This is only valid on Linux based Guru Server and NOT on a Tester EPC.
Run GuruServer v74.28 or later.
Run the attached script, chkGuruTime.sh, on each of the Guru Server, which required to shutdown the autostart of Guru, run the script then re-start the Guru. Copy the attached file to the Guru Server and make it executable.