Seger, Mark wrote: >> 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. >> > > Exactly... That was my reason for the question(s). This is not the same > system and so I'm trying to figure out what's going on. Is there a way to > tell if the cache is working or if the system isn't capable of using it? > -mark > I don't know of an easy way, but to be truthful, I know a lot about IPMI, but not about ipmitool specifically. I'd say that this is pretty convincing evidence, though. This operation requires a GUID for the system and a "last change time" on the SDR repository to be implemented reliably. I believe those are both optional.
-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
