Hi -
kenj wrote, re PR1136:
> (a) yes, the nirvana solution for pmlogreduce would be to convert
> counter,bytes -> instant,bytes/sec
Could you explain why? Random PCP tools would be just as able to do
counter rate-conversion based on temporally-subsampled counter values
as original counter values. Is there a complication other than the
somewhat larger possibility of counter overflow between larger time
samples? Could pmlogreduce handle those situations emitting of
synthetic 0x0, 0xFFFFFF pairs of counter values for each complete
overflow cycle? Then it could preserve the previous type/units.
> (c) widening was added to pmlogreduce because the longer the time
> interval that the archive spans the higher the probability of a
> counter wrap, and in the absence of (a) the simplest way to deal
> with this is to expand 32-bit counters to 64-bit counters
Maybe a less simple way is worth considering, due to this fallout. It
already makes the time-reduced archives difficult to glue together
with others; further explicitly performed rate-conversion would make
it worse.
- FChE
|