Hall, Eric R wrote: > A 1 second interval on the firmware level is fairly heavy use. You will not > want that. Anything less than about 2 minutes is a bit overkill for a small > embedded system that shares its resources. > I guess that's what I'm trying to figure out. If a system's power does fluctuate at a higher rate than that it could be worth knowing. > For what it does, IPMITool is probably the fastest In-band and OOB IPMI level > tool you will find. Most of what takes so long is establishing communication > with the management controller. There really is not much that can improve > this as it is a limitation by the management controller. > The point I was trying to make (and maybe failed to do so), is if you can start ipmitool once and never exit, you only take that hit one time. > RE: power monitoring every second. Of course you'll see fluctuations; you > are influencing that by making the MC work hard to poll the sensor, queue the > data, send it though the communication interface, etc... Long ago I tested > systems like that and soon realized that the sampling caused a 40 - 60 watt > increase in power usage (or error) versus sampling over a longer period of > time. I compared the results with an external watt hour meter. There wasn't > much of a difference between the longer sample period average and the real > watt hour meter. > When you say long ago, is that data still valid? Do you remember the kind of system? In my very poorly constructed test I ran ipmitool constantly and saw power change by a couple of watts. > RE: daemon. There is a bit of a security problem here. You might want to > read the IPMI spec. before taking this path. > yeah, I agree letting just anyone talk to a daemon could be a big hole, but if you have a known user community and no outside network access it's at least reduced though certainly not 0. -mark > My moot points anyway. ;) > > - Eric > > > > -----Original Message----- > From: Mark Seger [mailto:mark.se...@hp.com] > Sent: Friday, January 16, 2009 4:49 AM > To: Carol Hebert > Cc: ipmitool-devel@lists.sourceforge.net > Subject: Re: [Ipmitool-devel] Happy New Year, Happy New ipmitool > > Carol Hebert wrote: > >> Hi and Happy '09! >> >> To celebrate the New Year, I propose we start working on rolling >> ipmitool to v1.8.11 to include all the great fixes and patches folks >> have been sending in since last summer! Do you have a fix you've been >> using in your local ipmitool version? Send it in for review! Do you >> have a patch or an idea for some new functionality or support you'd like >> to see get into the tool? Send it in for review! >> > Well you did ask, so here ya go... > > I'm the author of collectl [see: http://collectl.sourceforge.net/], > which is a tool for doing system monitoring. A couple of the things I > think that sets it apart from others is it's very light-weight and that > it collects a very broad set of data, making it possible to drill down > and see what the state of all your system resources are any point in time. > > About 6 months ago I discovered ipmitool and now use it to monitor > temps, fans and power though I could see adding other resources as > well. My own problem with ipmitool is that while it's pretty > light-weight, it's not light-weight enough and so I had to give it its > own monitoring interval - I monitor most things every 10 seconds when > running as a daemon, though there are those who sample every 5 seconds > or even 1. I did some tests with ipmitool running at those frequencies > and there was just too much system load compared to collectl proper > which uses <0.1% and so I'm only sampling sensors every 2 minutes, which > I thought at first was reasonable. > > However since adding power sensor monitoring and watching the power > every second, just to see what's happening over short bursts of time, I > saw that sensor changes much more frequently than I thought it would. > Given all the interest in green computing I can see where more frequent > power monitoring would be a good thing. I even went as far to see what > it might take to query ipmi directly to save the overhead of running a > new instance of ipmitool every sample period but I think I can now > appreciate just how complex ipmi is and would prefer to continue to use > ipmitool as it already does a great job. > > So, as for an enhancement I'd like to see a way to run it at rates on > the order of a few seconds and not incur a lot of overhead. I'm basing > this on my assumption that the bulk of ipmitool's time is spent on > starting the image as well as establishing the internal communications > connection(s). If so, my logical conclusion would be there needs to be > a way to do the initialization one time and not exit. While I can think > of a few ways to do it, and I think the first is probably the easiest, > perhaps someone intimately familiar with ipmitool's innards such as > yourself would have better ways: > - run it as a daemon, allowing it to receive commands over a socket and > send the results back > - build some sort of library that could be called via something like > perl, once call to initialize and a second to query, probably others... > > In any event, if it turns out that sending/receiving the command to the > sensors is where all the is spent and startup is less of a big deal, > this whole discussion is moot. > > Anyhow, you DID ask... ;-) > -mark > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel >
------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
