> This page is for version 10. > For other versions, use one of these documentation indexes: > - 11 (default): https://docs.nvidia.com/base-command-manager/product-manuals/11/llms.txt > - 10: https://docs.nvidia.com/base-command-manager/product-manuals/10/llms.txt > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.nvidia.com/base-command-manager/product-manuals/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/base-command-manager/product-manuals/_mcp/server. # Understanding Consolidation ## K.1 Introduction Consolidation is discussed in the sections on using consolidation in the Monitoring chapter (sections [12.4.3](/admin/monitoring#1243-monitoring-configuration-consolidators) and [12.5.2](/admin/monitoring#1252-the-consolidator-submode)). However, it may be confusing to have the concept of consolidation discussed in the same place as the use of consolidation. Also, the algebra that appears in that discussion ([here](/admin/monitoring#12435-consolidator-item-settings)) may not appeal to people. There are many who would like an explanation that may be more intuitive, even if it is less rigorous. Therefore, in this section a more informal and visual approach is taken to explain consolidation. ## K.2 What Is Consolidation? Consolidation is the compression of data, for data values that have been measured over a fixed interval. The compression is nothing particularly sophisticated. It is carried out by using some simple mathematical functions to the data points: the average, the maximum, or the minimum. ## K.3 Raw Data And Consolidation Suppose raw data is sampled every 2 minutes. And the raw data values are consolidated every 10 minutes. A visual representation of the data values available to the system is: ```bash --- time ---> raw: | | | | | | | | | | | | | | | | | consolidated: | | | | | ``` Here, every “|”" indicates a data point, so that the visual shows 5 times as many raw data points as consolidated data values. In the preceding visual it makes no sense to use consolidated data since the data values for raw data and consolidated data overlap. I.e., the more accurate raw data values exist for the entire period. As time passes, the intention is to start dropping old raw data, to save space on the disk. For example, for the first 20 minutes in the following visual, there are no longer raw data values available: **Example** ```bash --- time ---> raw: | | | | | | | | | | | | | | consolidated: | | | | | | ``` But the consolidated data points for this period are still available to the system. When the data values are plotted in Base View graphs, periods without raw data values automatically have consolidated data values used. So a combination of both data sources is used, which can be visually represented with: **Example** ```bash --- time ---> plot: | | | | | | | | | | | | | | | | ``` That behavior holds true for `cmsh` too. The behavior illustrated in the last visual assumes that the cluster has been UP for long enough that raw data is being dropped. In this case, “long enough” means at least 7 days. However, because RLE (Run Length Encoding) is used to compress the sampled monitoring data values on disk, this minimal “long enough” time can be (much) longer than 7 days. It depends on how much the measurable that is being sampled is changing as each sample is taken. if it is not changing, then RLE can compress over a longer time period. For example, if a node has been up and reachable without issues for 1000 days, then the `ssh2node` health check raw data values would be `PASS` over that 1000 days. For the period from now to 7 days ago, the raw data values of `PASS` are kept as they are for now. However, for the period from 7 days ago to 1000 days ago, consolidation on the unchanging raw values means that only two values, namely the `PASS` value of 1000 days and the `PASS` value of 7 days ago, need to be retained, in order to have a totally accurate record of what the values were in that period. On the other hand, the `forks` metric changes very quickly, and thus can do little RLE compression. That makes it a good choice for demonstrating the kind of output that the preceding visuals imply. ## K.4 A Demonstration Of The Output So, as a demonstration, the last 7 days for forks are now shown, with the data values in the middle elided: **Example** ```bash [basecm10->device[basecm10]]% dumpmonitoringdata -7d now forks Timestamp Value Info -------------------------- -------------------- ---------- 2018/10/17 10:30:00 2.76243 processes/s 2018/10/17 11:30:00 2.52528 processes/s 2018/10/17 12:30:00 2.53972 processes/s ... 2018/10/24 10:42:00 2.66669 processes/s 2018/10/24 10:44:00 2.63333 processes/s 2018/10/24 10:46:00 2.64167 processes/s ``` The first part of the output shows samples listed every hour. These are the consolidated data values. The last part of the output shows samples listed every 2 minutes. These are the raw data value values. I.e.: consolidated data values are used beyond a certain time in the past. If the administrator would like to explore this further, then displaying only consolidation values is possible in `cmsh` by using the `--consolidationinterval` option of the `dumpmonitoringdata` command: **Example** ```bash [basecm10->device[basecm10]]% dumpmonitoringdata --consolidationinterval 1h -7d now forks Timestamp Value Info -------------------------- -------------------- ---------- 2019/01/07 11:39:06 2.65704 processes/s 2019/01/07 12:30:00 2.60111 processes/s 2019/01/07 13:30:00 2.58328 processes/s ... [basecm10->device[basecm10]]% dumpmonitoringdata --consolidationinterval 1d -7d now forks Timestamp Value Info -------------------------- -------------------- ---------- 2019/01/07 18:09:06 2.59586 processes/s 2019/01/08 13:00:00 2.58953 processes/s 2019/01/09 06:06:06 2.58854 processes/s [basecm10->device[basecm10]]% dumpmonitoringdata --consolidationinterval 1w -7d now forks Timestamp Value Info -------------------------- -------------------- ---------- 2019/01/08 11:15:12.194 2.59113 processes/s ```