Fiery

Do you mean the GPU Clock rate is stuck at 350 MHz, even when the GPU is under heavy load? Thanks, Fiery

Thank you for the feedback. Please make sure to use the default configuration settings for your Heatmaster 2, more specifically: Baud Rate: 57600 bps Parity: No Parity Byte Size: 8 Stop Bits: One Stop Bit You can alter the sensor labels only with the OSD Panel, LCD, SensorPanel and Desktop Gadget modules. On the Sensor page it's not possible to change the labels.

I'm not sure how can it be related, since in mini-monitor mode Samsung SPF devices simply work like any other USB device. Can you please check if G-sync breaks OSD Panel or SensorPanel as well? So disable the LCD module, and enable the OSD or SensorPanel instead.

There's no native (firmware) support for rotating the image in mini-monitor mode, so we would have to do the rotation at the end of the rendering process in AIDA64. And since Samsung frames also require compressing the rendered bitmap into JPEG, the overhead of the rotation + JPEG compression would be enermous It would have high impact on both CPU load and memory load.

You don't have to do anything else than enabling the mentioned option on the Stability page of the AIDA64 Preferences, and then restart AIDA64. Did you restart AIDA64 after altering that option? If yes, then do you have the USB driver installed for Heatmaster II? If yes, then please try to find the USB device on the Devices / USB Devices page in AIDA64, and copy-paste the information you can see in the bottom right window section into this topic.

Make sure to wait until September, when Skylake is unveiled

We've checked, and Microsoft's own Windows Phone Accelerometer sensor sample app shows the same measurements as AIDA64. I think the reason behind this oddity is in the last sentence of this quote: "The accelerometer measures the forces applied to the device at a moment in time. These forces can be used to determine in which direction the user is moving the device. The acceleration value is expressed as a 3-dimensional vector representing the acceleration components in the X, Y, and Z axes in gravitational units. The orientation of the acceleration is relative to the device such that -1g is applied in the Z-axis when the device is face up on a level table and -1g is applied to the Y-axis when the device is placed perpendicular to the table top. The accelerometer sensor detects the force of gravity along with any forces resulting from the movement of the phone. The combined motion API, accessed using the Motion class, uses multiple device sensors to separate the gravity vector from the device acceleration and allows you to easily determine the current attitude (yaw, pitch, and roll) of the device." Source is MSDN: https://msdn.microsoft.com/en-us/library/windows/apps/ff431810(v=vs.105).aspx Regards, Fiery

Thank you for the test. We've checked it, and it seems DirectInput has been officially deprecated sometime before Windows 8 was launched. We will disable DirectInput detection under Windows Vista and later Windows versions in the next AIDA64 beta update.

The temperature labelled as "CPU" comes from the sensor chip that is integrated on the PCB of your motherboard. The issue sounds like an intermittent sensor chip malfunction, although such issues are very rare. I don't think it would qualify your motherboard for a RMA, but it may worth a try to call the store where you bought it in case it's still under warranty. Regards, Fiery

It's true. We will do the porting in the second half of this year. Windows 10 enables more information to be collected, so the ported app will show more details about your phone and tablet. It will work on Xbox and HoloLens as well. It will work on classic PCs too, but due to the sandboxing of UWP, it wouldn't make much sense to use the UWP app there, but instead it would be best to keep using the classic AIDA64 Windows software that could provide a lot more information on the hardware and software environment on classic Windows PCs. Project Astoria (Android --> Win10 porting) and Project Islandwood (iOS --> Win10 porting) could help those guys who never ported their existing Android or iOS app to Windows Phone. But we already have got a Windows Phone 8.1 AIDA64 app that we've designed from the ground up to enable easy porting to UWP, so for us the porting will be a very smooth process.

It depends on the actual bandwidth and latency performance of the CPU, but generally speaking, PhotoWorxx is more bandwidth bound than latency bound. And about your scores: the 2x increase is not really 2x, and the bandwidth difference isn't actually 2x either The reference FX-8350 system has got 2.3x more bandwidth than your tested system, and it obtained 1.84x of your score.

It seems way too hot. But that snippet is not from our software AIDA64, is it?

Thank you for posting your ideas. First of all, please note that Windows Phone platform uses a very strict sandboxing solution, so running apps like AIDA64 are almost completely isolated from the hardware and other running or installed apps. So an app can only detect such information that is covered by the WinRT API. In other words, it can only "see" such details of the hardware that Microsoft chooses to allow. And Microsoft does not allow us to access the following information about the hardware: - storage type, class, manufacturer, or generally speaking: any information on the storage hardware itself - CPU frequency range or CPU voltage configuration -- so overclocking your CPU from an app is not possible - any details on the WiFi or cellular controller chip/module - any details on the battery except for remaining battery life, battery level and battery state (charging/discharging) We could get over some of those limitations by using the backend hardware database of AIDA64, and we may do that in a future update. As for benchmarks, it's actually a very complicated issue. It's not that difficult to develop a benchmark for phones and tablets, but it's virtually impossible to show a single score that could represent the performance of the device. It's especially difficult to measure a stable score that doesn't vary a lot based on environmental conditions. For example, if you run a heavily multi-threaded CPU benchmark on your phone 5 or 10 times in quick successions, your SoC will heat up so much that it will have to throttle down to keep your device from overheating, and in effect the obtained scores will keep decreasing at each further run of the benchmark. And then there's this: http://www.forbes.com/sites/patrickmoorhead/2015/06/12/misunderstood-or-inappropriate-mobile-benchmarks-are-hurting-the-industry-and-consumers/ To sum up: I cannot promise you anything about AIDA64 mobile benchmarks at this time. Regards, Fiery

If you disable Samsung LCD support, you can alter the state of the keep-alive checkbox. Let me know if it works with or without the keep-alive option enabled.

Thank you. That would a great help, thanks in advance

Yes, the picture size used by the PhotoWorxx benchmark means that up to 384MB memory is utilized on a 8-thread CPU, so it's good enough to stress the L4 cache, even when its size is increased to 256MB in the future.

Please note that Odroid-Show features a very slow USB protocol, and it takes several seconds (!) to perform a single frame update. It's not really suitable for the AIDA64 LCD module. The only reason we've implemented support for Odroid-Show is because a passionate AIDA64 user requested support for it. It is possible to handle multiple LCD screens from a different vendor, without limitations on the number of simultaneous screens connected. It is also possible to handle multiple screens from the same vendor, but not for all screen types. The Odroid-Show LCD module supports only a single screen in AIDA64 for example, but you can use up to three picoLCD screens, up to three Trefon screens, up to two AlphaCool screens, up to two Logitech G15/G19 screens, etc. DisplayLink monitors are connected via USB, but they act like classic monitors. So you can define a Windows desktop for it, and you can use the SensorPanel on it. Please note that you can only use a single SensorPanel right now, so having multiple DisplayLink screens may not work out well in your case. DisplayLink performance should be just fine for the SensorPanel (that uses cca. 1 or 2 FPS update rate), but I'm not sure how it works with video playback. It should work smoothly too, but we never had a chance to try it out.

Thank you for the feedback. I'm afraid we have no information on how to handle the frame buttons. There's a good chance that they cannot be handled via the USB connection, but only the frame's built-in software can handle them.

Please let me know what keyboard and mouse you've got. It's most likely due to a bug in the DirectX driver of one of your input devices. Thanks, Fiery

Thank you for the feedback. I've updated the opening post.

For that purpose the AIDA64 PhotoWorxx benchmark may be the solution we can offer at this time. It is heavily multi-threaded, it uses integer code, and it utilizes all cache levels.

That is normal, and it's much better than the first generation eDRAM solution. Core i7-4770R: L4 cache latency = 76.2 ns. Our ZLib data compression benchmark uses the "best" compression method, so it's more CPU bound than memory/cache interface bound. It is not designed to show off the underlying cache architecture performance. Our PhotoWorxx image manipulation benchmarks should be better to reflect the performance gains you can get from the L4 cache, but you may need to limit the number of used CPU cores to 3 or 4 if you really want to see a big difference between Haswell and Broadwell-H. I'm afraid we have no plans about implementing a sorting benchmark. AIDA64 benchmarks are not designed to show off the performance gain coming from a particular hardware feature. So we will not develop a new benchmark method just to show off how great 128MB or 256MB L4 is. And actually, in general (non-gaming) use the L4 cache doesn't provide huge gains. BTW, some rumours state that with Skylake and Cannonlake the eDRAM will no longer act as a L4 cache, but more as a dedicated buffer (cache) for the iGPU. I'm not sure if that's true, it would be surprising if Intel made such a move.

You can find the mentioned new beta update to AIDA64 Extreme at: http://www.aida64.com/downloads/latesta64xebeta If you have a disconnection issue after a few seconds, make sure to enable the new keep-alive option, and then restart AIDA64.

Thank you for the info. As I've mentioned above, we'll get around that by adding one more option to enable/disable the latest "Keep alive" workaround. A new AIDA64 beta update including that fix will be rolled out in an hour or so.

Please cut us some slack. Samsung never provided a SDK or other programming manual for their picture frames. What AIDA64 does may not work with all SPF variants. Samsung made a lot of variants of those SPF frames, they offer multiple models with the same (e.g. "SPF-87H") designation, so it's a big mess. And since it's not documented (at least not publicly documented), for us it's a big headache to sort things out and find out what tricks do we have to use to support all the different SPF models out there. As you can see, a certain bug fix could help to get around issues with a particular SPF model, but in the same time the fix ruins it for others. It's not easy to go blindly, without documentation, but we're doing our best to sort out every single issue you guys are facing. It would be much easier for us to pull the plug and remove SPF support from AIDA64... As for your issue, if possible, please uninstall Samsung Frame Manager and install our libusb driver: http://download.aida64.com/resources/lcd/samsung_spf_lcd_driver.zip It should help, as long as you wouldn't bump into the issue Xixou is having now with the latest beta. But we'll get around that by adding one more option to enable/disable the latest "Keep alive" workaround.