pcp
[Top] [All Lists]

Re: pcp updates, pcpfans.git fche/dev

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: pcp updates, pcpfans.git fche/dev
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Fri, 31 Oct 2014 22:40:08 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5452CFAB.5050703@xxxxxxxxxxxxxxxx> (Ken McDonell's message of "Fri, 31 Oct 2014 10:54:19 +1100")
References: <20141030203255.GA1913@xxxxxxxxxx> <494689218.4400197.1414702469822.JavaMail.zimbra@xxxxxxxxxx> <5452CFAB.5050703@xxxxxxxxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
kenj wrote:

> [...]  While a quick test is a good test, there are some cases where
> longer running tests are required [...]

Thanks.

The reason the pmmgr qa/666 test (not merged) takes relatively long is
because it exercises pmmgr's time-based polling and governing of
pmlogger/pmie daemons.  Normally, polling / pm*conf generation /
archive rotation takes a miniscule fraction of time compared to the
overall daemon cycle time (default 24 hours for pmlogger).

While the latter can be compressed for testsuite purposes, the former
cannot be much (polling / pm*conf still take a number of seconds), so
similar sorts of race conditions to the qa/518 case arise.  So far,
finding a sweet spot of cycle-times (to guarantee fixed-time ops
conclude, but not waste time) has been difficult.

Anyway, still thinking about it; all advice welcome.

- FChE

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