Fix the number-of-samples value calculated in pmval once and for all.
For those who care, it turns out that the number of fetches may be
known, the number of reported samples cannot be precomputed correctly
in all cases ...
only works for archives with -a (not -U or -h)
is known for non-counter metrics
most of the time is known for counter metrics but there are some
important corner cases where this is not the case, specifically there
will be one more reported sample than expected for a counter when the
report starting time is not at the start of the archive and the metric
has a defined value before the report starting time with no intervening
mark record (interpolate mode does return a value at the first report
sample in this case!).
With this pmval patch, the QA fallout is nil, except for 144 that is an
unrelated timezone problem. Also this patch avoids referencing the
context too soon, as there is no point in inspecting the metric's
semantics to try and better guess the value of smpls. As a bonus, this
patch also documents pmval's -U option that has remained a secret for
nearly a decade.
Fix the number-of-samples value calculated in pmval once and for all.
For those who care, it turns out that the number of fetches may be
known, the number of reported samples cannot be precomputed correctly
in all cases ...
With this pmval patch, the QA fallout is nil, except for 144 that is an
unrelated timezone problem. Also this patch avoids referencing the
context too soon, as there is no point in inspecting the metric's
semantics to try and better guess the value of smpls. As a bonus, this
patch also documents pmval's -U option that has remained a secret for
nearly a decade.