The on board oven computers obtain their time from Crater. Certainly when they boot, and it is unknown (to me anyway) if they update their time subsequently). This has interesting implications for the oven data staleness checking. When I ran the new oven software on a linux machine with the proper time, the data appeared to be 9 minutes old and was all invalidated by the staleness check. This check was "opened up" to allow testing the new software without rebooting the on board computers.
Notice thought that when Crater's time is fixed, the data from the oven will all be marked invalid until either the on-board computers are rebooted, or the old oven software has the check opened up (which will never happen).
server ntp.arizona.edu #server ntp1.arizona.edu #server ntp2.arizona.edu #server ntp3.arizona.eduNote that the ability to access an NTP server can be tested via the following command. Note that it may not be possible to access off-campus NTP servers due to firewall policies established by CCIT, so this is worth checking.
ntpdate -q ntp.arizona.edu server 128.196.128.233, stratum 2, offset 520.982519, delay 0.02655 23 Jul 12:01:39 ntpdate[6706]: step time server 128.196.128.233 offset 520.982519 secAfter making the above edits the ntp server needs to be restarted via:
cd /etc/init.d ./xntpd stop ./xntpd startAfter a few minutes, the time will be correct. The state of NTP can be checked via the following command:
bash-2.03# ntpq -p remote refid st t when poll reach delay offset disp ============================================================================== 128.196.128.233 10.140.34.16 2 u 53 64 1 1.21 -4.629 15875.0A non-zero "reach" value is a good thing, along with non-zero values for offset and disp.
Tom's home page / tom@mmto.org