Hi Jean, > On Thursday, February 20, 2014 9:49 PM, Jean Delvare <jdelvare@xxxxxxx> wrote: > >> which is very close to in4 (3.120). At one time it read: >> >> in4: >> in4_input: 3.140 > > There's something weird here: 3.140 isn't a integer multiple of 0.016, > so it is not possible that the IT8718F sensed that voltage value. Are > you sure this is the exact value reported by "sensors"? Or is it a > copy > and paste error? > Sorry about that. I relied upon my memory seeing such value once from "sensors" when it really was 3.104 and not 3.140. > > I have found a BIOS screenshot on the web (was hard to find): > http://img155.imageshack.us/img155/5831/dsc00004kz6.jpg > > Sample value there is 12.175 V. > > 12.302 - 12.175 = 0.127 > 12.365 - 12.175 = 0.190 > Early BIOS versions for this board didn't show the actual values for the sensors it monitors but instead it just displayed an "OK." This is true for the board's manual as well. I appreciate that you took your time to search the web when I had thought that I would never find one. Your search result only reiterated my previous guide suggestions that it is recommended to have at least 3 voltage samples to facilitate an accurate computation, which I myself should have been keen to follow, but I was feeling lucky at that time. :-) > The would suggests that the scaling factor isn't exactly 63/16 (3.9375) > but closer to 190/48 (3.9583.) However 190/48 doesn't map raw values to > BIOS values so that can't be it. > > Your original assumption was that 12.302 in the BIOS was 3.120 in > "sensors". I think actually 12.365 in the BIOS was 3.120 in > "sensors". > If you put some load on the CPU, you may be able to collect another in4 > value from "sensors" (presumably 3.104) that would match the 12.302 in > the BIOS. > > If I'm right then a scaling factor that would work would be somewhere > between 12.302/3.104 and 12.365/3.120, i.e. 3.9633. Note that this > isn't the first time this strange scaling factors shows up for Gigabyte > boards: > http://jdelvare.nerim.net/devel/lm-sensors/config/sensors3-Gigabyte-7N400-Pro2.conf > http://jdelvare.nerim.net/devel/lm-sensors/config/sensors3-Gigabyte-890GPA-UD3H.conf > http://www.lm-sensors.org/wiki/Configurations/Gigabyte/EX38-DS4 > > So I would go with: > > compute in4 @*3.9633, @/3.9633 > > It maps the values seen in the BIOS with actual register values: > > 192 * 0.016 * 3.9633 = 12.175 > 194 * 0.016 * 3.9633 = 12.302 > 195 * 0.016 * 3.9633 = 12.365 > You are correct about 3.104. I realize that it is not always the case that the formula one arrives at while following your guide maps raw values to BIOS values. In such special cases, one can try to find a correlation between BIOS values and "sensors" values like what you did above. > >> I'm now faced with the problem of determining +5V scaling, which is not > even present in the BIOS monitoring section. Even if it were present, how could > I determine which unscaled sensor input to match it up if in3, in5, in6, and in7 > are all 4.080V? > > You can't. All evidence indicates that +5V is not monitored on this > motherboard. > I'll have to let go of +5V monitoring then. > >> Regarding temperatures, temp1 and temp2 don't look right. How can this > invalid reading be rectified if possible? > > The BIOS shows a single temperature, so I'm afraid temp3 is the CPU > temperature and temp1 and temp2 aren't connected. > I was expecting fan1 corresponds to temp1, fan2 to temp2 and so on, but in a perfect world that would have been the rule. This board is an oddball but I'm glad that I tried setting up sensors on it. This exercise has shown me that motherboard vendors don't always follow convention when it comes to sensors implementation. Moreover, there's a reason why some people would say "Linux people know their hardware inside out" when one works closely with it. I can personally understand that reason the more I work my way inside Linux and with the underlying hardware as well. I can now recommended to others that when using third-party monitoring software, to take the software's monitoring data with a grain of salt, use the vendor-supplied monitoring suite instead, or even better, go Free/Open Source Software. :-) I will send in my configuration for this board as soon as I can finalize it. Thank you for your valuable insights once again Jean. ianp _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
