Fiery

Have you verified the STIME (entry in the Registry / SensorValues) update frequency with AIDA64 v1.50? We haven't changed anything around the update frequencies between AIDA64 v1.20 and v1.50, so I don't have an answer to your question at this time

The triangle is not there on your latest screen shot, but it was there on the previous screen shot. You need to enable the Registry feature in the Preferences (Hardware Monitoring / External Applications), and then you can expand the AIDA64 key to see the SensorValues key (which is a child of the AIDA64 key).

That shot clearly shows that the AIDA64 key has child keys (the little triangle there). Just expand that to see the SensorValues key.

Have you tried to expand the "AIDA64" key in the Registry? The SensorValues key should be a child of the AIDA64 key

The Registry checking was about the update frequency issue, not for the Alerting issue. Maybe you got confused, or you've started confusing things now

You mean you'd like AIDA64 to display data collected by other software?

Yes, AIDA64 implements better support for SSD drives than any Everest versions But it cannot fix the lack of temperature sensing logic implementation in OCZ Vertex 2 drives

AIDA64 (the motherboard sensor chip actually) cannot and won't check for power connection, it only senses the RPM wire.

Next time it happens, when after the configured alert items disappear, can you please check out on the Sensor page whether the fans in question can be detected spinning by AIDA64? Also, when that happens please check the AIDA64.INI file, if the configured alert items are still there or not. I suppose it may be because for whatever reason AIDA64 stops being able to find the watched fans at its startup, so it treats them as unconnected fan headers Thanks, Fiery

AIDA64 shows the MTU size configured for each network adapter. In case Windows' network interface layer overrides the MTU size, then Windows may reflect the wrong MTU size for the network adapter(s). Since AIDA64 uses the standard network interface (MIB), when the MTU size is unexpected, then it's the fault of Windows network interface actually

When those items are not there in the Preferences, are those fans spinning then? Not spinning (0 RPM) fans will not be collected by the AIDA64 Hardware Monitoring module, because AIDA64 treats "0 RPM" fans as unconnected fans, hence it will not poll them. But when you have a fan already configured, when it stops AIDA64 will of course fire an alert.

1) Update Frequency: we've just verified the update freq for the AIDA64 External Applications feature, and it works as expected, we haven't found any discrepancies. In case Rivatuner handles something wrong, then I suppose it's a bug in Rivatuner and not in AIDA64. You can actually verify the update frequency of the Ext.Apps feature if you enable the Registry support (AIDA64 / main menu / File / Preferences / Hardware Monitoring / External Applications / Enable writing sensor values to Registry), enable the Time item there, and then check out the published STIME value in the Registry at HKEY_CURRENT_USER\Software\FinalWire\AIDA64\SensorValues. 2) Fans: I'm not sure if I understand it, so please clarify. Do you have fans connected and spinning fine, but those fans sometimes disappear from the list of Alerting items in AIDA64 / main menu / File / Preferences / Alerting? Or you have the AIDA64 Alerting feature properly configured for those fans, but the actual alert is not fired when one of the fans stop spinning? Thanks, Fiery

1) Core temperatures are measured by the CPU itself, using Intel DTS. "CPU" temperature is measured by the motherboard, using the sensor chip mounted on your motherboard. Due to the fundamental difference on measuring methodology, it's not advised to compare core temperatures and "CPU" temperature. 2) As for the fan RPMs, please copy-paste the results of the following dumps and info into this topic: - Computer / Sensor page - right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> ISA Sensor Dump Thanks, Fiery

We've done several test runs on various Intel chipset based configurations, but couldn't reproduce this issue. We suspect it may be the fault of the SATA driver, since AIDA64 uses industry standard driver calls to collect disk temperature readouts. Have you tried to update the Intel SATA drivers? Have you seen the same issue with other tools like HD Sentinel or HWMonitor?

What version of Logitech drivers do you have installed?

Please compare the measured values against Asus' own hardware monitoring software called PC Probe II. If you can see any discrepancies there, please let me know. Thanks, Fiery

It will be implemented in the very next beta release of AIDA64. I'll post it into this topic, so you can give it a try

One of the differences between AIDA64 and the last release of EVEREST is that AIDA64 supports a lot of new hardware (e.g. Sandy Bridge processors, SSD drives, Radeon HD 6000 family, GeForce GTX 500 family, etc) that EVEREST doesn't. And that effectively means that -- unlike EVEREST -- AIDA64 is able to monitor those new hardware, hence it reads more information from new hardware.

We've never had such issues on our G15 and G19 keyboards. Can you please let us know which keyboard do you have, and what version of Logitech drivers do you have installed? BTW, have you tried to alter the option "Allow Program to Force Itself to Foreground on Display" in Logitech LCD Manager? That may be a solution for your issue. Thanks, Fiery

That's a good point. Fads, please try to switch the option "nVIDIA GPU SMBus access through ForceWare" option in AIDA64 / main menu / File / Preferences / Stability. That may bring back the missing sensor readings. Make sure to restart AIDA64 after altering that option.

1) Please copy-paste the full content of the Computer / Sensor page of AIDA64 into this topic. 2) Then right-click on the bottom status bar of AIDA64 main window --> Video Debug --> nVIDIA GPU Registers. Copy-paste the full results into this topic. 3) Finally, right-click on the bottom status bar of AIDA64 main window --> Video Debug --> nVIDIA SMBus Dump. Copy-paste the full results into this topic. Thanks, Fiery

As far as we know, APIC ID is assigned by the BIOS, so when the order is unusual or unexpected (even by Windows), it is the fault of the BIOS. If you want that to be fixed, then I suppose the only one to contact is the motherboard manufacturer. APIC ID is used by modern multi-processor kernels to identify the CPU cores and the CPU packages. In various situations a software (or the operating system itself) has to know which logical processor belongs to which CPU package, or which CPU core. I'm not sure why you brought that up. Thermal protection is managed by the processor itself, and it's a completely automatic process. Once a core is overheating, the CPU will immediately start throttling the affected core down. If it still doesn't help to lower the temperature of the affected core, the whole CPU package will shut down. Hence there's no real need to know which core is at fault, and no need to shut down the system manually at all. The whole APIC ID assignment business is managed by the BIOS, and interpreted by the operating system, and the APIC ID is not checked or verified or read by the CPU itself. Especially not when it comes to thermal protection mechanism The CPU itself knows which of its cores are which, and you don't need to know which is which. BTW, when a core is overheating inside a CPU package, it always affects the rest of the cores, especially for monolithic multi-core processors. Hence when core#0 overheats, it will also affect (heat up) every other cores in the same package.

Thank you. Please copy-paste the full content of the Computer / Sensor page of AIDA64 into this topic. Thanks, Fiery

1) Do you have any RAID arrays defined? 2) Do you have any external USB, eSATA or FireWire disk drives connected? 3) Have you tried disabling the SMART layer in Preferences / Stability? Thanks, Fiery

Thank you. Unfortunately for Asus P67 boards the sensor registers are inaccessible using standard methods, so we cannot use those dumps