Seger, Mark wrote: > 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? > Is this on the same hardware? That make a huge difference. Some systems cannot use the cache, but if they can it makes a huge difference.
-corey > 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
