Hi, here is my view of the problem >> 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.
Assuming you use IOL, there is some overhead in establishing the command. Asumming your are not, some time is spent spawning IPMITOOL as well, that's for sure, if you are not yet using IOL, I suggest you took a look at it, because it won't use any CPU cycles on your monitored system. >> A 1 second interval on the firmware level is fairly heavy use. That really depends on the MC used, on a H8S from the 2600 family, via NSCI (recent IOL OOB ) a command would take < 5 ms to run, and the ~30 Mhz controller, will deal with that easily. You will not be able to achieve this speed when starting IPMITOOL from the shell, with standard Linux (vs low latency or otherwise improved system timers) I guess that starting a process can't take less than 10ms. Via KCS or so, on some MCs you can sample sensors at ~10ms interval, note however, that the MC may use a lower sampling frequency internally, you may want to ask the vendor to avoid overkill monitoring. >> If so, my logical conclusion would be there needs to be a way to do the initialization one time and not exit. There is (or was) a 'shell' mode available for that, you could try that. Francois Isabelle -----Message d'origine----- De : Hall, Eric R [mailto:eric.r.h...@intel.com] Envoyé : 16 janvier 2009 10:10 À : Mark Seger Cc : ipmitool-devel@lists.sourceforge.net Objet : Re: [Ipmitool-devel] Happy New Year, Happy New ipmitool 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. 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. 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. RE: daemon. There is a bit of a security problem here. You might want to read the IPMI spec. before taking this path. 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
