Fiery

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.

Did previous betas work before? Do you use the libusb driver?

Do you use the libusb driver? What SPF model do you have?

As far as I know, on Kepler/Maxwell GeForce GPUs it's not possible to measure the power draw in Watts. Regards, Fiery

Thank you http://www.aida64.com/news/aida64-turns-20-windows-phone-ios-mobile-apps AIDA64 for iOS Download: http://www.aida64.com/goto/?p=iosapp AIDA64 for Windows Phone Download: http://www.aida64.com/goto/?p=winapp

Your post came at just the right time to squeeze a new single line into the code before we rolled out the new beta update Thanks again

That seems like a very useful information, thanks a lot! We've already implemented it in the latest AIDA64 Extreme beta update available at: http://www.aida64.com/downloads/latesta64xebeta Let us know if it helps to fix the disconnection issue.

In case you want to push your reports into a SQL database, then you need to remove /CSV from your command-line, and add /DATABASE instead.

AIDA64 cannot measure drive activity, so you cannot put it on the SensorPanel either.

I don't think I can follow that If by Frame manager you mean Samsung Frame Manager software, then you have to uninstall all SPF-related Samsung software and driver before installing our LibUsb driver. Otherwise Samsung's software and driver may collide with our driver. But, in case you've figured it out and now things are stable, then it's great

Does the every 500ms there are "Device Vendor_Device" command - two zero bytes anomaly happen with both drivers?

No, it's not possible to monitor the uncore load level. Yes, you can use the Logitech Arx Control LCD module or the RemoteSensor LCD module of AIDA64: http://forums.aida64.com/topic/2610-logitech-arx-control-lcd-for-smartphones-and-tablets/ http://forums.aida64.com/topic/2636-remotesensor-lcd-for-smartphones-and-tablets/

Thank you. Do you use our LibUsb driver?