V7 Hardware monitoring / gpu compute enumeration

[GoogleCodeExporter]

First off: I don't think I need to say I like the proposed feature set and I 
know I am not alone. This will make allot of people happy, keep up the good 
work!

I've noticed that your envisioned future usability overlaps with what I been 
proposing/trying to put together or how ever one would like to describe it, and 
I acknowledge that your programming expertise is much higher then mine so I'm 
left with a question regarding feature set.

Some of the things you are currently not doing and I thought of being useful 
are gpu compute platform enumeration and device properties, ideally coupled 
with hardware monitoring. I feel this is a useful feature to include since it 
would be helpful to troubleshoot problems, as well as enhance the data mining 
capabilities and therefore the data available for the web back end you've 
mentioned.

For gpu enumeration you're free to use my code to save some time, there was a 
problem with cal detection on certain systems which was caused by some invalid 
casting but since I've rewritten the library with option strict it is now 
fixed. 

There is a hardware monitoring library you could use which would work for the 
greater subset of folding clients ( on this moment in time, if/when linux gpu 
folding would be officially supported I can for see a possible swing towards 
linux for every dedicated folding box ) 
[http://code.google.com/p/open-hardware-monitor/ here].

You would need to write a socket interface to enable sharing readings from 
other ( remote ) clients, or you could wait for 
[http://code.google.com/p/open-hardware-monitor/issues/detail?id=34&colspec=ID%2
0Type%20Status%20Stars%20Summary remote monitoring support in 
openhardwaremonitor itself]

If you feel you should not make this a core feature, maybe it's possible to add 
this through your plugin interface ( I have not looked at it with the .7 
revisions, I do not know if it's possible to add ui elements to the main form 
which would be a requirement to add hardware monitoring without the need to 
display a separate form )?

If you feel this could be a core feature, or if it would be possible to add 
this through a plugin if not a core feature, there is little incentive left for 
me to continue with my own project.

Original issue reported on code.google.com by mtm78.cf...@gmail.com on 12 Jan 2012 at 3:31

[GoogleCodeExporter]

Hey Marvin... been thinking about this some more and I'm more open to allowing 
some modification of the UI through plugins.  I'm going to mark this as 
Deferred for now but will come back to it.  I see you're moving ahead nicely 
with your application anyway. :) 

Original comment by harlam357 on 23 Mar 2012 at 2:57

• Changed state: Deferred

[GoogleCodeExporter]

Original comment by harlam357 on 23 Mar 2012 at 4:32

[GoogleCodeExporter]

Hi Harlam!

Sorry for the late reaction, I hadn't checked if I added this mail account to 
outlook and I missed your response entirely ( it's added now though ).

Actually, I been working on a backend more then the monitoring application. I 
even have to admit that I been using hfm for monitoring my local clients, and 
been thinking in what I need to change to make it a more viable statistics feed 
for my site. 

Basically, all what is needed is tie the two fields to the project, gpu and 
cpu. Then, it's possible to let the xml files be a feed input on their own but 
those have overhead in embedded information I wouldn't need ( only the frame 
summary and project summary, including the hardware properties ). 

This I could try out in a fork when I'm done with the site back end, done at 
least to the point where it can handle the incomming statistics. The statistics 
are more important then an alternative monitoring front end, and I believe it's 
going to probably benefit both of us if I wouldn't try and do both. I would 
also change the way you store history, so it also holds the hardware 
information ( enabling generating local statistics in the same manner as I do 
in my own project ), and I would finish those ppd/tpf graphs. At least I 
planned to, but the site is giving me more problems then expected ( shared 
hosting is more limited then my own development environment, and I had worked 
in the past on a dnn based solution which fails to install in my hosting 
provider ). Not sure when I'll give this a try, or even if you wouldn't 
consider doing some of this together ( I was hoping that if not initially, that 
when I showed you the results I could persuade you to either integrate it in 
the source code tree or allow me to extend functionality through a plugin 
system ).

I also had a suggestion, one which I hope you're already working on. The cpu 
overhead is currently, imo, way to high. I've seen it using a large factor more 
total cpu time then FAHControl, and I think it's easy to avoid when you change 
how you monitor the slots.

What I had in mind for my own project is discarding all scheduled updates 
except for log-updates start, and only do ondemand updates when needed. Since 
you have the slot status after the initial query, and the connection class 
which will notify you if a client disconnects, it should be possible to only 
listen to logout. That's how it was done in the past, and I don't think any 
benefit of having a continous feedback loop are worth the cpu usage I'm seeing. 
This might change when you add control options, as asking for a status before 
opening a context menu ( for instance ) might introduce to much lag. 

Also, maybe of interest for you is my summary page -> 
http://www.fahwatch7.net/psummary/

Or to be more precise, the webservice behind it which enables downloading 
project definitions either all known or single project, or all changes made to 
projects since the service was started.

The webservices also will include statistical information later, but one step 
at a time. Security is a work in progress for instance.

mojoPortal has less documentation then DNN, and I'm struggeling with 
integrating certain features right now. There is progress, but it's to steps 
forward one step back.

When I'm further along, I plan on releasing the code for the backend as gpl, 
excluding perhaps the code responsible for security if needed ( though, open 
source security can still work if I use a key based cryptography system ). 

Btw, added advantage of this endavour is that someone told me to apply for a 
webspark account at microsoft and because of that I now have access to all the 
goodies ( well not all, but allot more then what I had to make due with before 
).

Original comment by mtm78.cf...@gmail.com on 29 Mar 2012 at 9:46