Option to adjust polling cycle time

[GoogleCodeExporter]

Updating every 3 or 5 seconds would be plenty for me.

Original issue reported on code.google.com by old...@ymail.com on 8 Jun 2011 at 5:52

[GoogleCodeExporter]

Allowing the user to specify the polling interval would be preferable.

In most cases (unless you are actively troubleshooting a problem) anything 
faster than 10 seconds provides no added value whatsoever and just needlessly 
eats more CPU and GPU cycles.

This is especially true in programs that do not provide any alarm, email, "run 
program 'xyz'", or auto-shutdown capability when a monitored parameter is 
"outside of limits".

Original comment by transgen...@gmail.com on 12 Sep 2011 at 6:54

[GoogleCodeExporter]

Sorry if this triggers extra emails, but I wanted to make clear that my 
"preferable" statement was meant that users should be able to input (specify) 
their OWN desired interval...not just choose from a limited list of intervals 
as we see in some of these kinds of monitoring programs.

e.g. don't just let a user choose from between a limited list ( )1sec, ( )5sec, 
( )10sec, etc Let the user input a value...probably in seconds. Just assigning 
a single byte to store this value would allow the user to choose anywhere from 
1 second to over 4 minutes between samples with a 1 second granularity.

Original comment by transgen...@gmail.com on 12 Sep 2011 at 7:14

[GoogleCodeExporter]

My vote for this one. This is a much missing setting for me. I think predefined 
intervals would suffice - like the windows task manager for instance.

Original comment by ania...@gmail.com on 18 Jan 2012 at 5:50

[GoogleCodeExporter]

Just found out that Optimus graphics on my Thinkpad T430 drain 125% more power 
(18w instead of 8w!) when running OHM due to the high polling frequency which 
keeps waking the GPU, so I can't really use OHM there without an enormous loss 
in battery life. Therefore, I just signed up to vote for this too. Very useful 
feature!

Original comment by franzdon...@gmail.com on 30 Jun 2012 at 8:07

[GoogleCodeExporter]

Hello there. Me again. I read this comment yesterday 
(http://openhardwaremonitor.org/news/release-version-0-5-1-beta/comment-page-1/#
comment-4203) and was concerned for my drive that (as I now know) suffers from 
overfrequent head parking and excessive load cycle count - common to HDD for 
the mobile PC today.

Now considering this temperature polling can interfere with, and adversely 
affect its hardware operation, may we suggest higher priority to this issue?

Original comment by ania...@gmail.com on 26 Sep 2012 at 1:58

[GoogleCodeExporter]

I added a simple menu to set the update interval to any value between 10 and 
max int32 milliseconds, it is also saved in settings, so you don't need to set 
it every time
screenshots, compiled binary and source patch are attached

Original comment by spir.rob...@gmail.com on 9 Dec 2012 at 10:35

Attachments:

• update_interval1.png
• update_interval2.png
• update_interval.patch
• ohm_interval_binary.7z