HFM.NET - Client Monitoring Application for Folding@Home

New Version: 0.4.5 - Revision 97 - Beta - Download (MSI) Download (Zip)

---

- For International Users that experienced the issue in v0.4.2.92 with Work Unit Credit being shown as 100 times (x 100) its correct value, please upgrade to this version to correct the problem along with the next instruction.

- Before starting v0.4.5.97, please go to the HFM.NET Application Data Folder and delete the ProjectInfo.tab file. Project Information will redownload correctly upon startup. If you do not delete the ProjectInfo.tab file, the issue will persist.

* HFM.NET Application Data Folder (example locations)

- Windows XP: C:\Documents and Settings\<username>\Application Data\HFM

- Vista / Windows 7: C:\Users\<username>\AppData\Roaming\HFM


Need help with HFM? Have a Feature Request? Please Join the Discussions. Post in the HFM Google Group.


http://groups.google.com/group/hfm-net
 
I'm having a strange issue, actually. One of my Linux SMP clients isn't being reported properly. HFM shows the client as being hung, and it shows this in the messages window:
[12/6/2009-5:55:01 PM] + HFM.Instances.ClientInstance.DetermineStatus (3. Secondary E2140)
[12/6/2009-5:55:01 PM] + - Retrieval Time (Date) ------- : 12/6/2009 5:55:01 PM
[12/6/2009-5:55:01 PM] + - Time Of Last Frame (TimeSpan) : 07:37:34
[12/6/2009-5:55:01 PM] + - Offset (Minutes) ------------ : 60
[12/6/2009-5:55:01 PM] + - Time Of Last Frame (Adjusted) : 06:37:34
[12/6/2009-5:55:01 PM] + - Prior Day Adjustment -------- : False
[12/6/2009-5:55:01 PM] + - Time Of Last Frame (Date) --- : 12/6/2009 6:37:34 AM
[12/6/2009-5:55:01 PM] + - Terminal Time (Date) -------- : 12/6/2009 5:18:51 PM
[12/6/2009-5:55:01 PM] + HFM.Instances.ClientInstance.DetermineAsyncStatus (3. Secondary E2140)
[12/6/2009-5:55:01 PM] + - Retrieval Time (Date) ------- : 12/6/2009 5:55:01 PM
[12/6/2009-5:55:01 PM] + - Time Of Last Unit Start ----- : 12/6/2009 5:53:11 PM
[12/6/2009-5:55:01 PM] + - Time Of Last Frame Progress - : 1/1/0001 12:00:00 AM
[12/6/2009-5:55:01 PM] + - Terminal Time (Date) -------- : 12/6/2009 5:18:51 PM
[12/6/2009-5:55:01 PM] - HFM.Instances.ClientInstance.Retrieve (3. Secondary E2140) Client Status: Hung
[12/6/2009-5:55:02 PM] + HFM.Instances.InstanceCollectionHelpers.FindDuplicates Execution Time: 0 ms
[12/6/2009-5:55:02 PM] + HFM.Instances.ProteinBenchmarkCollection.Serialize Execution Time: 12 ms

Notice the part that's bold and underlined. Any ideas?
 
Dammit man!!! :bang head Yeah, I see it. It should be looking at the 12/6/2009 5:53:11 value and it's not.

It's an freakin' two line change... uh, I really thought I had it worked out. Ok, we'll have a new build shortly. Basically it just means that 'RunningAsync' is half broken right now. :bang head
 
Just wanted to say thanks for all you do and how [H]ardcore this project is
We apreciate it!!
Posted via [H] Mobile Device
 
Still showing that weird datestamp...

It's not necessarily a weird Date Stamp... It's the absolute Minimum Value for the DateTime structure. Which I use as sort of an "Empty" Value.

Here's how it works, based on the log section you posted... HFM saw this unit begin at 12/6/2009 5:53:11 PM local time on the box that HFM is running on - this could be because you just restarted HFM (which I think is the case) or because a new unit began. At the time the Time Of Last Unit Start value was set, the Time Of Last Frame Progress value was cleared. This piece of data gets updated with the local time on the box that HFM is running on when frame progress is observed (green line in the log viewer). Until then, it remains the Minimum Value as described before.

Code:
[12/6/2009-5:55:01 PM] + HFM.Instances.ClientInstance.DetermineAsyncStatus (3. Secondary E2140)
[12/6/2009-5:55:01 PM] + - Retrieval Time (Date) ------- : 12/6/2009 5:55:01 PM
[12/6/2009-5:55:01 PM] + - Time Of Last Unit Start ----- : 12/6/2009 5:53:11 PM
[12/6/2009-5:55:01 PM] + - Time Of Last Frame Progress - : 1/1/0001 12:00:00 AM
[12/6/2009-5:55:01 PM] + - Terminal Time (Date) -------- : 12/6/2009 5:18:51 PM
[12/6/2009-5:55:01 PM] - HFM.Instances.ClientInstance.Retrieve (3. Secondary E2140) Client Status: Hung

So the question really isn't if that "weird" DateTime Stamp is being shown, but that the client is not being detected as "Hung". In that scenario above, it should have been given a 'RunningNoFrameTimes' status with a color of Yellow.

Can you confirm the correct behavior in v0.4.6.99?

Here's similar (and correct output) from one of my clients using v0.4.6.99.

Code:
[12/7/2009-1:14:05 PM] + HFM.Instances.ClientInstance.DetermineAsyncStatus (nVidia GPU - GTX285 - 1)
[12/7/2009-1:14:05 PM] +  - Retrieval Time (Date) ------- : 12/7/2009 1:14:05 PM
[12/7/2009-1:14:05 PM] +  - Time Of Last Unit Start ----- : 12/7/2009 1:13:28 PM
[12/7/2009-1:14:05 PM] +  - Time Of Last Frame Progress - : 1/1/0001 12:00:00 AM
[12/7/2009-1:14:05 PM] +  - Terminal Time (Date) -------- : 12/7/2009 1:10:07 PM
[12/7/2009-1:14:05 PM] - HFM.Instances.ClientInstance.Retrieve (nVidia GPU - GTX285 - 1) Client Status: RunningNoFrameTimes

Lastly, I must say Thank You Zero! This would have gone uncaught for a while (I'm sure) if you hadn't caught it. :)
 
I see. Well, it's actually working fine now, so I suppose it's all good :). That client takes a while to finish a percent (three GPU clients do take their toll, plus the overhead from WINE), so it took some time for everything to catch up and report correctly.
 
well i figured id bump this thread since its all the way on page 6.. but i also have a question..

everytime i restart my computer HFM completely resets so that i have to re-add the client.. also theres periods of time where it will refresh the client and then times where ill complete 5 WU's and i have to manually refresh it to show whats completed..

anyone got idea's on why this happens or is it normal? because i think i'll end up going back to fahspy if this is normal..
 
save the config after you re-add the client. Then go to Edit -> Preferences -> Startup -> Click on Load Config File and put in the path to the config file you saved. :)
 
Okay,

I just loaded up HFM.NET on a recently formatted box, so I've got a couple issues I wanted to mention. Since I'm not sure how to get in touch directly and since I've noticed a couple other bug reports being posted here, I'll just list what I've run across here (so far). ;)

First off, I have a network drive listed in my clients. The number of WU completed on this client is actually 2439 complete, but the software only shows up as 51 complete on this particular client. I have no idea where the number 51 comes from, it's only what I'm seeing. I've taken a screen shot if needed. I'm wondering if this isn't a network drive issue, or is it because I've racked up four digits worth of completed units on a particular install.

HFM_network_drive.png


Second is under Preference -> Web Settings. For some reason it will not allow me to input my username under teh EOC Stats option. I've got it successfully entered under the Stanford field and correctly changed my team number, but the only thing it will allow me to do under teh EOC field is delete the existing username, and not input my info.

Since I've just loaded this program up (been using FAHSpy for the most part) I'll keep looking for other issues and mention them here if I find any. :D It seems to be pretty nice overall and has a good feel to it. Might have to consider switching most of my status updates to this one as I get more familiar with it.

EDIT: I tried to do a copy & paste of my username, and it almost allowed me to do that. When I did the paste, it placed all but the last letter in my username in that block. (no "N"). Is this field chararcter limited?

Ax
 
Last edited:
its the EOC ID, search yourself and input the number in the url.


Edit: about the number of completed units, I know its working up to 300.
 
Your UserID for EOC is not your name.. it is your id number. Your user id number is 318677 - try putting that in and try again. :)
 
First off, I have a network drive listed in my clients. The number of WU completed on this client is actually 2439 complete, but the software only shows up as 51 complete on this particular client. I have no idea where the number 51 comes from, it's only what I'm seeing. I've taken a screen shot if needed. I'm wondering if this isn't a network drive issue, or is it because I've racked up four digits worth of completed units on a particular install.
Mine reset to 0 every time I have to restart the client. I've accepted it as a feature and not a bug.. I look at it as "ok, we've done 51 since I last started the client.. life is good" and move on. :D
 
Mine reset to 0 every time I have to restart the client. I've accepted it as a feature and not a bug.. I look at it as "ok, we've done 51 since I last started the client.. life is good" and move on. :D

Hmmmm, the only problem with taking that logic to heart is the fact that my network client showed up as 49 as soon as it was set up, and it had 2437 completed WU's at that point. :p
 
Then I am at a loss.. I'm not sure how it computes this value. As mentioned, I see a similar idiosyncrasies with this "feature" so it is probably something only the author can answer. :) I can say that it is unlikely to be a network issue or anything you can fix.
 
I also just noticed that the *failed* count was at "6" on that particular client as well. I wouldn't think that was the case, but I have run that particular setup for a *long* time so....I guess I could just clear out the work data and start fresh, to see if the issue corrected itself when I did that. Of course, that doesn't resolve the issue at hand either, so maybe I'll just wait in case the author needs more specific data from my work logs or something.

I do like the HFM.NET software so far though. I'll have to try out the web page generator and see how that works. Might be something I can do to finally compile *most* of my existing client data in to one spot.
 
It just counts the number of successful runs in the logfile instead of the "Number of units completed". I'm at 301 and the logfile reports 864, but my logfile .txt was cropped/corrupted at some point, so it starts off at 564.
 
the fail count is working correctly. Search for UNSTABLE_MACHINE and EARLY_UNIT_END in your logfile you should find these keywords 6 times out of the 57 shutdowns.

Sometimes when a card is messing around the fail count can go up quickly if its unstable at starting an unit.
 
Its the number of WUs since the client was restarted, ie the number of WU in the most recent session. not the number that the client has turned in total.

I use it as a feature, that way I know when one of my boxen has reset itself.
 
New Version: 0.4.8 - Revision 121 - Beta - Download

Wow! Happy New Year Everyone! I'm pleased to announce that version 0.4.7 of HFM.NET was the most popular yet, with more than 500 individual downloads!!! Lots of good stuff planned for 2010. Start off by updating to v0.4.8. This is an incremental update with a few fixes - primarily a pretty big bug that surfaces when mangled SMP Client logs are encountered. Check the HFM Google Code page for downloads and details on the changes.

---

Need help with HFM? Have a Feature Request? Please Join the Discussions. Post in the HFM Google Group.


http://groups.google.com/group/hfm-net
 
Excellent, I think I ran into that SMP log bug a few times, so this should help.
 
I'm having a problem. Before this I used to fold for another team. I stopped using one of my computers for folding before I switched, and I just turned it back on today. I reconfigured the log file, and started running it. I then added the client into HFM.NET. The problem is that HFM reports my Username and Team as the ones I used before, instead of my details for the [H]orde, even though I had reconfigured the client config file. It was a brand new work unit, nothing in the queue, and all the rest. FahSpy and FahMon both report my correct (i.e. current) details; it's just HFM.NET that gets the old ones.
 
I'm having a problem. Before this I used to fold for another team. I stopped using one of my computers for folding before I switched, and I just turned it back on today. I reconfigured the log file, and started running it. I then added the client into HFM.NET. The problem is that HFM reports my Username and Team as the ones I used before, instead of my details for the [H]orde, even though I had reconfigured the client config file. It was a brand new work unit, nothing in the queue, and all the rest. FahSpy and FahMon both report my correct (i.e. current) details; it's just HFM.NET that gets the old ones.

This is not a bug, but a decision on where to pull the Username and Team information. HFM will get those values from the queue.dat file if it's available. So if the WU was assigned while using the old Username and Team, then HFM will continue showing it that way until the next WU is assigned with the updated Username and Team. I have plans to change this to pull this data from the FAHlog file (if available) since it's always the "current" settings and only use the queue.dat data as a backup data source.

The other thing FahMon or FahSpy could be doing is pulling this info directly from the client.cfg file, idk. I just know that's where the information is actually stored.
 
fahspy is the same way.. when you change the user info you need to restart the F@H client for them to detect the new username in fahspy.. not sure about fahmon though..
 
I have a question. How does HFM calculate the bonuses? Does it just take the TPF into account, or does it work out the expected finish time and use deadline and assignment time data to calculate the bonus? i.e. if I restart an SMP unit after pausing for some time, would it take the paused time into account?
 
Very good question. I have been meaning to ask but never in front of computer when I have the question
 
Okay, from what I can tell it does the latter. I turned my computer off for 12 hours, and this morning after 4 frames ppd as calculated by HFM has dropped by about 4000, to around about where I'd be if I were running the SMP1 client on a notfred vm, even though frame times are almost exactly the same as they were yesterday afternoon.
 
Not sure what the newest version is, but I've tried 3 from the thread and all 3 won't start, installer or zip
sorry if this has been covered, I'm trying to install a new rig via remote on my phone and I've got the VM set up finally (and folding too)
but everytime I run hfm.net it shows this error, failed to initilize (sp) and gives a code with all 0's ending in 135

any help? Or newer version, but last 3 all did that
thanks!
Posted via [H] Mobile Device
 
Any advice?
Doing the same error on two rigs, both XP64, a tweaked build that you can sub out your own license # for (I've got a mass dis license for XP)

Its called SuperXP64, but I don't think anything was taken out besides auto updates (perfect for folding computers)
 
I have a question. How does HFM calculate the bonuses? Does it just take the TPF into account, or does it work out the expected finish time and use deadline and assignment time data to calculate the bonus? i.e. if I restart an SMP unit after pausing for some time, would it take the paused time into account?

Yes it uses the Download Time and the Current Time to estimate how long its been since the unit has been assigned... it then takes the ETA value and adds that time to the value determined in the first step to extrapolate an Estimated Finishing Time or EFT.

It then follows the formula that Stanford published publicly... the variable in the formula is the length of time the since the unit was downloaded till it is returned, so that's what the above estimates. What I can't accurately estimate at this time is the length of time it takes to upload the unit, which could be several minutes or longer. Stanford doesn't credit until the entire result is uploaded, and rightly so. So HFM's estimate will probably be a little on the high side. When I first implemented this I had the help of some mods at FF.org who sent me the actual credits I received for the bonus units I returned. In all cases the PPD and Credit HFM calculated was less than 1% higher than the actual credit Stanford credited. So... all I can say is, it's close. The only thing I could do to make it more accurate is try to estimate the upload time based on the average upload rate found in the queue.dat. At this time I'm undecided how or if I will attempt to implement this...

Not sure what the newest version is, but I've tried 3 from the thread and all 3 won't start, installer or zip
sorry if this has been covered, I'm trying to install a new rig via remote on my phone and I've got the VM set up finally (and folding too)
but everytime I run hfm.net it shows this error, failed to initilize (sp) and gives a code with all 0's ending in 135

any help? Or newer version, but last 3 all did that
thanks!
Posted via [H] Mobile Device

Can you send me some information, like a screen shot or a stack trace? Best to post it up at the HFM Google Group or send me an email. I'm always monitoring the Google Group and try to answer questions posted there within a couple days, usually sooner.

First thing, make sure the .NET Framework 2.0 or greater is installed.

---

Need help with HFM? Have a Feature Request? Please Join the Discussions. Post in the HFM Google Group.

http://groups.google.com/group/hfm-net
 
Damn, sorry to waste your time, it was the .net issue

I love this stripped down XP for folding on, really nice, but apparently they took that out

Working good on one rig now, should be fine on the others I would assume

Thanks!
 
Damn, sorry to waste your time, it was the .net issue

I love this stripped down XP for folding on, really nice, but apparently they took that out
I don't think the .NET framework is included with XP altogether. You always have to install it manually. Vista and Windows 7 do include it.
 
I thought it was in the newer service packs, but o well, I like to keep it lean and fast, nothing I don't need

saves a shitload on install time too :)
Posted via [H] Mobile Device
 
Back
Top