From owner-pcp@oss.sgi.com Mon Apr 10 04:50:50 2000 Received: by oss.sgi.com id ; Mon, 10 Apr 2000 04:50:41 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:20762 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 10 Apr 2000 04:50:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id EAA19074 for ; Mon, 10 Apr 2000 04:45:33 -0700 (PDT) mail_from (kenmcd@melbourne.sgi.com) Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA28546; Mon, 10 Apr 2000 21:48:58 +1000 Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id VAA35127; Mon, 10 Apr 2000 21:48:54 +1000 (EST) Date: Mon, 10 Apr 2000 21:48:54 +1000 From: Ken McDonell To: Michal Kara cc: pcp@oss.sgi.com Subject: Re: PCP graphical monitor In-Reply-To: <20000410085211.42743@arthur.plbohnice.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pcp@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pcp-outgoing On Mon, 10 Apr 2000, Michal Kara wrote: > Hello! > > I have downloaded your Performance Co-Pilot software. Due to my work > for Czech portal (centrum.cz), I am very interested in performance > monitoring. However I greatly missed a graphic monitor to show me > graphical performance statistics. There are all manner of 2-D and 3-D performance visualization tools built over the PCP protocols. Unfortunately, most of these are currently kept private by SGI, and bundled with various solution bundles. In most cases these applications use libraries and technologies that cannot be open sourced, even if we wanted to release the SGI developed code. > So I have written one under the GTK library. Check it out, I have > attached the source archive to this letter. It requires GTK and libxml > (to read/write configuration). This is great. The more people who use the PCP protocols to develop value-added tools to consume performance data: 1. the more useful PCP becomes, and 2. the more pressure there is on SGI to innovate at the high end and release more of the lower-level tools over time. Can you please help me identify the RPMs I need to install so that I can build this? At the moment, configure dies thusly ... ... checking for gtk-config... /usr/bin/gtk-config checking for GTK - version >= 1.2.0... yes checking for gzopen in -lgz... no configure: error: libgz not found (required for libxml) Your mail to the list at oss.sgi.com bounced due to a size limit ... if I can make this work I'll put it up on a "contrib" area below http://www.oss.sgi.com/projects/pcp, and mail to the list. > I also have one question: How stable are indexes assigned to symbolic > value instance names? Currently it is only possible to index by number > in the monitor, but it will be necessary to index by name too. And I > don't want to check the index on every fetch. Good question. This is in a murky area we've been describing generically for some time as "dynamic instance domains". In practice they occur rather infrequently (the proc.* metrics is the most obvious example), and we've adopted a position that is as follows: 1. an agent exporting metrics should be free to add and delete instances on the fly. 2. an agent should try very hard to _not_ re-assign the same _internal_ instance identifier (the integer) to different instances and in particular to different _external_ instance identifiers (the string) as follows: (a) never in the life of the one exection of the agent, and (b) not if it can be avoided between one execution of the agent and the next. 3. given 1. and 2., most clients will operate according to the principle of "least suprise" if they enumerate the instance domain at start up and then ignore any changes ... instances that go away will return "no values" which is OK, new instances that appear will be ignored, which is often OK. 4. when the dynamic nature of an instance domain is important, the client can request "all instances" and then only has to do something different when consecutive fetches return a different set of instances ... this is _exactly_ what pmie does, for example. From owner-pcp@oss.sgi.com Mon Apr 10 06:19:31 2000 Received: by oss.sgi.com id ; Mon, 10 Apr 2000 06:19:21 -0700 Received: from eik.ii.uib.no ([129.177.16.3]:48294 "EHLO ii.uib.no") by oss.sgi.com with ESMTP id ; Mon, 10 Apr 2000 06:18:52 -0700 Received: from jfm by ii.uib.no with local (Exim 3.03) id 12ee5b-00071s-00 ; Mon, 10 Apr 2000 15:18:51 +0200 Date: Mon, 10 Apr 2000 15:18:51 +0200 From: Jan-Frode Myklebust To: Michal Kara Cc: pcp@oss.sgi.com Subject: Re: PCP graphical monitor Message-ID: <20000410151851.A22848@ii.uib.no> Mail-Followup-To: Michal Kara , pcp@oss.sgi.com References: <20000410085211.42743@arthur.plbohnice.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from kenmcd@melbourne.sgi.com on Mon, Apr 10, 2000 at 09:48:54PM +1000 Sender: owner-pcp@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pcp-outgoing On Mon, Apr 10, 2000 at 09:48:54PM +1000, Ken McDonell wrote: > > > So I have written one under the GTK library. Check it out, I have > > attached the source archive to this letter. It requires GTK and libxml > > (to read/write configuration). > Hi, this sounds really interesting. I would love to see a pmchart for linux. Do you think you could put your code up on the web, or send it to me privately by email? Best regards, janfrode -- Jan-Frode Myklebust, Para//ab, High Performance Computing Center From owner-pcp@oss.sgi.com Mon Apr 10 06:36:00 2000 Received: by oss.sgi.com id ; Mon, 10 Apr 2000 06:35:51 -0700 Received: from tah14.cesnet.cz ([194.108.115.182]:41991 "EHLO arthur.plbohnice.cz") by oss.sgi.com with ESMTP id ; Mon, 10 Apr 2000 06:35:25 -0700 Received: (from lemming@localhost) by arthur.plbohnice.cz (8.8.5/8.8.5) id PAA16432; Mon, 10 Apr 2000 15:35:03 +0200 Message-ID: <20000410153503.17621@arthur.plbohnice.cz> Date: Mon, 10 Apr 2000 15:35:03 +0200 From: Michal Kara To: pcp@oss.sgi.com Subject: Re: PCP graphical monitor Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e Sender: owner-pcp@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pcp-outgoing > this sounds really interesting. I would love to see a pmchart for linux. Do > you think you could put your code up on the web, or send it to me privately > by email? It has been put to http://k332.feld.cvut.cz/~lemming/projects/pcpmon-1.0.1.tar.gz Michal Kara From owner-pcp@oss.sgi.com Tue Apr 11 14:08:45 2000 Received: by oss.sgi.com id ; Tue, 11 Apr 2000 14:08:36 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:38713 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 11 Apr 2000 14:08:20 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id OAA02961 for ; Tue, 11 Apr 2000 14:03:34 -0700 (PDT) mail_from (kenmcd@melbourne.sgi.com) Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA09555; Wed, 12 Apr 2000 07:06:55 +1000 Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA58038; Wed, 12 Apr 2000 07:06:52 +1000 (EST) Date: Wed, 12 Apr 2000 07:06:52 +1000 From: Ken McDonell To: Kash Ansari cc: pcp@oss.sgi.com, "nafose (E-mail)" Subject: Re: ace install into alternate locations? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pcp@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pcp-outgoing On Tue, 11 Apr 2000, Kash Ansari wrote: > > A customer is testing out ace on our 1200Ls and has this question: > > "Does ace allow alternate install locations for some of its > packages? I went through ace to install pcp (nice!) and I > can't recall that it does. The reason I ask is that having > mpich installed into the main /usr tree makes it harder to > keep track of the files, especially in the case of alternate > builds. I'll gather together the benchmark data that we've > been able to gather thus far." > > If it's yes, is it a simple edit of the installace script or something > nasty? > > A choice during the installace would probably be a nice addition I would > guess. Fair question. Unfortunately the PCP packages _need_ to install somethings in places that cannot be relocated, e.g. /etc/rc.d/init.d for starters. So very early on we decided to _not_ make the base of the PCP installations relocatable. However, _everything_ within PCP is referenced indirectly via the pathnames defined in /etc/pcp.conf ... if someone _really_ wants to move PCP pieces then they can locate the paths from /etc/pcp.conf, move the directory and replace it by a symbolic link. For the record, the PCP pieces are installed in - /usr/bin ... common utilities and you can't move these, sorry - /usr/lib ... PCP libs, and you can't move these, sorry - /usr/include ... PCP headers, and you can't move these, sorry - /usr/man ... PCP man pages, and you can't move these, sorry - /var/log/pcp ... PCP logs - /usr/share/pcp ... private PCP commands, libs, demos, odds and sods - /var/pcp ... all of the configration stuff, agents, From owner-pcp@oss.sgi.com Wed Apr 12 05:21:12 2000 Received: by oss.sgi.com id ; Wed, 12 Apr 2000 05:20:52 -0700 Received: from tah14.cesnet.cz ([194.108.115.182]:58886 "EHLO arthur.plbohnice.cz") by oss.sgi.com with ESMTP id ; Wed, 12 Apr 2000 05:20:20 -0700 Received: (from lemming@localhost) by arthur.plbohnice.cz (8.8.5/8.8.5) id OAA27404; Wed, 12 Apr 2000 14:19:38 +0200 Message-ID: <20000412141938.62918@arthur.plbohnice.cz> Date: Wed, 12 Apr 2000 14:19:38 +0200 From: Michal Kara To: pcp@oss.sgi.com Subject: PCP graphical interface Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e Sender: owner-pcp@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pcp-outgoing Hello! I have made another few improvements in the PCPMON and put up a web page for it. You can find it at http://k332.feld.cvut.cz/~lemming/projects/pcpmon.html. Please let me know how do you like it. Michal Kara From owner-pcp@oss.sgi.com Wed Apr 12 13:21:37 2000 Received: by oss.sgi.com id ; Wed, 12 Apr 2000 13:21:28 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:31796 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 12 Apr 2000 13:21:20 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA02742 for ; Wed, 12 Apr 2000 13:16:36 -0700 (PDT) mail_from (kenmcd@melbourne.sgi.com) Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA17622; Thu, 13 Apr 2000 06:18:46 +1000 Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id GAA61916; Thu, 13 Apr 2000 06:18:44 +1000 (EST) Date: Thu, 13 Apr 2000 06:18:44 +1000 From: Ken McDonell To: Michal Kara cc: pcp@oss.sgi.com Subject: Re: PCP graphical interface In-Reply-To: <20000412141938.62918@arthur.plbohnice.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pcp@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pcp-outgoing On Wed, 12 Apr 2000, Michal Kara wrote: > Hello! > > I have made another few improvements in the PCPMON and put up a web page for > it. You can find it at http://k332.feld.cvut.cz/~lemming/projects/pcpmon.html. > Please let me know how do you like it. This is a good initial effort at a GPL'd PCP stripchart monitor. The following comments are all intended to be constructive to encourage the development of pcpmon and any other similar monitoring tools over the PCP protocols ... 0. You probably want to consider changing the basic operational model for how you present the metrics in the Values setup dialog ... in addition to the issues of instance "numbers" vs instance "names" and memory footprint you've identified, you should consider ... a) the namespace can be much larger, e.g. on my local Irix server $ pminfo | wc -l 1552 b) the number of instances can be even larger, e.g. on the same local Irix server $ pminfo -F | grep ' value ' | wc -l 27911 c) the namespace can be different on different hosts d) the instances are expected to be different on different hosts e) metrics with the same name on different hosts do not necessarily have the same metric id, e.g. bruce is a Linux system, snort is an Irix system ... $ pminfo -m -h bruce kernel.all.load kernel.all.load PMID: 60.2.0 $ pminfo -m -h snort kernel.all.load kernel.all.load PMID: 1.18.3 f) instances with the same name on different hosts do not necessarily have the same instance number g) the namespace and instances change over time even on the same host All of the above arise from the fundamental architectural decision that in PCP it is the PMCD alone (or rather in concert with the local PMDAs) that decides what metrics and instances are available. This breaks the tyranny of the SNMP MIB, forces the protocols to support the necessary name and meta data services and allows new sources of metrics to be added on any host without breaking anything else. I'd suggest a more scalable solution for the metric and instance selection might be a dynamic tree-selector where: a) only the top-level metrics are displayed by default, e.g. on my local Linux system this would be: + disk + filesys + hinv + kernel + mem + mpi + network + nfs + pmcd + proc + rpc + swap + swapdev + web Use pmGetChildren(3) or pmGetChildrenStatus(3) here. b) let the user expand any of the non-leaf entries, e.g. --| filesys +- capacity +- used +- free +- maxfiles +- ... Use pmGetChildren(3) or pmGetChildrenStatus(3) again here. c) and finally let the user expand a leaf node into instances, e.g. --| filesys +- capacity +- used --| free * /dev/root * /dev/sda6 * /dev/sda5 * /dev/sdb1 * ... This would be less of a memory foot print, easier for the user to navigate, the instances can be enumerated only when needed so it accommodates dynamic instance domains, and the dialog can be rebuilt when you connect to a new server (with a new namespace). 1. I don't think your scaling model is going to work ... as soon as you have 2 metrics in the same chart you have 2 choices: a) auto-scale to a single y axis, or b) independently scale each plot and (optionally) annotate the left and right axes with the two scales. We chose a). You've opted for b). I think b) is less desirable because - the visual message is wrong (two values with a similar y value in the chart _should_ have the same _real_ value for the underlying metrics), and - this model does not scale beyond 2 plots in the same chart 2. PCP metrics have metadata to describe the dimension and scale of the values. We've found it important to use this to prevent "silly" combinations of metrics in the same chart, and to annotate the graph axes. 3. I like the expression evaluator ... this is a special case of something called a "derived metric" that we've been fighting with for a long time ... the semantics of derived metrics is very tricky if you want to restrict the user to only "sensible" combinations ... if that is not a concern, then go for it. 4. I had to upgrade from 1.0.0 to 1.8.7 for libxml and libxml-devel before pcpmon would link ... the unresolved symbol was xmlSubstituteEntitiesDefault ... you may want to check the dependencies, either in the configure script or your web page. 5. And finally, a couple of trivial patches to remove some compilation warnings: [kenmcd@bozo-pc src]$ diff -c file.c.orig file.c *** file.c.orig Thu Apr 13 16:06:57 2000 --- file.c Thu Apr 13 16:11:04 2000 *************** *** 8,13 **** --- 8,14 ---- #include #include #include + #include #include #include [kenmcd@bozo-pc src]$ diff -c values.c.orig values.c *** values.c.orig Thu Apr 13 16:06:33 2000 --- values.c Thu Apr 13 16:09:59 2000 *************** *** 7,12 **** --- 7,13 ---- #include #include #include + #include #include #include #include Keep up the good work. From owner-pcp@oss.sgi.com Wed Apr 12 23:48:04 2000 Received: by oss.sgi.com id ; Wed, 12 Apr 2000 23:47:54 -0700 Received: from tah14.cesnet.cz ([194.108.115.182]:37392 "EHLO arthur.plbohnice.cz") by oss.sgi.com with ESMTP id ; Wed, 12 Apr 2000 23:47:35 -0700 Received: (from lemming@localhost) by arthur.plbohnice.cz (8.8.5/8.8.5) id IAA30343; Thu, 13 Apr 2000 08:47:21 +0200 Message-ID: <20000413084719.27699@arthur.plbohnice.cz> Date: Thu, 13 Apr 2000 08:47:19 +0200 From: Michal Kara To: pcp@oss.sgi.com Subject: Re: PCP graphical interface References: <20000412141938.62918@arthur.plbohnice.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from Ken McDonell on Thu, Apr 13, 2000 at 06:18:44AM +1000 Sender: owner-pcp@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pcp-outgoing Thanks for the letter. > 0. You probably want to consider changing the basic operational model > for how you present the metrics in the Values setup dialog ... in > addition to the issues of instance "numbers" vs instance "names" and > memory footprint you've identified, you should consider ... > The note about memory usage is because currently the instance ID is taken as an index to an array, so if the name resolves to ID 1000, 1000*sizeof(double) bytes is allocated. I can either create another hash table (but that would be overcomplicated in 99% of the cases), or create simple array and linearly scan it which will be OK as long as the user doesn't use too many instances (up to 10-20) of one PM. > a) the namespace can be much larger, e.g. on my local Irix server > $ pminfo | wc -l > 1552 > b) the number of instances can be even larger, e.g. on the same > local Irix server > $ pminfo -F | grep ' value ' | wc -l > 27911 > c) the namespace can be different on different hosts > d) the instances are expected to be different on different hosts > e) metrics with the same name on different hosts do not necessarily > have the same metric id, e.g. bruce is a Linux system, snort is > an Irix system ... > f) instances with the same name on different hosts do not necessarily > have the same instance number That should be all OK in the current version, since PMIDs and instance IDs are resolved when program starts/metric is added. See also note about the predefined values below. > g) the namespace and instances change over time even on the same host > As long as the IDs remain constant this should pose no problem. Otherwise simple bringing up the values dialog and clicking OK causes all symbolic names to be resolved again. > a) only the top-level metrics are displayed by default, e.g. on > my local Linux system this would be: > > + disk > + filesys > + hinv > + kernel > + mem > + mpi > It seems you didn't get the "predefined values" dialog - the values are not from PNMS, they are predefined expressions for beginner users. > 1. I don't think your scaling model is going to work ... as soon as > you have 2 metrics in the same chart you have 2 choices: > a) auto-scale to a single y axis, or > b) independently scale each plot and (optionally) annotate the > left and right axes with the two scales. > > We chose a). You've opted for b). I think b) is less desirable > because > - the visual message is wrong (two values with a similar y > value in the chart _should_ have the same _real_ value for > the underlying metrics), and > - this model does not scale beyond 2 plots in the same chart > Partially right. There's no problem to choose a), you just check "show on left axis" for both values. So it clearly scales beyond 2 plots, you can have as many graphs as you can. The graphs get too dense with about five graphs anyway, so some algorithms in the PCP count with the fact that the number of values is generaly small (up to 10-20). When you decide to show values on different axes in one graph, they are usualy not same but have some correlation - like number of HTTP requests vs network traffic. And what you want to see is the corelation. > 2. PCP metrics have metadata to describe the dimension and scale of the > values. We've found it important to use this to prevent "silly" > combinations of metrics in the same chart, and to annotate the graph > axes. > > 3. I like the expression evaluator ... this is a special case of something > called a "derived metric" that we've been fighting with for a long > time ... the semantics of derived metrics is very tricky if you > want to restrict the user to only "sensible" combinations ... if > that is not a concern, then go for it. > These two must be considered together - descriptions and semantics are nice, but if you compute value from an expression, it is tricky, as you write. There is note by the delta operator that it cannot use the "counter" semantics to handle overflows, so the overflows are handled by heuristics "if the last value was bigger than 3G and current is lower than 1G, it is overflowed counter". > 4. I had to upgrade from 1.0.0 to 1.8.7 for libxml and libxml-devel > before pcpmon would link ... the unresolved symbol was > xmlSubstituteEntitiesDefault ... you may want to check the > dependencies, either in the configure script or your web page. > OK, I will check if this symbol is present in the configure. > 5. And finally, a couple of trivial patches to remove some compilation > warnings: > Thanks, they have been applied to my working version. > Keep up the good work. > Thanks for the comments. Michal Kara P.S.: I am already on the PCP list, so you can answer there. From owner-pcp@oss.sgi.com Thu Apr 13 06:13:06 2000 Received: by oss.sgi.com id ; Thu, 13 Apr 2000 06:12:57 -0700 Received: from cpk-mail-relay1.bbnplanet.com ([192.239.16.198]:38896 "HELO vienna1-mail-relay1.bbnplanet.com") by oss.sgi.com with SMTP id ; Thu, 13 Apr 2000 06:12:34 -0700 Received: from atlantic3-cp.atlanticos.com (atlantic3-cp.atlanticos.com [199.120.242.66]) by vienna1-mail-relay1.bbnplanet.com (Postfix) with SMTP id 4DD157A8A for ; Thu, 13 Apr 2000 13:12:25 +0000 (GMT) Received: by AtlanticMutual.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 852568C0.00487841 ; Thu, 13 Apr 2000 09:11:33 -0400 X-Lotus-FromDomain: ATLANTIC COMPANIES From: Cameron_C_Caffee@AtlanticMutual.com To: pcp@oss.sgi.com Message-ID: <852568C0.00487733.00@AtlanticMutual.com> Date: Thu, 13 Apr 2000 09:12:21 -0400 Subject: PCPMON - kudos & encouragement Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-pcp@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pcp-outgoing From: Cameron C Caffee@ATLANTIC COMPANIES on 04/13/2000 09:12 AM To: pcp@oss.sgi.com cc: Subject: PCPMON - kudos & encouragement I'd like to add my praise for this effort to provide a real time monitoring capability within the Open Source community. I like the PCP architecture but will not be inclined to do very much with it without Open Source tools to utilize the metrics gathered by it. A few suggestions for PCPMON : (1) Plot labeling - if one has several graphs on the screen, it would be useful to have each reflect something more than "PCP Monitor". Perhaps the user could provide a label in the Config settings (e.g. a plot of the cpu-related metrics such as system,user,nice,idle might be labeled "CPU Utilization"). (2) Source labeling - the plot's source would be useful (e.g. Host: node01). When one has plots for several nodes on the screen, its difficult to remember which is which without a label. (3) Axis units - the user could provide a units label for each axis. Archive analysis : I agree with your project "to do" referring to support for archives. There's nothing wrong with having one tool for real time monitoring and another for archive analysis since the goals for each are a bit different. The former has the character of an "alert" or "alarm" while the latter is normally oriented toward historical trending (e.g. CPU Utilization trend for last 6 months). Archive analysis would benefit from options for different forms of output. They might include : delimited data points - for piping to another analysis or reporting tool postscript, pdf, etc. - for hard copy gif, jpg, etc. - for web access to plots. Of course, there would be no objection to a generic export format for piping to commonly available plot and reporting tools. Some examples would be helpful to the novice user. A great beginning ! Much thanks for your efforts ! Cameron +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I Cameron Caffee, Sr Systems Manager Atlantic Mutual Companines I +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I Internet : Cameron_C_Caffee@AtlanticMutual.Com I Snail Mail : I I +++++++++++++++++++++++++I I FAX : (540) 772-4198 I 1325 Electric Road, SW I I Voice : (540) 772-4071 I Roanoke, VA 24018 I +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From owner-pcp@oss.sgi.com Sun Apr 16 16:23:37 2000 Received: by oss.sgi.com id ; Sun, 16 Apr 2000 16:23:28 -0700 Received: from postfix3.free.fr ([212.27.32.22]:25860 "HELO postfix3.free.fr") by oss.sgi.com with SMTP id ; Sun, 16 Apr 2000 16:23:05 -0700 Received: from free.fr (unknown [213.228.37.175]) by postfix3.free.fr (Postfix) with ESMTP id 8B95D86BA7 for ; Mon, 17 Apr 2000 01:22:52 +0200 (CEST) Message-ID: <38FA4ABF.BE1A7E3B@free.fr> Date: Sun, 16 Apr 2000 23:20:31 +0000 From: Luc Stepniewski Reply-To: lstep@free.fr X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Bug report and debian package now available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pcp@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pcp-outgoing Hello, Here's my list of bugs and their correction for the latest PCP version. ------------ In pcp.conf.in, there is PCP_CPP_PROG=@cpp_simple@@cpp_simple_args@ But when it is replaced, it gives something like this: PCP_CPP_PROG=/lib/cpp -P -traditional -undef Which is wrong as it is interpreted as having the /lib/cpp content into PCP_CPP_PROG and to execute the program '-P -traditional -undef' ! So when I run /etc/init.d/pcp start, I get an error saying 'Program -P not found'. The correction is to add quotes, like this: PCP_CPP_PROG="@cpp_simple@@cpp_simple_args@" ------------ In etc_init.d_pmie, there's a call to a variable named IS_ON, which doesn't exist. After searhing a little into all the available code, I found its declaration in pmlogger.sh. The correction is to add the following lines at the beginning of etc_init.d_pmie: if which chkconfig >/dev/null 2>&1 ; then IS_ON=chkconfig else IS_ON=false fi ------------ In etc_init.d_pmie, there's a call to MAIL, which is defined as MAIL=/usr/sbin/Mail The problem is that, at least on Debian, it is /usr/bin/Mail The correction is to do exactly like in src/pmcd/rc_pcp, that is: MAIL=`which Mail` ------------ I added support for Debian packages by changing all of the Makefiles to use a supplementary variable, named DESTDIR, which is ONLY defined when compiling the package for Debian. (it has no incidence if used anywhere else like redhat, or just plain .tar.gz). This variable is used in front of each destination directory, to allow a different path than an absolute one. After some discussion with Mark Goodwin and a lot of tests, I came to the conclusion that it is not currently possible to define some global variable by modifying the pcp.conf file. The problem is that this file is used BOTH for installation, and for later use, after installation. Moreover, some files are generated from these variables. So if I put the temporary paths I use for installation, I will get all wrong :-( If SGI could backport the DESTDIR variable trick into the official distribution of PCP, it would be really cool, and ease the work of Debian maintainers (me :-) For the debian package, the other thing which is different from standard installation is the path to man and doc directories which are /usr/share/doc and /usr/share/man, to comply with the Debian standards (and FHS too, I guess). All of the debian specific mods and all centralized in the debian/ directory. The debian pcp package I made includes all of the corrections described above. It is available from ftp://ftp.banquise.org/pub/debian/ (I uploaded the diff file too, against the original distribution). Thanks, Luc -- Luc Stepniewski Adequat - Securite, Linux Public key: Key D93B2D2D fingerprint = 49 00 CC D1 69 03 E2 94 C8 78 ED 3C 75 89 A8 DE From owner-pcp@oss.sgi.com Mon Apr 17 01:03:03 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 01:02:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:64808 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 01:02:19 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id AAA08990 for ; Mon, 17 Apr 2000 00:57:30 -0700 (PDT) mail_from (markgw@sgi.com) Received: from sandpit.melbourne.sgi.com (sandpit.melbourne.sgi.com [134.14.55.132]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA18451; Mon, 17 Apr 2000 18:00:46 +1000 Date: Mon, 17 Apr 2000 18:00:45 +1000 (EST) From: Mark Goodwin X-Sender: markgw@sandpit.melbourne.sgi.com To: Luc Stepniewski cc: pcp@oss.sgi.com Subject: Re: Bug report and debian package now available In-Reply-To: <38FA4ABF.BE1A7E3B@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pcp@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;pcp-outgoing On Sun, 16 Apr 2000, Luc Stepniewski wrote: > Hello, > > Here's my list of bugs and their correction for the latest > PCP version. > Luc, thanks for your efforts. As time permits I'll work through your changes and incorporate them into pcp2.1.6. Please stay tuned .. thanks -- Mark