TimeKeeper maintains all logging data in clear text formats for easy analysis and management. This includes logging parameters of each configured timing source, client timing quality information, network map data, and more.
To access the logs, either see under the Logs tab, or download the logs under the Support tab (see Downloading Log Files).
TimeKeeper logs information in multiple files, maintaining data on alarms, general messages, state change information, administrative information, and source sync information. All sources have the same log format regardless of source type.
Every update that TimeKeeper receives is recorded, one line per update.
Below is some information on the log file format:
timekeeper_0.data in the folder
tk_report\var\log is a running list of every update that TimeKeeper receives and how TimeKeeper is adjusting time for Source (0). It is the best way to see how TimeKeeper is performing. This file contains a line for every update received from the time source. If it is growing then TimeKeeper is receiving time updates.
In most installations, the first two fields – the absolute timestamp and the offset from the time source — are all that is of interest. Once started and running properly this file should be growing as updates are received.
- Column 1: Absolute timestamp of the update, seconds since midnight January 1 1970 (also known as UNIX time)
- Column 2: Offset (in seconds) from the remote server or time source
- Column 3: Raw offset from remote side – pre-smoothing and adjustments
- Column 4: Internal testing use
- Column 5: Clock correction factor for the TimeKeeper managed clock
- Column 6: Used to provide additional data with TimeKeeper GPS devices
- Column 7: Used to provide additional data with TimeKeeper GPS devices
- Column 8: A predictive indicator for internal use
- Column 9: Timestamp type – hardware/software/other timestamp source
- Column 10: Network delay – meaning depends on type of source
- Column 11: Raw network delay – meaning depends on type of source (for NTP/PTP this is the oneway trip time)
- Column 12: Time source, PTP, NTP, PPS or other
- Column 13: “Ideal” clock correction that if used would have minimized offsets over the previous few minutes
- Column 14: Model error over the model interval period
- Column 15: “Ideal” clock correction from sourcecheck calculations if applicable
If this file is not being updated, it is likely that firewalls are preventing receipt of network data, or there is some configuration issue reported in the timekeeper file.
\var\log\timekeeperclients contains clock quality about client machines that TimeKeeper is either directly serving time to or otherwise able to retrieve information from. The files in this directory contain data in the same format as described above for
timekeeper_$SOURCE.data. The amount of detail available in each file will vary depending on the client. For some remote client types, the data available is limited. If the client is a TimeKeeper client, the data provided in that file will be more fully populated, giving you a better understanding of timing quality across the network.
TimeKeeper is provided with a default log rotate recipe that rotates all of the relevant TimeKeeper log files. By default, this will retain 7 days worth of log files. If you have specific log storage needs this value can be modified via the TimeKeeper Web UI: Navigate to Configuration > TimeKeeper configuration, and scroll down to Days of TimeKeeper logs retained.
TimeKeeper’s multisource feature allows for easy compliance with the FINRA OATS specification. For complete details, refer to the OATS Reporting Technical Specifications.
Accuracy to within one second of NIST time is required. However, if there is a very precise local time source, it is unlikely that a public NIST server is being used to drive the clock. By pointing to a NIST server as a secondary source, accurate logs can be maintained that provide continuous system time offsets from NIST time.
To configure for this scenario, the TimeKeeper configuration should specify a NIST server as a secondary (or even lower priority) time source.
The display compliance inside the Web UI, obtain a list of all the timing sources (Configuration > TimeKeeper configuration > Sources), and then check for their timing accuracy under Timing Quality > Live Graphs, where you can trace presence and accuracy over the log duration.
Note: The default log duration retainment period is 7 days. This can be changed under Configuration > TimeKeeper configuration.
For permanent tracing, establish a process to pull logs regularly, and store them in a safe location. VelaSync supports setting up cron jobs to transfer relevant logs from the unit to a storage system via standard protocols like FTP or SCP.