<div>Hello again!</div><div> </div><div>Answering myself, may be this would help anybody else.</div><div>So the core reason is the quantum nature of the world, in this particular case - how fractional number are presented in IPMI.</div><div> </div><div>This is well described here: <a href="https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md#how-to-best-choose-coefficients">https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md#how-to-best-choose-coefficients</a></div><div> </div><div>By default the upper limit for power sensors is 3000, thus the discreteness of the sensor value just doesn't allow it to follow the "real" values read from  sysfs files.</div><div> </div><div>To fix this it's necessary to add custom real limits to entity manager configuration file.</div><div>In my case this looks like the following:</div><div>========================================</div><div><div>"pin_Name" : "VR_P0_PIN",</div><div>"pin_Min": 0.0,</div><div>"pin_Max": 252.0,</div><div>"pout1_Name" : "VR_P0_POUT",</div><div>"pout1_Min": 0.0,</div><div>"pout1_Max": 230.0,</div></div><div>========================================</div><div>The value of 252 Watts is taken from the power subsystem calculation, it's a bit more than the maximum value the VR can transform before shutdown.</div><div>The same limits are set for currents and volts, and now I have sensor value presentation precision that allows me to get a given VR efficiency.</div><div> </div><div>Thank you!</div><div> </div><div>15.05.2020, 09:23, "Konstantin Klubnichkin" <kitsok@yandex-team.ru>:</div><blockquote><div><p style="line-height:100%;margin-bottom:0in">Hello all!</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">I've noticed a strange behavior while integrating pmbus sensors into OpenBMC.</p><p style="line-height:100%;margin-bottom:0in">This phenomenon is observed on all power sensors provided by psusensor.</p><p style="line-height:100%;margin-bottom:0in">All this started from this patch:</p><p style="line-height:100%;margin-bottom:0in"><a href="https://github.com/openbmc/entity-manager/commit/24d30aea6468ef3358eab93714ead929271242d8">https://github.com/openbmc/entity-manager/commit/24d30aea6468ef3358eab93714ead929271242d8</a></p><p style="line-height:100%;margin-bottom:0in">Please note in the commit message that the efficiency of this PSU is 100% that is great but hard to believe :)</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">We also noticed the same: ipmitool gives the same values for PIN and POUT for a VR.</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">Then I started to dig deeper and found that values given by sensors command (i.e. directly read from the sysfs driver interface) differ from what we see in Dbus/RedFish, but this difference is more or less can be explained by rounding error and rapid value change. What is more strange is “big†difference of data in Dbus and ipmitool output for power readings.</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">Okay, to the configuration.</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">In our server entity manager configuration file we declare INA219 sensor. The driver is loaded via DTS as I use my dirty-hacked driver version that needs additional DTS parameters:</p><p style="line-height:100%;margin-bottom:0in">===============================================</p><p style="line-height:100%;margin-bottom:0in">{<!-- --></p><p style="line-height:100%;margin-bottom:0in">"Address": "0x45",</p><p style="line-height:100%;margin-bottom:0in">"Bus": 6,</p><p style="line-height:100%;margin-bottom:0in">"Type": "pmbus",</p><p style="line-height:100%;margin-bottom:0in">"Name": "SYS_PWR",</p><p style="line-height:100%;margin-bottom:0in">"power1_Name": "SYS_PWR",</p><p style="line-height:100%;margin-bottom:0in">"curr1_Name": "SYS_CURRENT",</p><p style="line-height:100%;margin-bottom:0in">"in1_Name": "BUS_12V",</p><p style="line-height:100%;margin-bottom:0in">"Labels": [ "power1", "curr1", "in1" ]</p><p style="line-height:100%;margin-bottom:0in">},</p><p style="line-height:100%;margin-bottom:0in">===============================================</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">Second HWMON is VR, this one is instantiated in user space as the driver is standard and VR can be overtaken by host:</p><p style="line-height:100%;margin-bottom:0in">===============================================</p><p style="line-height:100%;margin-bottom:0in">{<!-- --></p><p style="line-height:100%;margin-bottom:0in">"Address": "0x74",</p><p style="line-height:100%;margin-bottom:0in">"Bus": 22,</p><p style="line-height:100%;margin-bottom:0in">"Type": "pmbus",</p><p style="line-height:100%;margin-bottom:0in">"Name": "VR_P0",</p><p style="line-height:100%;margin-bottom:0in">"vin_Name": "VR_P0_VIN",</p><p style="line-height:100%;margin-bottom:0in">"vout1_Name": "VR_P0_VOUT",</p><p style="line-height:100%;margin-bottom:0in">"temp1_Name" : "VR_P0_TEMP_1",</p><p style="line-height:100%;margin-bottom:0in">"temp2_Name" : "VR_P0_TEMP_2",</p><p style="line-height:100%;margin-bottom:0in">"pin_Name" : "VR_P0_PIN",</p><p style="line-height:100%;margin-bottom:0in">"pout1_Name" : "VR_P0_POUT",</p><p style="line-height:100%;margin-bottom:0in">"iin_Name" : "VR_P0_IIN",</p><p style="line-height:100%;margin-bottom:0in">"iout1_Name" : "VR_P0_IOUT",</p><p style="line-height:100%;margin-bottom:0in">"Labels": [</p><p style="line-height:100%;margin-bottom:0in">"vin",</p><p style="line-height:100%;margin-bottom:0in">"vout1",</p><p style="line-height:100%;margin-bottom:0in">"temp1",</p><p style="line-height:100%;margin-bottom:0in">"temp2",</p><p style="line-height:100%;margin-bottom:0in">"pin",</p><p style="line-height:100%;margin-bottom:0in">"pout1",</p><p style="line-height:100%;margin-bottom:0in">"iin",</p><p style="line-height:100%;margin-bottom:0in">"iout1"</p><p style="line-height:100%;margin-bottom:0in">],</p><p style="line-height:100%;margin-bottom:0in">},</p><p style="line-height:100%;margin-bottom:0in">===============================================</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">Checking current values gives no suspicions:</p><p style="line-height:100%;margin-bottom:0in">===============================================</p><p style="line-height:100%;margin-bottom:0in"><a href="mailto:root@my8">root@my8</a>1:~# sensors ina219-* | grep curr1; busctl introspect --no-pager xyz.openbmc_project.PSUSensor /xyz/openbmc_project/sensors/current/SYS_CURRENT | grep "^.Value"; ipmitool sensor reading SYS_CURRENT</p><p style="line-height:100%;margin-bottom:0in">curr1: 12.20 A</p><p style="line-height:100%;margin-bottom:0in">.Value property d 12.24 emits-change writable</p><p style="line-height:100%;margin-bottom:0in">SYS_CURRENT | 12</p><p style="line-height:100%;margin-bottom:0in"><a href="mailto:root@my8">root@my8</a>1:~#</p><p style="line-height:100%;margin-bottom:0in">===============================================</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">But power values look worse:</p><p style="line-height:100%;margin-bottom:0in">===============================================</p><p style="line-height:100%;margin-bottom:0in"><a href="mailto:root@my8">root@my8</a>1:~# sensors ina219-* | grep power1; busctl introspect --no-pager xyz.openbmc_project.PSUSensor /xyz/openbmc_project/sensors/power/SYS_PWR | grep "^.Value"; ipmitool sensor reading SYS_PWR</p><p style="line-height:100%;margin-bottom:0in">power1: 115.20 W</p><p style="line-height:100%;margin-bottom:0in">.Value property d 158.4 emits-change writable</p><p style="line-height:100%;margin-bottom:0in">SYS_PWR | 141.600</p><p style="line-height:100%;margin-bottom:0in"><a href="mailto:root@my8">root@my8</a>1:~#</p><p style="line-height:100%;margin-bottom:0in">===============================================</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">I’ve done the above test several times and it looks like the value in ipmitool output has discrete values like 141.6 and 153.4 but can’t get value in between.</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">For the VR things are even worse as PIN is always equals to POUT:</p><p style="line-height:100%;margin-bottom:0in">===============================================</p><p style="line-height:100%;margin-bottom:0in"><a href="mailto:root@my8">root@my8</a>1:~# sensors pmbus-* | grep -E '(pin|pout)'; busctl introspect --no-pager xyz.openbmc_project.PSUSensor /xyz/openbmc_project/sensors/power/VR_P0_PIN | grep "^.Value"; busctl introspect --no-pager xyz.openbmc_project.PSUSensor /xyz/openbmc_project/sensors/power/VR_P0_POUT | grep "^.Value"; ipmitool sensor reading VR_P0_PIN VR_P0_POUT</p><p style="line-height:100%;margin-bottom:0in">pin: 26.00 W</p><p style="line-height:100%;margin-bottom:0in">pout1: 21.00 W</p><p style="line-height:100%;margin-bottom:0in">.Value property d 26 emits-change writable</p><p style="line-height:100%;margin-bottom:0in">.Value property d 21 emits-change writable</p><p style="line-height:100%;margin-bottom:0in">VR_P0_PIN | 23.600</p><p style="line-height:100%;margin-bottom:0in">VR_P0_POUT | 23.600</p><p style="line-height:100%;margin-bottom:0in"><a href="mailto:root@my8">root@my8</a>1:~#</p><p style="line-height:100%;margin-bottom:0in">===============================================</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">I think this is caused by the fractional numbers representation in IPMI itself, but can it be fixed?</p><p style="line-height:100%;margin-bottom:0in"> </p><p style="line-height:100%;margin-bottom:0in">Thank you!</p></div><div> </div><div>-- </div><div>Best regards,</div><div>Konstantin Klubnichkin,</div><div>lead firmware engineer,</div><div>server hardware R&D group,</div><div>Yandex Moscow office.</div><div>tel: +7-903-510-33-33</div><div> </div></blockquote><div> </div><div> </div><div>-- </div><div>Best regards,</div><div>Konstantin Klubnichkin,</div><div>lead firmware engineer,</div><div>server hardware R&D group,</div><div>Yandex Moscow office.</div><div>tel: +7-903-510-33-33</div><div> </div>