Hi Ken,
----- Original Message -----
>
> 1. if pmie starts sooner, the number of samples should be larger, not
> smaller ... so in qa/260 expecting a value of 180, finding a value of
> 172 or 175 does not sound like a filter change is the right fix
The sample time is increased by up to 2sec over earlier due to removal
of the delays. For rate conversions like in 260 we'll end up with a
larger denominator in the delta-v-over-delta-t calculation. So, if the
numerator doesn't increase accordingly (depends on the sampled values),
we can expect to see a smaller rate converted value.
In all my tests, the values were only ever going down (slightly), so I
only went with only decreasing the filter range.
> 2. qa/312 is failing for me now and the pmie rule is never being evaluated
>
> I suspect (but have not found yet) some early rule firing that is no
> longer working with the 1 sec delays at start removed ... more
> investigation needed, me thinks.
That may be because I aggressively reduced the timeout in test qa/312 -
too much so perhaps. Does this change things...?
diff --git a/qa/312 b/qa/312
index f3e0d75..c18ac3c 100755
--- a/qa/312
+++ b/qa/312
@@ -25,7 +25,7 @@ trap "rm -f $tmp.*; exit \$status" 0 1 2 3 15
echo 'load = sample.load;' | pmie -v -t 1hour >$tmp.out 2>$tmp.err &
pmie_pid=$!
-pmsleep 0.5
+pmsleep 1.5
$signal -s TERM $pmie_pid
wait
If not, can you run that sample.load pmie invocation in a shell and see
if it really produces no output at all? (anything on stderr?)
cheers.
--
Nathan
|