pcp
[Top] [All Lists]

Re: [pcp] QA: pmval showing one less sample

To: Nathan Scott <nscott@xxxxxxxxxx>
Subject: Re: [pcp] QA: pmval showing one less sample
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Mon, 07 Sep 2009 10:41:35 +1000
Cc: Martin Hicks <mort@xxxxxxxx>, pcp@xxxxxxxxxxx
In-reply-to: <1252098179.9881.4.camel@bozo>
References: <256314019.229001251939788289.JavaMail.root@xxxxxxxxxxxxxxxxxx> <1252098179.9881.4.camel@bozo>
Reply-to: kenj@xxxxxxxxxxxxxxxx
This whole thing is getting ugly and evolving into something between a
rat hole excursion and a turd polishing exercise.

Nevertheless, I now have a patch I'm comfortable with ... it is much
simpler than any of the earlier variants and is attached.

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.

Attachment: patch
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>