Ok, to summarize.
Pros: * querying particular sensor is faster compared to current implementation * in case sensors share the same IPMI name, it's possible to retrieve specific sensor * Record IDs are always unique Cons: * Record IDs are dynamically allocated * Record IDs may and can change at any time The list above is just a summary and not meant to imply there are more pros or cons. Proposed implementation: * extend output of sdr list(all list outputs?) by adding column with Record IDs; this column will be added to the end(as the last one) not to break current output * # ipmitool sensor get INPUT; will accept either IPMI name(current implementation) or Record ID * perhaps even # ipmitool sensor reading INPUT; could/should be extended as well Examples: # ipmitool sdr list T_AMB | 20 degrees C | ok | 46 # ipmitool sensor get T_AMB or # ipmitool sencor get 0x46 Z. On Wed, Jan 4, 2012 at 3:28 AM, Albert Chu <ch...@llnl.gov> wrote: > Hi Hank, > > Perhaps I shouldn't have said, "in practice they don't". I should have > said, "SDRs don't change for many motherboards in many environments." > Is it the majority of people in the world w/ IPMI servers? My > perception is yes, but that's my guess. > > The question is, what is best for those users/customers? And given the > user/customer base of ipmitool, what is the best for ipmitool? For > reasons discussed earlier, I think selecting sensors via record-ID is > useful and worth the tradeoff risks you describe. That's my 2 cents. > > Al > > On Tue, 2012-01-03 at 16:55 -0800, Hank Bruning wrote: >> A large number of computers allow renumbering of the SDR records. In >> practice renumbering of sensor records has been done for more than a >> decade. The Intel MPCMM001 from 2001 was the first I can remember. >> Since then all major computer server vendors, Intel, HP, Dell, IBM, >> Fujitsu, Sun, SuperMicro (but not Apple or Lenovo) have had systems >> that renumber SDR records. This is Billions of dollars of hardware >> sold every year. Renumbering of the SDRs is a very common occurrence. >> >> You want the sensor names to be identical and have renumbering of the >> SDR. >> Use case. >> >> I'm going to use AdvancedMC modules as defined by PICMG because >> multiple hardware vendors make this hardware and there is no >> proprietary non IPMI things going on. >> >> Four identical AdvancedMC modules are plugged into a MicroTCA or >> AdvancedTCA carrier. They all have to get power from a common power >> bus and each one of them will have a voltage sensor for pin 84, >> Payload power which is +12 Volts. >> This voltage sensor should have the identical name for each of >> AdvancedMC modules. There is no advantage in having identical >> AdvancedMC modules with different sensor names. Yes, some vendors may >> name the sensor "12 Volt in" and some may call it "12 Volt Pin 84" but >> if the AdvancedMC modules are identical the sensor names should also >> be identical. Since the AdvancedMC modules can be plugged in at any >> time and there is no way to predict the number of sensor records for >> each AdvanceMC they must be renumbered. >> >> Hank >> JBlade >> >> >> >> On Tue, Jan 3, 2012 at 1:00 PM, Albert Chu <ch...@llnl.gov> wrote: >> On Tue, 2012-01-03 at 08:22 -0800, Hank Bruning wrote: >> > The SDR Record ids are dynamic and the same record may have >> a new >> > record ID by the time you read it on the screen and start a >> new >> > IPMITool. >> > >> > The SDR Record IDs are allowed to be renumbered per IPMI >> 2.0, Section >> > 33.8 SDR ‘Record IDs’ page 435. When the IPMC Controller >> reboots or >> > when the FRU population managed by the IPMC Controller >> changes the >> > SDRs most likely will be renumbered but the IPMI Controller >> is allowed >> > to renumber the records when ever it wants. >> >> While they can change, in practice they don't. It's a useful >> way to >> select sensors that several other projects support. I don't >> see why it >> couldn't be supported by ipmitool as an option. >> >> As a use case example, I've seen some motherboards that have >> duplicate >> sensors w/ the same name, so you can't select a specific >> sensor via >> ipmitool's current "get SENSORNAME" option. Here's one >> example of that >> situation. >> >> # ipmitool -I free sensor list >> Temp | -58.000 | degrees C | ok | na >> | na | na | 85.000 | 90.000 | na >> Temp | -59.000 | degrees C | ok | na >> | na | na | 85.000 | 90.000 | na >> Temp | 39.000 | degrees C | ok | na >> | na | na | na | na | na >> Ambient Temp | 21.000 | degrees C | ok | na >> | na | na | na | na | na >> Temp | na | degrees C | na | na >> | na | na | na | na | na >> Ambient Temp | na | degrees C | na | na >> | na | na | na | na | na >> Ambient Temp | 21.000 | degrees C | ok | na >> | 3.000 | 8.000 | 42.000 | 47.000 | na >> >> # ipmitool -I free sensor get Temp >> Locating sensor record... >> Sensor ID : Temp (0x1) >> Entity ID : 3.1 >> <snip> >> >> Al >> >> > Hank >> > JBlade >> > >> > On Tue, Jan 3, 2012 at 10:13 AM, Zdenek Styblik >> > <zdenek.styb...@gmail.com> wrote: >> > Hello, >> > >> > as subject suggests, my question is why ipmitool >> doesn't >> > display Record ID >> > anywhere in its output. Or have I only failed to >> look more >> > thoroughly? >> > The only thing it displays is Logical Number, if >> that's >> > correct term, >> > eg. ``Sensor ID: T_AMB (0xa5)'' >> > which is not the same thing. >> > >> > Why am I asking about Record ID? It seems it would, >> well it >> > can and >> > is, be useful for eg. looking up specific >> > sensor and fetching information about it. It also >> seems to be >> > crucial >> > for (fetching) Sensor Data Records. >> > >> > Thanks in advance, >> > Z. >> > >> > >> >> ------------------------------------------------------------------------------ >> > Write once. Port to many. >> > Get the SDK and tools to simplify cross-platform app >> > development. Create >> > new or port existing apps to sell to consumers >> worldwide. >> > Explore the >> > Intel AppUpSM program developer opportunity. >> > appdeveloper.intel.com/join >> > http://p.sf.net/sfu/intel-appdev >> > _______________________________________________ >> > Ipmitool-devel mailing list >> > Ipmitool-devel@lists.sourceforge.net >> > >> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel >> > >> -- >> Albert Chu >> ch...@llnl.gov >> Computer Scientist >> High Performance Systems Division >> Lawrence Livermore National Laboratory >> >> >> > -- > Albert Chu > ch...@llnl.gov > Computer Scientist > High Performance Systems Division > Lawrence Livermore National Laboratory > > ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
