| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [pcp] qa/518 tweaks on pcpfans.git fche/dev, Frank Ch. Eigler |
|---|---|
| Previous by Thread: | Re: [pcp] pcp updates, pcpfans.git fche/dev, Nathan Scott |
| Next by Thread: | pcp updates: fche-merge, pmlogextract, qa, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |