Timebeat's most detailed dashboard is the Device Information page. This holds the key to your host's synchonisation secrets.
At first, this page may be daunting but I assure you all is not as complicated as it may at first appear, in fact, once you understand this is one of the most useful dashboards for troubleshooting and working through support issues.
The above is what you will most likely be welcomed with when you enter this dashboard. A lot of rows closed down to headings with the first one open. What you may not be greeted with are the annotations.
Annotations are a simple yet effective visualisation for showing you what is going on with the synchronisation application behind the scenes. The above annotation is likely seen upon start-up, a new primary source of UTC.
The below annotation lets you know which group of UTC sources are currently the active ones in use, in the instance below we can easily see that we are synchronising to our primary sources of UTC.
There are a few more annotations but for greater detail on each of them go check out the Annotations guide here.
Master & Slave Clocks:
When hardware timestamping is enabled your dashboards will populate with both master and slave clocks. If you do not have hardware timestamping enabled the system clock will become your master clock and the slave row will be empty.
You can configure Timebeat to synchronise all available slave clocks as we can see below.
What we can see above is that the Master Clock is the Enp2s0 interface. This is the clock which is using the UTC source to synchronise its clock. From there we have two slave clocks the Enp6s0 interface and the system clock. Both of these slaves will be synchronised by the Master Clock. In the event you have bonded interfaces or team interface configuration, Timebeat will dynamically upgrade the slave interface to master if the master clock interface goes down.
To the right of each offset graph, we can see the clock performance graph. This is sometimes referred to as granularity. In a nutshell, this shows the smallest increment the clock can report. Typically these records are fairly stable but you can easily see spikes in this value when you place your system under load. As a mini metric for performance, you can utilise this when conducting analysis on how your systems operate within certain conditions.
Time Source: <protocol>:<Source ID>
A dynamic list of Source IDs will populate these rows, below we can see two sources both of which are PTP.
The above graphs are a good example of some of the complex features within Timebeat such as the Intelligent offset filter. Above we can see that larger time offsets are filtered out of the system and therefore not used during synchronisation. This allows for more stable synchronisation and better accuracy to UTC. The above graphs display the raw values for the UTC sources in relation to the host as well as the easy to digest EMA which is useful for understanding long term averages without the noise.
To the right of the UTC source offset graphs, we see the One-way Delay graph. This shows how packets are traversing from source to host. A more stable One-way delay is always the goal but this can be useful when troubleshooting timing or sync issues as it can direct you to a network issue if fluctuations are occurring.
Algorithm & Host Servo:
The Algorithm and Host Servo rows may not be your go-to graphs, you may not even ever populate these graphs. Starting with the Algorithm graphs, these will dynamically repeat for each clock that is being synchronised on your host.
It is important to understand that these graphs will only be populated if the algo_logging parameter is set to true within your timebeat.yml file. If you want more details on this check out the Advanced Configuration information here.
When logging you will see 3 graphs relating to the Algorithm in use for your clock synchronisation. The first is the Clock Frequency, this relates to the level of change that is currently taking place. i.e. by how much is your clock being adjusted.
The next (which is probably more useful) is the PID Frequencies. This is an especially useful graph if you are experimenting with your own custom steering algorithm as you can see how your modifications directly affect the P, I, and D values. This allows for a very quick analysis of how your algo is performing and stability.
The last graph within the Algorithm row is the Client Raw Absolute graph. This is very similar to the offset graph but allows for a simpler evaluation of offset when modifying the steering algorithm. Although similar to the offset graph this only looks at the raw values converted to an absolute number.
The host servo graphs are split into two charts. The first (left side) is a stacked bar chart that depicts the number of transactions your host receives from each Source of UTC. Typically this is one transaction a second for each source of UTC making each bar total 180. The right bar graph represents the number of servo runs. In basic terms this is how often the system clock is adjusted - typical behavior is once a second making each bar total 60.