Interview with HWiNFO creator. Arrow Lake? Remember to update

We sat down for a interview with the author of one of the most widely used diagnostic tools for monitoring computer hardware. Martin Malík talked about the ins and outs of HWiNFO. Although he doesn’t consider data processing to be rocket science himself, this article will certainly broaden the horizons of the average user. By the way, do you know what HWiNFO has in common with HWCooling? For example, the country of origin – Slovakia.

Many of you use the HWiNFO application to monitor various parameters of PC components, so we hope you will be interested in “what’s behind it”. We talked directly to its developer, Martin Malík, about the workings of and approach to one of the world’s most widely used diagnostic tools.

HWCooling: To start with a very basic question: How does HWiNFO know that the fourth core of a processor is at 75°C?

Martin Malík (HWiNFO): There is no magic in it. Manufacturers put a lot of sensors in processors – some are for public use, others are for internal use/diagnostics only. One just needs to know which of the thousands of hardware registers to read and how to interpret it correctly to provide a user-friendly value. You also need to know what exactly a given sensor/value represents. Modern processors can contain dozens of temperature sensors, but sometimes displaying too many sensors can actually be confusing.

On the other hand, oversimplification or abstraction can also lead to misinterpretation. As an example, consider Windows Task Manager, which displays the CPU clock speed as a single value. However, most users know that each core usually runs at a different clock speed, so there is no such thing as a single clock speed in a processor. So what does the value in Task Manager actually represent? Is it the average of the clock speeds of all the cores, the maximum value, or something else? It’s similar with temperatures – different sensors read the immediate temperature of different parts, and these are then combined (either as an average temperature over a certain time interval, or as a maximum value of the temperatures in a given area). If there are rapid changes in values (called peaks), it is usually more useful to know the average value (over a certain time interval) of the area. Thus, HWiNFO not only displays the values, but also tries to make sense of them so that the user knows what the values represent.

HWCooling: We know from our own observation that different diagnostic tools can report different values for the same sensor? What causes this and how does the user know that they are getting the correct information (e.g. from HWiNFO)?

Martin Malík (HWiNFO): Here it is difficult to give a definite answer without specifying the exact sensor and the differences observed. However, the most common difference may be that changes in hardware happen very quickly (e.g. a change in clock speed may occur in milliseconds) and no software can capture all these changes in real time. So if different software reads the rapidly changing values at different times, it may get different results. HWiNFO puts a lot of emphasis on the accuracy of the data, and I think it is also highly valued for this very feature. As one example, I can point to the rapidly changing CPU clock speed, called Effective Clock, more info here (link to thread on hwinfo.com forum).

HWCooling: If the reported value is sometimes obviously incorrect. Technically nothing in this context can be 1000+ degrees Celsius, but we have seen similar anomalies. What could be the reasons for them?

Martin Malík (HWiNFO): This may also have several causes. For example, it may be a momentary error in the sensor reading. Another problem may be that some sensors (or their interface) are not designed to allow synchronous access by multiple applications at the same time. If there is a situation where multiple applications access such a sensor at the same time (command-response, or read-after-write), there may be a conflict and misinterpretation of the command and the result. HWiNFO, as well as many other monitoring tools, have agreed and defined a simple synchronization mechanism (mutual exclusion/mutex) to prevent this conflict. However, this requires that all applications support this mechanism and use it correctly. Despite our great efforts to promote this mechanism (also with major vendors such as Asus AI Suite, Gigabyte SIV, MSI Core Center), some software vendors still either do not support this mechanism or have implemented it, but not correctly, which can cause other problems.

Another cause of incorrect readings (if the erroneous output is permanent) may be a sensor that does not have a probe attached. For example, motherboards use LPC/SIO chips that support multiple sensor inputs, but depending on the board, some of these inputs may not have sensors connected to them. Since there is no universal mechanism that can determine whether a given input is connected, it may happen that the value read from such a sensor seems correct (in which case it may be a floating value), or the result shows nonsensical values. HWiNFO tries to filter out sensors that appear to be unconnected, but the best way is to work with OEM/ODM manufacturers who provide detailed connectivity information for all sensors on the motherboard. This connectivity is often different for each board model, so you can probably imagine the amount of information needed just to get quality support for motherboards.

HWCooling: I will specify the situation around reporting different values across different diagnostic applications. It was a long time ago, but I still have a vivid memory that the Core Temp temperature sensors, at least on the Core i9-920 processor, were disagreeing, in terms of output, with both HWiNFO and I think HWMonitor (TechPowerUp!). At the time, I evaluated that it didn’t matter, because this error will hopefully always be the same and it doesn’t matter that much on the absolute value for the purposes of CPU cooler tests. So let’s talk specifically about temperature sensors. Why can it happen that their values don’t scale, application to application?

Martin Malík (HWiNFO): I don’t know if you are referring to the Core i7-920 (Nehalem/Bloomfield family), but there was a problem with interpreting the CPU core temperatures in the older generations. I will explain it in detail. Starting with the first generations of Core Duo/Solo (Yonah family), Intel added the so-called Digital Thermal Sensor (DTS), which allowed one to measure the temperatures of each core. However, these sensors were designed to be able to detect overheating and thus the value they reported was not the real-time temperature, but the difference from the maximum temperature at which clock speed reduction (thermal throttling) was supposed to occur. This maximum temperature is called Tj,max.

So in order for the software to report the current temperature it needed to know two things – the DTS sensor value (Distance to Tj,max) and the current Tj,max value for the processor. Tj,max is a constant that was different for each model and was set during production. Well, but since the manufacturer apparently didn’t expect so much public interest in real time temperature values, they didn’t build in a mechanism for older generations to find out the Tj,max for a given processor – it was only possible to know the DTS value (i.e. Distance to Tj,max), which the lower it was, the closer the processor was to the maximum temperature. The first temperature reporting tools tried in various ways (based on estimates and real observations) to estimate the correct value of Tj,max and thus also to calculate the real-time temperature value (t = Tj,max – DTS_value). However, this was often inaccurate, and it was found that in some cases it was not possible to estimate Tj,max for some processors with any guarantee.

Intel tried to fix this later by publishing Tj,max values for some CPU generations, but even this list was not accurate and even after several modifications (and adding some “flags” to the registers) it was not possible to determine the correct value for all models. It was this way of “estimating” Tj,max for a given CPU that caused the difference in temperature reporting between different programs – each used a different way of “estimating” Tj,max and then the resulting temperatures always differed by a constant value. These programs also allowed the user to define their own Tj,max value if they thought the program had got it wrong. It was only since the Nehalem generation that Intel added a register that reported the current Tj,max value for a given CPU and this solved the problem. Still, there was another problem that many users don’t know about – accuracy, or rather deviation. Each sensor operates according to certain characteristics depending on the design and calibration.

Since the first DTS sensors were designed to correctly detect CPU overheating, the emphasis in accuracy was on temperatures close to Tj,max, and for many sensors the accuracy decreased as the temperature dropped. This resulted in some generations of CPUs that, at temperatures below 50 °C, these DTS sensors virtually started reporting nonsensical readings and were thus almost unusable. Intel, after realizing the interest in tracking real-time temperature, started to improve the accuracy of DTS and from Nehalem/Sandy Bridge onwards achieved acceptable accuracy. AMD had a similar “flaw” with older generation CPU/APUs, where the sensor reported values on some “arbitrary” scale (not in °C) and since nobody knew what scale it was, those sensors were practically unusable. It was only since the Zen generation that dozens of sensors were implemented that were also accurate enough. Some reported the current value of a given sensor, others the maximum of a certain area, and still others the average over a certain time. More information here (link to a thread on hwinfo.com forum).

HWCooling: Following up on the previous question… is it somehow possible to write in simple terms why the user can be sure that HWiNFO reports values accurately?

Martin Malík (HWiNFO): That’s quite a trick question (laughs). In the real world, nothing is absolutely accurate, and also each measurement itself can affect the system being measured. With software like HWiNFO, we are limited mainly by two factors – the accuracy and capabilities of the hardware in question and information from the manufacturer.

I dare not claim that the values in HWiNFO are always accurate, but given the amount of effort put into development and the emphasis placed on obtaining information as optimally and accurately as possible, I would venture to say that HWiNFO is clearly among the top. I will leave the final judgment up to the users, and I think that the feedback, from professional users as well (such as the manufacturers themselves, who often use HWiNFO as a validation tool) or overclockers (who place a lot of emphasis on the accuracy of the data), is very positive.

HWCooling: Sorry, but I’ll again ask about the temperatures (HWCooling… (laugh)): The GPU Memory Junction Temperature sensor was added later, initially HWiNFO didn’t report it and so we didn’t have much of an idea of VRAM temperatures. I assume that again there will be some complexities behind this, also considering that most applications in current versions still can’t read this sensor to this day I think? If I’m wrong, please correct me. Maybe this has already changed…

Martin Malík (HWiNFO): This value is not one of the “official” sensors provided to the public by the manufacturer. HWiNFO was the first tool that was able to display this value. As I mentioned earlier, many components contain various sensors, but not all of them are intended for public use. It’s not even that the manufacturers intended to hide the actual data, but rather how the layman public would interpret these values and what conclusions they would draw from it. If a value were to be misinterpreted and users started to panic and return products (RMAs) on the basis of that, it would have a very negative impact on business and that would be very undesirable. The “GPU Memory Junction Temperature” is quite a specific value as it is sensed inside the silicon (not on the surface) and hence we have to expect the temperature to be higher than other sensors. This is also how we had to explain it to users so that they don’t panic that their graphics cards will burn up. However, if this temperature reaches the threshold at which throttling occurs, then it is a different situation… this may mean that the design is unsatisfactory and needs to be improved… Although some users think that HWiNFO displays too many values and it is difficult to get a handle on it, it could display a much larger amount of data. However, the question we ask ourselves with each new sensor is how useful the sensor would be and whether it would cause misinterpretations.

HWCooling: Is there any of the displayed sensors that you consider important for HWiNFO that other diagnostic tools do not have? Conversely, is there something that you “can’t get into HWiNFO” and others “know how to do it”, if I ask like this… daftly? (laugh)

Martin Malík (HWiNFO): For example, the above mentioned temperature is among such unique ones. I would also mention detailed sensors from multiple voltage regulators (VRM/Digital PWM), C-State Residency, Performance Limiting Reasons, for AMD Zen/Navi it’s a lot of detailed sensors (TDC, EDC, individual core and CCD temperatures, IOD, SVI2/3 telemetry, PRD, and more), Windows Hardware Error Architecture (WHEA) informing about Correctable Errors, a lot of Embedded Controller specific values (e.g. ASUS VCore Latch). These are sensors that either no other program can display, or only in a limited way. We will be releasing a version with further unique sensors on certain systems in the near future. On the second question – I honestly don’t know of anything important that other software can do, but HWiNFO can’t. If you know of something, let me know. Just please don’t let it be the CPU clock speed from Task Manager (laugh).

HWCooling: Why can’t it be the CPU clock speed from Task Manager?

Martin Malík (HWiNFO): See the first answer.

HWCooling: What are the main things you need to address with motherboard manufacturers to be able to respond flexibly to new hardware? In the sense that HWiNFO will start to read some new sensors that have been added? How long and how complex is the process between “you learn about the new sensors” and “the new sensors are incorporated and functional in HWiNFO” anyway?

Martin Malík (HWiNFO): We mainly need to sort out LPC/SIO support first if it is some new model, then need to know the wiring of the sensors (temperature, voltages, fans) for each new motherboard model. This is because often, even if it is the same series, each model may use different wiring. Here, then, you can see, by the number of different variations, how many different designs/teams have worked on the boards. If the boards also support some special functions/sensors (e.g. implemented in EC), it is necessary to know the protocol and registers. That total implementation process varies and the duration depends on the number of new designs and features. It is days, even weeks for one manufacturer. Many manufacturers then test Beta versions of HWiNFO and give feedback on what needs to be modified. This process often starts weeks to months before the launch. For example, for new platforms coming out soon, we started implementing these sensors for some manufacturers in the spring.

HWCooling: HWiNFO differs from most other tools in that it also lists the effective clock speeds of the CPU cores. What does this metric express, how is it calculated, and what is it good for? We know about threads on your forum, but still… Do you have any TLDR on this for the most accurate interpretation?

Martin Malík (HWiNFO): Simply put – the Effective clock reflects the rapidly changing clock speed much better, all changes of which software cannot otherwise capture. It is not possible for software to read at the frequency (sampling) at which the clock speed can change and thus may not capture most of the values. Also, reading the current state requires the core to perform the operation and thus cannot remain in the inactive state it might otherwise be in (the observer effect). With Effective Clock, the reading is only performed at certain intervals and the CPU performs the sampling internally, so the observer effect is minimized. AMD Zen allows even more advanced reading methods (Snapshot polling) that further reduce the observer effect significantly.

HWCooling: How are the “Core Clocks (avg) [MHz]” values approached for Intel big.LITTLE processors? The average of which cores does this value include? Does it include the “efficient” (E) cores, or just the “performance” (P) cores?

Martin Malík (HWiNFO): At the moment it includes all cores, but it would probably make more sense to split them into P-core/E-core.

HWCooling: Is there a feature in HWiNFO that you have worked hard to implement, is useful, and you are sad that its presence is overlooked by users and they don’t use it much?

Martin Malík (HWiNFO): I guess I can’t answer this because I don’t have an accurate picture of which feature is used by how many users. It seems that even the DOS version is still used quite a bit (laughs).

HWCooling: Thank you for the very detailed answers. I think we’ll stop here, and I suppose the discussion can continue in the comments, with questions from our readers and HWiNFO users.

Martin Malík (HWiNFO): Thank you for the space.

English translation and edit by Jozef Dudáš