What output is logging supposed to produce, and how often?

[DSperber]

I want to log only "UPS battery power" over time, which is represented by the File -> Preferences -> Logging -> Power Values -> Battery checkbox item.  I plan on replacing my video card with a much lower power card (at modest reduction in graphics performance) and want to see how much savings in electricity this has bought me as the machine is on 24/7.

 

So I unchecked everything in the Logging list except for that Battery item, and then checked the "Log sensor readings to HTML log file" and hit APPLY.

 

I don't know how often individual lines are supposed to be added to whatever HTML output is produced, but it appears that in one of the two HTML outputs a single line with the power wattage value is generated every 4 seconds (i.e. 15 times per minute, meaning 15 lines per group), which is my OSD update frequency.  This would be meaningful and informative if there were actually a date/time value also generated next to the power wattage value... BUT THERE IS NOT!

 

So there is no way at all to tell what the "raw" output items are, in terms of the date/time of that 4-second value.

 

Then, there is a second HTML output produced which appears to show a minimum and maximum value for the power wattage.  However although I assume this HTML file starts when I push APPLY with the LOG checkbox checked, and closes when I push APPLY with the LOG checkbox un-checked some minutes later, the content of the HTML file does not seem to indicate the date/time range during which this logging was taking place.

 

It's not clear whether I should see additional lines in that second HTML output (say one line for each minute?) or what?  There's certainly nothing in that second HTML file reflecting the ending time when I turned off the experimental logging activity, to see what I got.

 

 

So, my questions are simple: what am I expected to see if I leave logging on for 8 hours, with my OSD update frequency of 4 seconds?

 

I assume I'm supposed to be seeing something useful and helpful and informative, but so far I don't.  Instead, no matter how long I keep logging on before turning it off, I see two sets of two HTML files (LOG and STAT), with file name suffixes suggesting the date/time at which the files were opened.  The second set of two files is apparently created one minute after the first set of two files, and is eventually closed when I stop the logging function.  But the contents of these sets is truly worthless, in my opinion.

 

What am I doing wrong???

 

I'm attaching a sample of the two sets of HTML files (i.e. the two aforementioned sets of LOG/STAT HTML files) from a sample 5-minute logging period.  Note that the second set of two files has a file time of 04:09:32AM, matching the fact that I turned off logging five minutes after I turned it on (back at 04:04:44AM, which is built into the file name).  So this second set of HTML files is supposed to convey information for the five minute period during which logging was active.

 

Why was there the first set of HTML files also generated, with a file name including the what I guess is from just first second of logging...04:04:43AM?  Why was that first pair of files then closed, and the second set opened... which covered the next five minutes presumably?

Log_2014-08-12_04-04-43_log.htm

Log_2014-08-12_04-04-43_stat.htm

Log_2014-08-12_04-04-44_log.htm

Log_2014-08-12_04-04-44_stat.htm

[Fiery]

1) You need to enable the first 2 logging items (labelled as "Date" and "Time") to have a date+time stamp in the chart. Not all AIDA64 users need such columns in their logs, that's why they are not there all the time.

2) You can adjust the log file update frequency in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Update Frequency.

3) Whenever you make a change about logging settings in the Preferences, AIDA64 will start a new pair of log files. That's because things would get mixed up if you add or remove a column in the logs "on the fly". Once you're settled with your settings, just remove the partial, old log files, and keep just the latest one.

4) You're right, the statistical log file misses the logging start and logging finish time stamps. We'll add them in the next AIDA64 beta release due in a few days from now.

Thanks,

Fiery

[DSperber]

1) You need to enable the first 2 logging items (labelled as "Date" and "Time") to have a date+time stamp in the chart. Not all AIDA64 users need such columns in their logs, that's why they are not there all the time.

2) You can adjust the log file update frequency in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Update Frequency.

3) Whenever you make a change about logging settings in the Preferences, AIDA64 will start a new pair of log files. That's because things would get mixed up if you add or remove a column in the logs "on the fly". Once you're settled with your settings, just remove the partial, old log files, and keep just the latest one.

4) You're right, the statistical log file misses the logging start and logging finish time stamps. We'll add them in the next AIDA64 beta release due in a few days from now.

Thanks,

Fiery

 

Aha!  Date and time boxes should have been checked!  That was the secret.  I've also set my logging update frequency to 15 seconds, to reduce unnecessarily granular detail rows in LOG.

 

Entries look useful now.  Thank you.

 

As far as the STAT file, are you saying that while the actual logging session start/finish date/time values should clearly have been displayed as part of the titling content (which they will be in the next upcoming beta), that there will in fact only be one row max per STAT file as the total content of this HTML file?  Its purpose is strictly to show the minimum, maximum and average values during the entire course of the logging session, with a new pair of files started anew for each 24 hour period if logging goes on for longer than that since I have that value set?

 

There's no way to get one line in the STAT file for each 24 hours, and not create a new file?  What about having another checkbox that controls whether or not a new file is to be started at all, or whether just another additional min/max/avg row gets added to the one file every so often according to the separate specified number of hours frequency value?  I really don't necessarily want a huge number of files (if I leave logging on say for a month), but rather would just like a single large file with a separate row for each 24-hour period.

 

Just trying to understand what I should expect to see.

[Fiery]

Yes, the stat file now shows the log start and log finish time stamps. We've already rolled out the patched AIDA64 beta:

http://www.aida64.com/downloads/aida64extremebuild3114t0h8kqnryfzip

The lifetime of both log files are controlled by the option you've mentioned. In case you enable the date and time columns, and you use the above linked new beta, then you'll have all information in the log files to let you understand the logging time range covered by the log files.

[DSperber]

Yes, the stat file now shows the log start and log finish time stamps. We've already rolled out the patched AIDA64 beta:

http://www.aida64.com/downloads/aida64extremebuild3114t0h8kqnryfzip

The lifetime of both log files are controlled by the option you've mentioned. In case you enable the date and time columns, and you use the above linked new beta, then you'll have all information in the log files to let you understand the logging time range covered by the log files.

 

Thank you.

 

Could I suggest that both the log start and log finish time stamps be placed in the LOG file as well as the STAT file?  Seems like this information should be in both files.

 

For some reason you added only the log start to the LOG file but didn't also add the log finish.  In contrast you added both items to the STAT file.  Don't know why both items shouldn't appear in both log files.

[Fiery]

The log file is not re-created at each update, but only appended. That's why its header cannot be updated at each update. The stat file in contrast is re-created at each update, hence its header can be updated.

[DSperber]

The log file is not re-created at each update, but only appended. That's why its header cannot be updated at each update. The stat file in contrast is re-created at each update, hence its header can be updated.

 

How about just appending one this log finish final line at the end of the LOG file rather than requiring it to be up at the top where it really can't be placed at this time?  Then you'd be showing the same log start and log finish info that you place in the STAT file?

 

This would have the currently present log start line at the front of the LOG file and the currently missing log finish line at the end of the LOG file.  Perfectly fine with me, as long as both pieces of info are present in both log files.

 

I realize the information about log finish is probably close to the same date/time info as is implied in the final detail entry in the LOG file, and I probably don't absolutely need to see the official log finish line to know about when logging got stopped.  But just for "closure" it seems showing both start and finish "title items" in both LOG and STAT files makes sense to me.

 

I wouldn't care that it's the very final line of the LOG file rather than up at the top immediately following the log start line where it is placed in the STAT file.  I'd just really like to see that currently missing line present in the LOG file, indicating the precise time that logging was terminated and confirming that the logging process terminated normally (by the presence of this "closing" line in the LOG file).

[DSperber]

One last pitch for the one missing line to be added to the end of the LOG file... using "visual aids" to try and persuade you to do this one final tweak.

 

Here's what the STAT file looks like.  Note the START and FINISH lines, providing all of the relevant information about the logging session.  I recognize that the entire STAT file is produced all at once, when the logging session is terminated, hence why it's possible to put the FINISH line right after the START line.

 

 

 

And in contrast here's what the LOG file looks like.  Note the START line up at the beginning of the file which is physically there because that's produced at the beginning of the logging session, followed by an indefinitely growing list of detail lines over time, each generated at the specified logging update frequency.

 

 

 

Now I ask again why you cannot write one more line of data at the physical end of the LOG file, showing the FINISH info... exactly the same line as you show in the STAT file? The LOG file would then be closed, and you'd be able to see the START line up near the very top as a "report header", and also see the last detail lines then followed by the FINISH line, as a "report footer".

 

Doesn't this seem reasonable, to show both START and FINISH in both logging outputs??

 

Thanks.

[Fiery]

It will be sorted out in the next AIDA64 beta release due in 1 or 2 days from now I'll post a download link here once the new beta is available.

[Fiery]

We've further tweaked the log files header/footer, as requested. Please upgrade to the latest beta version of AIDA64 Extreme available at:

http://www.aida64.com/downloads/aida64extremebuild3120dwjf9t3lcpzip

Let me know how it works

[DSperber]

3120 doesn't seem to have made any change to the LOG file.  No "footer" record.

 

 

[Fiery]

It should be there But it's written there only when you close AIDA64 or it automatically opens a new log file.

[DSperber]

I don't understand the timing.

 

What I've posted is what got produced when I clicked on the "stop sensor logging" item on the popup menu from RMB on the Aida64 icon in System Tray.  That's when both files get closed and appear in the directory, and that's the date/time of the two file entries in the directory.

 

Why isn't the new footer record in the LOG file not written to the LOG file prior to issuing the CLOSE, which creates the file from the session I just ended??

 

What does this have to do with closing the program or opening a new log file??  I want to see the identical two STARTED/FINISHED information lines in both LOG and STAT files from a given logging session that I started and let run for a while and then ended.  I don't expect any additional information to be "deferred" until after the program itself is ended (which in my case is NEVER), or when opening a new log file (which may never happen if I choose to never start another logging session).

 

What am I missing about your design in implementing what you've coded so far?

[Fiery]

I'm sorry, that is just a pecularity of our implementation of the log closing. It doesn't put the footer there if you manually stop logging, since it treats the situation as you just suspend logging and may restart it again with the same log files. It will only put the footer there when AIDA64 itself stops the logging and closes the log file. We'll try to come up with a solution soon, although it's not easy, since there are many different issues colliding with each other in this case.

[DSperber]

I see.  Now that I've actually closed the program (with a logging session currently open) I can see your new generated last line in the LOG file.

 

 

 

However now I'm actually a bit confused as to how logging is supposed to be activated or not.  I had assumed it was a "dynamic" function, activated by selecting "start sensor logging" from the RMB context menu on the System Tray icon.  I had assumed that my checking in Preferences of "log to HTML" was simply choosing the HTML output option over say CSV output, not that this check actually automatically enabled logging when the program is started.

 

But now that I see what's happening (which is that when I RMB on the icon the choice presented immediately after launching the program is to "stop sensor logging", implying that it is already active... although I did not explicitly "start sensor logging" but instead only checked the HTML output choice in Preferences) I can see why I'm confused, and why the program behavior is other than I expected.  I thought I had to manually start it from the RMB menu, but apparently not.  Apparently is auto-starts at program launch because I had checked the "HTML output format" option box in Preferences.

 

I would have thought the Preferences option simply describes the type of output desired, and not simultaneously forces auto-start of logging when the program launches.  Perhaps there should be another checkbox on this same Logging tab, to actually request auto-start of logging when the program launches or not (if this new checkbox is not checked).  In the absence of this new checkbox not being checked, logging would NOT auto-start when the program launches, but rather must be manually initiated through the RMB context menu and selecting "start sensor logging".

 

In some circumstances, I suppose automatic launching of the logging function when the program starts might be desired, but I would think that most of the time this is NOT desired. And since I run Aida64 100% of the time, I really do want the ability to conveniently be able to start/stop a logging session without having to close/re-launch the program itself.  That's what I thought the RMB context menu items were for... to manually "start logging" and "stop logging", and that the "start logging" actually opened a new file (rather than resumed writing to an existing file), and that the "stop logging" actulaly closed the currently opened file (rather than just suspending logging but keeping the file open so as to facilitate later resuming of logging).

 

So, this is obviously my own confusion in understanding how this works.  Certainly there IS a "finished" line now added to the STAT file simply when I select the "stop logging" item on the RMB context menu, so I feel justified in expecting that same line to have also been written to the LOG file as a direct result of this action.  I feel justified in thinking this whole START/STOP process (using the RMB context menu items) to be like OPEN/CLOSE for a brand new pair of files, rather than RESUME/PAUSE for a one-and-only pair of files reflecting the program's instance.

 

Personally, I guess it is that ambiguity which stems from my checking of "HTML output format" which also seems to automatically launch logging when the program starts (and which is NOT what I expected or want) that is at the heart of the confusion.  Yes, I want HTML as opposed to CSV format output.  But I want the logging to be manually started and stopped by me, when I want to.  And each START/STOP pair produces a new pair of LOG/STAT files, with the proper STARTED/FINISHED lines showing in both LOG and STAT files... even with the program itself still remaining active and running across each of these event pairs that results in a distinct new pair of LOG/STAT files.

[DSperber]

I just gave beta build 3124 a try, thinking perhaps some additional adjustments might have been made to the logging functionality without a matching update post here in this thread.  Didn't happen.

 

So after experimenting with the related Preferences options as well as the RMB menu start/stop items, I honestly feel that the current logging behavior is confusing and seemingly inconsistent, although it may performing be exactly as you programmed it to work.  Which is why I'd like to again propose just a few small alterations and tweaks which (if others following this thread might "vote" agreement or disagreement) I feel would produce completely unambiguous and totally consistent and intuitive slightly altered new behavior.

 

Here is a description of currently implemented logging behavior along with my comments as well as suggestions for what I feel would be very beneficial user-friendly tweaks and adjustments. 

 

 

(1) The primary "problem" as I see it is that the current single checkbox in Preferences which designates the type of logging output is actually behaving as a two-function option controlling and activating both options, which makes it ambigous and undesirable as currently implemented:

 

a - choose the TYPE of logging output, either HTML or CSV and specify a path/filename prototype, and

 

b - automatically START the logging function when the Aida64 program is launched

 

 

But if the "log sensor readings" checkbox is UN-CHECKED while a non-blank path/filename prototype is still present, the logging function is NOT automatically started with Aida64 is launched.  Instead, initiating the logging session is deferred following program launch until the "start" item from the RMB menu is selected at which time the logging session is begun and a pair of initial LOG/STAT files for that logging session opened with the designated path/filename prototype used along with a current date/time filename suffix appended.

 

I think it would be clearer and more intuitive to the user if there actually were one more new logging checkbox option presented: "automatically start logging when Aida64 program is launched".  Having this new checkbox option available would clearly imply that a logging session is either to be started automatically along with Aida64 program launch, or not automatically started but rather deferred until a manually requested "start" is issued.

 

And that new second checkbox option would then clearly separate the other true preference option, which is to deisgnate the type of log file(s) format (HTML or CSV) and its path/filename prototype.

 

 

(2) The second "problem" as I see it is that there is no "finished" line guaranteed to always be added at the very end of the LOG file (as a "footer" record) if the RMB menu "stop" item is selected to stop the current logging session.  There is only guaranteed to be the "started" line at the top of the LOG file which got written when the current logging session began (either automatically at program launch of manually if the RMB menu "start" item was selected).

 

The "finished" line only appears at the very end of the LOG file if the Aida64 program itself is terminated while the logging function is still active.  It does not appear if the RMB menu "stop" item is selected earlier to stop the current logging session manually.  This makes for an inconsistent and confusing to the user LOG file output structure, which may or may not have the "finished" last line depending on how the logging session being tracked by the LOG/STAT files was ended.

 

In contrast, the "started" and "finished" lines ALWAYS appear at the top of the STAT file, even though the current logging session may actually still be active and in progress, and thus is not actually "finished" at all.  And yet, there is ALWAYS a pair of "started" and "finished" lines with the "finished" English words actually suggesting something that is not true since the logging session is actually still "in progress and active".

 

Furthermore, while the logging session is active the pair of LOG/STAT files is realtime updated (as a pair) at the logging update frequency specified in Preferences.  And each new set of updated LOG/STAT files shows a newly updated "finished" item in the STAT file which reflects the always increasing new date/time of the most recent update, whereas there is never a "finished" item shown in the ongoing LOG file (which does seem reasonable, since ongoing new LOG lines will be continually added at the bottom until the logging session is ended).

 

So looking at the STAT file while the current logging session is progressing, the "started" line remains fixed since the current logging session obviously started at some fixed time. However the "finished" line keeps changing, updated to the new current date/time at each logging update frequency interval.

 

And simuiltaneously, looking at the LOG file while the current logging session is progressing, the "started" line also remains fixed and there is never a "finished" (footer) record but rather only continually appended new detail logging lines.

 

 

(3) In my opinion if the logging session is still active so that the pair of LOG/STAT files is updated periodically at log update frequency, perhaps better and more appropriate English for that "finished" line in the ongoing updated STAT file (i.e. until the logging session is actually ended) might be something like "current last LOG entry" or similar.  This would more accurately convey the status of things, i.e. that the ongoing logging session is actually still active and not stopped/closed.

 

Only when the logging function is truly terminated (either temporarily with the RMB menu "stop" item or permanently by closing the Aida64 program) would a "finished" item be posted instead of the "current last LOG entry", thus conveying the implication that the logging session is truly ended and no longer active.  And now the "started" item would reflect the true time that the logging session started, and the "finished" item would truly reflect the time that the logging session ended... for the logging session monitored by the pair of LOG/STAT files.

 

 

(4) And for sure, when the current logging session is ended (either manually through RMB menu "stop" item or automatically by closing the Aida64 program) there should ALWAYS be a "finished" item added at the end of the LOG file (prior to issuing the CLOSE for the file) as a "footer" record, so that it always appears no matter how the logging session was ended.  There's no reason the LOG file should not be wrapped up when logging ends with this "footer" record showing the time that the logging session was ended, no matter how the session was ended.

 

Today, the "finished" item only appears if the method of logging termination is to close the Aida64 program while logging is still ongoing and active (which also forces logging to be automatically started when the Aida64 program is next launched!).  If the RMB menu "stop" item had previously been used to end the logging function, A - there is no "finished" footer line posted to LOG file which has now been CLOSE'd, and B - closing the Aida64 program also does result in the "finished" footer added to the already closed LOG file. 

 

Inconsistent and confusing not to see a "finished" footer record always appear in the LOG file to identify when exactly the logging session being tracked was ended.

 

 

(5) If logging is active because the "log sensor readings" checkbox was CHECKED, and the RMB menu "stop" item is used to end the current loggging session, and Preferences is examined, the "log sensor readings" checkbox will appear as UN-CHECKED.

 

However this Preferences appearance is only in-memory and temporary.  If the Aida64 program is closed at this moment the UN-CHECKED state of this option is NOT saved.

 

So the next time the Aida64 program is re-launched, the original CHECKED state of the option will once again be in effect, and thus logging will automatically be activated at program launch, even though the last thing done in the prior program instance was to "stop" logging.

 

Again, this is inconsistent and confusing and ambiguous to the user, because there essentially are TWO functions implied by the ONE checkbox option for logging... when there should really be TWO SEPARATE OPTIONS to control two separate user choices for controlling program behavior.

 

 

In summary...

 

There should be a distinct new option to control whether or not sensor logging is to automatically begin (or not) when the program is launched.  If this option is not checked then the RMB menu "start" item must be used sometime after the program is launched to manually start a logging session.  This new option is separate from the existing checkbox option which should be re-purposed to specifically designate the LOG/STAT file format (either HTML or CSV).

 

And again, no matter whether the logging session is automatically begun when the program is launched or manually begun using the RMB menu "start" item, and no matter whether the logging session is automatically ended when the Aida64 program is ended or manually ended when the RMB menu "stop" item is selected, there should ALWAYS be a "finished" item (shown as footer record in LOG file) present in both the LOG and STAT files.  It should not be sometimes missing.

 

And for cosmetic and user-friendly reasons the "finished" line that always currently appears in the STAT file (updated at regular logging update frequency throughout the still active logging session) no matter that the current session is still active and ongoing, I'd suggest an English change to show "current last LOG entry" rather than "finished" to more accurately convey the meaning of this date/time value.  Only at the end of the logging session might the English "finished" be used.

[Fiery]

I appreciate your attention to this issue, and the proposed ideas on how to improve the existing Logging feature of AIDA64. However, you have to understand a few things:

1) The logging facility was originally designed without an entry in the System Tray icon right-click menu. It wasn't meant to be stopped or suspended and then restarted again with a user interaction. And we haven't had complaints on the way it was implemented. Later on, a few users wanted us to make it suspendable and restartable via the System Tray icon. The current solution is in place for a few years now already, and it was only you, a single user who posted any complaints on the Logging feature. Most users simply find it clear and easy to follow, easy to use. While I do understand that you want to make it more clear for you, for most guys it is simply "good enough" currently, they can use it without issues.

2) If you check other Preferences options, related to other features of AIDA64, you can see that the way the logging options are implemented is completely consistent with other related features of AIDA64. For example, if you enable the OSD Panel or SensorPanel, they will automatically open once you start AIDA64, and they will close when you close AIDA64. You can open and close the SensorPanel from the System Tray icon right-click menu, but that wasn't found with criticism by other users as well. So, once you enable a specific Hardware Monitoring facility of AIDA64, they will always start once you start AIDA64, that's just the way they are supposed to work.

3) We'll fine-tune the "Logging Finished" tags at the end of the log files. It's not quite easy to swap an already written line there, simply because currently logging is implemented in an incremental way, so only appending the files is possible. That policy saves a lot of unnecessary writing to disks, which is quite important in the days of SSD drives. And when you suspend logging and AIDA64 would write a "Logging Suspended at XXXX" time stamp there, and you restart the logging, the file should be completely recreated in order to remove the "Logging Suspended at XXXX" line from there. Unless of course you would leave those lines there, which would make the log file quite ugly IMHO.