Using NTP on the Sun Fire 15K/12K Server
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Sun Fire™ 15K/12K server system controller (SC) is a SPARCengine_ CP1500 board, which is a member of Sun's family of platforms based on CompactPCI technology. One of the key components of the CP1500 board is the NVRAM device that contains a time-of-day (TOD) clock and non-volatile memory that stores the MAC address of the CP1500 board. The NVRAM has its own lithium battery to operate the clock and to retain the contents of the NVRAM during power-off situations.
The real-time clock circuitry has an accuracy of plus or minus one second per day. Despite this accuracy, both field and internal sources have noted that the SCs are losing from 1.4 to 8 seconds per hour. As a result, several bugs have been opened. The solution to prevent these time skews is to use the Network Time Protocol (NTP), which is designed to synchronize computer clocks over a network.
This article addresses the time skew issues for the Sun Fire 12K/F15K server and explains how the system controllers and domains can be configured as NTP clients to external servers. A sample configuration is also provided.
NTP Concerns
The System Management Services (SMS) 1.1 Administrator Guide and the System Management Services (SMS) 1.2 Administrator Guide for the Sun Fire™ 15K/12K Systems contain the following statements:
If NTP makes a large time correction on the SC, the setdate(1M) command will not store the correct time offsets.
The main SC propagates the time to the spare SC by file propagation. This process causes the time to be off on the spare SC even if NTP is in use.
In response to these statements, Enterprise Systems Products (ESP) Engineering has made the following observations:
Many of the assumptions that the offset will not be correct are based on the ideas that the offset was set during a skewed SC time period or that domains will reboot and receive the time through the OpenBoot™ PROM server daemon, osd(1M), during a skewed SC time period. ESP Engineering does not believe that these examples are valid.
With NTP on the SCs, the time on the spare SC is corrected. The time is propagated to the spare SC from the main SC. The act of reading, packaging, and restoring the time takes a significant amount of time. If the main SC is busy, a significant time error on the spare SC can be introduced. Without NTP on the spare SC, a failover could cause the time to be off by more than a second. With NTP, the NTP daemon, xntpd(1M), would constantly be making corrections to the time. Thus, the amount of time error on the spare SC is decreased.
The setdate(1M) command is already inaccurate because it requires the time to be set manually. In addition, it is only accurate to the second, and even this level of accuracy is questionable. Thus, the accuracy is significantly better with NTP running on the SCs than it is with a manual time adjustment.
If NTP is in use on the SC and the setdate(1M) command is used to set the time offset for a domain, the correct domain offset will be established from a correct SC time source. The corrections made by NTP are towards the correct time, not away from the correct time. Therefore, if the SC time is maintained by NTP, the offset should continue to be correct.
If the SC and the domains are synchronized using NTP, then using the setdate(1M) command is not necessary. The setdate(1M) command would only be necessary if a user desires a special case for a non-standard SC time or domain time. Otherwise, the SC times and domain times will be correct because the same NTP server will align the SC times and domain times.
Adjustments can be made locally in the Solaris™ Operating Environment (OE) at any time by setting the time zone. Setting the time zone does not change the offset established by the setdate(1M) command. However, if NTP is used on the domain, NTP nullifies the offset when it makes corrections and synchronizes the time with the NTP servers. If an offset is needed, NTP should not be running on the domain; however, that does not prevent NTP from running on the SCs.