I don't know if this helps or not, but look at these timings. This first set is w/o using the cache, just to get a baseline:
[r...@hpdc3d001 ~]# time for i in `seq 1 10`; do ipmitool sdr >/dev/null; done real 0m20.204s user 0m0.005s sys 0m0.012s The good news is it used < 0.02 seconds of CPU but took over 20 seconds to execute. Now here's the same thing using the cache: [r...@hpdc3d001 ~]# time for i in `seq 1 10`; do ipmitool -S /tmp/xxx sdr >/dev/null; done real 0m19.802s user 0m0.003s sys 0m0.016s not a whole lot different! Is there a way to verify the cache is actually doing something? While I can't swear to it, I'm pretty sure back in the RHEL4 timeframe when I first started using this, I could do 720 iterations (the equivalent of once/2mins) w/ cache in under a minute. -mark >-----Original Message----- >From: Corey Minyard [mailto:miny...@acm.org] >Sent: Friday, March 26, 2010 8:43 AM >To: Seger, Mark >Cc: Ipmitool-devel@lists.sourceforge.net >Subject: Re: [Ipmitool-devel] performance questions > >Seger, Mark wrote: >>> Has the OS version changed? Maybe a driver change caused it. Or if >you >>> are running over the LAN, maybe networking changes? >>> >> >> Unfortunately I haven't a clue. This is standard RHEL5.3 so >everything is off-the-shelf. As for the communications path, I'm only >talking to the local machine. >> >Hmm, doesn't make much sense. Perhaps this has something to do with the >event log? As it fills up, going through the events may slow down. I >can't think of anything else, the driver shouldn't have changed. > >-corey > >> -mark >> >> >>> Seger, Mark wrote: >>> >>>> I've been using ipmitool inside my collectl monitoring tool for some >>>> time now and it's been fairly efficient, thanks to some >optimizations >>>> from this mailing list. However I've recently noticed it's gotten >much >>>> slower and I don't know if something has changed OR if it's the >actual >>>> hardware architecture that's doing this. >>>> >>>> Specifically I'm running 1.8.10 >>>> >>>> Before running it I do: >>>> >>>> ipmitool sdr dump xxx >>>> >>>> followed by >>>> >>>> ipmitool -S xxx sdr >>>> >>>> while it's using very little cpu time, it IS using a lot of elapsed >>>> time which makes me wonder if it is something about the system >>>> configuration. I do know for a fact that when I first started using >it >>>> with the cache, the cache I was able to get the runtimes much lower. >>>> >>>> My reason for asking is I do a mix of monitoring activities with >>>> collectl and gather the ipmi data only every couple of minutes, but >I >>>> something use a monitoring interval of 1 second for the other data >and >>>> the slowness of ipmitool prevents this. If it is what it is, so be >it >>>> but I just want to make sure it's not me. >>>> >>>> -mark >>>> >>>> >> >> ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
