pcp
[Top] [All Lists]

Re: PCP Network Latency PMDA

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: PCP Network Latency PMDA
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Mon, 23 Jun 2014 11:57:19 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <20140623141216.GK8337@xxxxxxxxxx> (Frank Ch. Eigler's message of "Mon, 23 Jun 2014 10:12:16 -0400")
References: <53A34A47.3060008@xxxxxxxxxx> <53A352FF.9090906@xxxxxxxxxxxxxxxx> <y0m7g4c9wcp.fsf@xxxxxxxx> <1241706054.31171165.1403487302812.JavaMail.zimbra@xxxxxxxxxx> <20140623014102.GI8337@xxxxxxxxxx> <1830537766.31176499.1403488150780.JavaMail.zimbra@xxxxxxxxxx> <20140623015408.GJ8337@xxxxxxxxxx> <223453324.31184588.1403489511833.JavaMail.zimbra@xxxxxxxxxx> <20140623141216.GK8337@xxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
>> Its common for someone to run something like "pminfo -f network" to get
>> a high level look, then browse through the result, maybe iterating on
>> further with pminfo to something more specific, or switching to pmchart
>> or another tool for a different view.
>
> I think it's reasonable for such one-shot clients to suffer from the
> indignity of a PM_ERR_PMDANOTREADY for such metrics.  (That's not too
> surprising, considering that the semantics would probably be COUNTER,
> which are meaningless in isolation.)

By the way, it would not be a big stretch for the PMDA retain
collection of these statistics for some time after a PCP client
closes, in case of a reconnection soon by an equivalent context.
This way, even

     % pminfo -f papi.system.FOOBAR
     -ERR_NOTREADY
     % pminfo -f papi.system.FOOBAR
     12345
     % pminfo -f papi.system.FOOBAR
     23456

would work.

- FChE

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