Fiery

Please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> SMBus Dump (Full). Copy-paste the full results into this topic, or attach the results as a TXT file to your post. You may need to enable status bar in AIDA64 / main menu / View first. Also right-click on the bottom status bar of AIDA64 main window --> CPU Debug --> CPUID & MSR Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. Thanks, Fiery

Such monitors that you can connect to your PC using a DSub, DVI, HDMI or DisplayPort port, should be able to work as a secondary monitor and as an extension to the Windows Desktop. In which case you can use the SensorPanel module of AIDA64 to display sensor readings on any of the connected monitors.

As I've mentioned in email, we're already working on the bug fix. Please give us one or two days to investigate this rather strange and erratic bug.

I'm afraid we have no Supermicro X11 motherboards among the over 100 test motherboards we use daily to check out whether AIDA64 performs well on them. In case Supermicro could send us one sample of such a motherboard, we can work on it of course.

RComment is always filled with the Computer Comment (a.k.a. Computer Description) value that you can set in Windows / System Properties / Computer Name.

LCD exporting takes all LCD pages and writes them to the export file. If you open the .RSLCD files using Notepad for example, you can see that each page content is between similar tags like this: <LCDPAGE1> ... page content ... </LCDPAGE1> If you have multiple RemoteSensor layouts created, and you always used Page 1 in those layouts, and exported them to separate .RSLCD files, you should have LCDPAGE1 tags (and only those, not LCDPAGE2, LCDPAGE3, etc) in all those files. Problem is: when you import a layout, it will wipe your current layout, all pages of it, and import the page (or pages) from the .RSLCD file you select. Currently it's not possible to import a .RSLCD file into a page of your choice, so even if you alter the files to have different LCDPAGEx tags, you will only be able to import a file into a specific page but the rest of the pages will still be blank. What you can do to overcome this limitation is to combine the .RSLCD files into a single .RSLCD file where you use multiple page tags and put the relevant content between them. For example: <LCDVER>200</LCDVER><SWVER>6.20.5321 Beta</SWVER> <LCDBGCOLOR>16777215</LCDBGCOLOR> <LCDPAGE1> ... page content coming from one of your .RSLCD files ... </LCDPAGE1> <LCDPAGE2> ... page content coming from another one of your .RSLCD files ... </LCDPAGE2> <LCDPAGE3> ... page content coming from the 3rd .RSLCD file ... </LCDPAGE3> That way you can combine your .RSLCD layouts to exactly the page assignment of your choice.

IMHO it should be fairly easy to do that without altering AIDA64. For example, you can add the ISequel field to the Item table, and use a script to scan the table for multiple instances of "Monitor Name" and fill the ISequel fields accordingly. You only need to do it once, for those lines where ISequel is not yet filled in, so it shouldn't be a constant resource-hogging process to be running on your SQL server.

You can use the /LOCATION command-line option to pass your custom location and make AIDA64 write it into the RLocation field of the Report table. Example: AIDA64 /R null /DATABASE /HW /LOCATION MainHQ

It's not possible to cherry-pick from the reference results I'm afraid. And when it comes to "similar systems", it's not easy to decide which one is similar to the current system. You could go by CPU vendor, number of cores, CPU socket, CPU clock, etc.

The current way is fine for us.

RLocation was defined to help companies with multiple sites/locations manage their data. It's intentionally left empty so you can fill it up if you need that field for each report/computer.

The background (automatic) report creation process is designed to not slow the computer down. In case your users have difficulties using their computers while the report is being created in the background, then I suppose those PCs must be very old and very slow anyway. Is that the case? BTW, you can use the /IDLE command-line option to change the process priority of AIDA64 to idle, which could help to improve user experience during automatic background report creation.

It's not possible to assign an IID for everything that AIDA64 puts into the reports simply because then the number of IID's would be 100 times more than right now, and that would slow down the processing of reports by the Audit Manager and Change Manager modules of AIDA64. We keep adding new IID's on a case by case basis, per customer request.

It's completely logical, because the target report file in that case would be a text file with the .ADO extension. In that file AIDA64 will put an error message in case the report cannot be inserted into the database. Due to e.g. SQL misconfiguration or such. If you don't want to have that output, you can specify a non-existing filename that cannot be created anyway, like C:\?

It'd be best for you to put all Event Logs records into your database and then use SQL queries to filter them to your preferences.

We do not have plans to enable such filtering for the Event Logs page. You seem to be a corporate user of AIDA64, so once you've collected the reports you can filter them by using any criteria you wish, using e.g. SQL queries.

Please copy your AIDA64.INI file as AIDA64.TXT and send me that file attached to an email. I'll send you my email address in private message.

It looks quite impressive actually! As for your original question, L3 write bandwidth cannot scale as great as the read and copy because the CPU has to verify if there's a collision with other L3 cache segments in order to maintain cache coherency.

Thx

Meanwhile the bug fix has been rolled out as a new AIDA64 beta update: https://www.aida64.com/downloads/latesta64xebeta

We've checked it on our own Aquaero 5 Pro device, and it fails to work there either. I suspect in a recent firmware Aqua Computer removed this feature or revamped in a way that it became incompatible with AIDA64. We've sent an inquiry to our friends at Aqua Computer to find out how to solve this. I'll let you know in this topic once we've got a reply from them.

Memory latency is a key in the PhotoWorxx score. In which case when there are too many threads fighting for RAM access, scores can indeed drop heavily. So with this particular benchmarks it's not always best to have a lot of CPU threads at your disposal

I can only help you about AIDA64, I don't know the other tools. In what way can I help you? Please send me a private message about this, it will be easier to talk there about various issues.

I'm afraid I'm more confused about all that than ever before. If it's possible, please send me an email about this issue. I think you must have my email address from previous correspondance. But if not, just drop me a private message and we'll go from there.

The real fix or solution to this issue would be if NZXT came up with a SDK or some other solution where 3rd party apps could safely communicate with NZXT hardware, without having to worry about collisions with NZXT's own CAM software performing similar hardware polling.