* HFM.NET - Client Monitoring Application for Folding@Home *

New Version: 0.2.2 - Build 31 - Beta - Download

- md5: 9a0d3c858fc0c1bdd7fb2a68f152bd04

- sha1: 4eb65e8cb1b6ede4b7b35f4ec792a8de35bab4b3

Change Log

• Fix: Issue with Save As... function not using the file name supplied by the user in the Save As... Dialog. Was using current config file name instead... which in the case of a new configuration would result in an unhandled exception - Thanks augie!!!
  
  
• Change: Messages Window can now be closed using F7 key.
• Change: Now a single instance application (attempting to start HFM.exe again won't yield an exception, just a dialog telling you the app is already running).
• Change: User specific UI settings like log file splitter location, column indexes, and column sort are now being saved at the time they are changed... not just on application shutdown.
  
  
• Enhancement: HTML Summary now respects the 'Allways List Offline Clients Last' option.
• Enhancement: Add options to turn on/off the search for Duplicate User/Machine ID and Project (R/C/G) (HTML Summary reflects these changes as well).

Upgrading HFM to the latest release

• When upgrading HFM, please take the new Zip file and extract it to the same location as your current install and overwrite the older files.
  
  
• The user settings are tied to the location of the HFM.exe file. So if you move or otherwise rename any directory in the path to the HFM.exe file, you will lose your custom settings. Please choose your install location wisely, I recommend a very generic folder name like "\Program Files\HFM". Settings will also not follow the application from machine to machine. It is possible to transfer them and I will post instructions on how to do so at a later time.

Donate to the HFM.NET Project with PayPal


A major fix for a nasty bug I created. If you're auto-loading a default config file, you probably didn't experience it. Couple other quick changes and enhancements based on user feedback. Please upgrade to avoid any problems saving your configuration files.

Thank you again to the following people who have donated to the HFM.NET Project (no particular order... and I apologize if I've missed someone)

• cuda340
• David Fonda
• Michael Obermeier
• moltenrain
• David Dory
• George Stephen
• Zachary Glazer
• Jason Farque
• Michael Metcalf
• Charles Richards
• Timothy Hester
• ChelseaOilman
• LandShark

I think I figured out the problem, with mono. It is thinking my timezone is +5 GMT instead of -5 GMT. Then the -60 minutes gets turned into +60 minutes.

If you look it says my terminal time is 03, because FAH works on GMT. My clock is -5 hours. However in the message dialog it is saying 08 and then offset makes it 09. This then causes it to report hung because the times are 10-11 hours ahead.

harlam357 said:

I do apologize for you're trouble...

Click to expand...

Meh, it's a beta H and free too. I know not everything will go as it's supposed to, thanks for the quick fix!

Shelnutt2 said:

I think I figured out the problem, with mono. It is thinking my timezone is +5 GMT instead of -5 GMT. Then the -60 minutes gets turned into +60 minutes.

If you look it says my terminal time is 03, because FAH works on GMT. My clock is -5 hours. However in the message dialog it is saying 08 and then offset makes it 09. This then causes it to report hung because the times are 10-11 hours ahead.

Click to expand...

Actually, I parse the logs as if they are current UTC based on the current OS offset... unless the user checks the VM option. In that case, UTC is considered local time. Case in point, my notfred VMs are showing 00:53:00 right now... while my Ubuntu VMs are showing 05:53:00 right now in the FAH logs... but I'm -5 GMT. Anyway, the plan is to build in an option to deal with async clocks as FahMon has. It's just too tough to deal with these issues by adjusting an offset... although, I think there are still some EOL issues with Linux... I'll have to explore it more while I'm testing the new log parsing upgrades. I just commited a slew of code tonight... it won't help your log parsing... but it's moving toward unit testing more of the code... which needs done anyway. I'm working for sure... but it may be another couple weeks before you guys see another public build as things are generally stable right now... at least on the Windows front.

augie1111 said:

Meh, it's a beta H and free too. I know not everything will go as it's supposed to, thanks for the quick fix!

Click to expand...

You're welcome. I appreciate you bringing it to my attention.

Hi Harlam, same MtM as on foldingforum, registerd souly for this thread. I posted links to the latest source there, but I had to look for it and I''m doubting if it really was my most recent project file. Like you I have had a google code page for quite some time, I need to find my login details so I can cross check ( you can't browse repository without being a member so I can't compare right now ).

As said, allot of the issues you will find I can help you with, especially with new monitoring code and if you think hfm.net could incorperate the client control code I wrote for maxFah I'm more then happy to work with you porting it to c#. There are no licence issues, maxFah I wanted to be gpl3 anyway, and all my code has cleared cross checks with the people behind the queue.dat documentation for being based on the documentation and not being a straight port from qd.

My contact info is on FF.

Cheers, Marvin

Hey Marvin. Thanks for the heads up. I will get back with ya on FCF.

I thought this was your primary active forum so I registerd. I think I'm enjoying the prospect of being able to offer some help/ideas maybe instead of feeling pressure to finish my own project finally

Take your time though, I got plenty

ps, fcf ceased to exist quite some time ago!

Hehe... I appreciate your offer. I've taken a peak at some of the code you linked, but I haven't dove in deep yet. I didn't get over to FF.org last night... but I'll get back with ya there.

...and yes, I know... it's just old habit. FCF... FF.org... eh, it's all the same to me.

An Update for those looking for news and/or progress on the next HFM.NET Release: Been working, when I can, on some refactoring, unit tests, and an automated build server. There has been activity in the SVN repo as HFM is at Revision 37 (as opposed to the current Release Build 31). Not too much is going on with the front end yet, but what I'm doing now is making HFM.NET a more robust and verifiable program.

The following is still on the todo list for the next public release:

• Send E-mail or SMS text when detecting an EUE state.
• Dynamic Web Application Component (ASP.NET based WebApp fed data by HFM.NET client monitor).
• Auto-Run on Windows Startup option.
• Add Core Name and Core Version output to CompletedUnits.csv file.
• Add New Version Notification (possibly download and update as well).
• Option to show the entire FAHlog file in the HFM UI (in lieu of only the current WU).
• Others... and many 'under the hood' changes planned that I won't detail.

I guess you could say... I'm in the 'under the hood' stage right now.

ttt....

Thanks cuda! I was thinking a while ago... it might be nice to have a dedicated sub-forum here for HFM.NET. This is my home after all. Having this thread stickied would be a secondary or temporary option.

Hints for mods in green.

Otherwise, work is progressing on the next major release... I've changed a lot of code. Been running new builds on my box and haven't had any major issues. The SVN repo has been updated for anyone who wants to crank out an unofficial build.

My goal is to have a new build ready for distribution by this week... and to be honest I'd love to post it tomorrow. We'll just have to see how things go in the next couple days.

Playstation 3 monitoring?

I was brought over here through AtlasFolder's use of HFM, and now have it set up on my 4 PCs at home. Both of us are running Folding in hopes of a cure for the Huntington's Disease that is devastating our families.

I searched and didn't find a discussion of being able to get my Playstation 3 added as a client to HFM. I know we don't have any control over where the PS3 puts its folding log files and they're probably in a different format, so I'm not holding out much hope.

Any thoughts? Thanks.

Mike Brown

Hi Mike!

I hope you enjoy using HFM.NET... and I appreciate your support by using it.

To my knowledge there is no way to access a PS3's log files via Windows or CIFS mounts... but I may be wrong. Don't have a PS3 nor have I ever seen any log files.

So you are in fact correct that HFM.NET is not written to handle PS3 Clients or Core Executables. If anyone finds a way to access the logs from a PC (Windows or Linux) and can provide me with sample logs, I'll be happy to add support.

Harlam,
As the economy forces me to turn off some of my farm rigs, I thought of a feature you could add to HFM. I could use a hide inactive clients feature. I think you'd have to have a check box in the Add/Modify instance screen that let you set a client as inactive and under the edit/preferences a selection to hide clients set as inactive.
I like to be able to tell at a glance when a client stops running, but if I have 6 or 7 inactive clients at the bottom of the screen, an 8th one doesn't stand out. I don't want to delete the clients from HFM, because I fully intend to turn them back on.

Another issue I'm dealing with is several clients that for some reason are intermittantly shown as off line after a normal refresh. Manually refreshing them usually works. I've checked the clock on the problematic instances and it is spot on, so it's not a time offset issue.

This is from the messages:
Auto refresh:

[8/26/2009-9:57:07 AM] X HFM.Instances.ClientInstance.RetrievePathInstance (BEN VM2) The path \\Bar-vm2\fah\FAHLog.txt is inaccessible.
[8/26/2009-9:57:07 AM] - HFM.Instances.ClientInstance.Retrieve (BEN VM2) Client Status: Offline

Manual refresh:
[8/26/2009-10:05:14 AM] - HFM.Instances.ClientInstance.RetrievePathInstance (BEN VM2) Execution Time: 109 ms
[8/26/2009-10:05:14 AM] - HFM.Instances.ClientInstance.Retrieve (BEN VM2) Client Status: Running
[8/26/2009-10:05:14 AM] - HFM.Instances.FoldingInstanceCollection.FindDuplicates Execution Time: 0 ms

The auto refresh does refresh the log shown at the bottom of the screen even though HFM shows the client off line. Client files and the cached log are available at all times. It happens to both Ubuntu VM instances running on 2 different machines.

Perhaps I need to look at how the Ubuntu network settings are configured on those machines. Most VMs that I have are static IP and entered into the router address table. However, some are static and not entered in the table (outside dynamic range though), a few are DHCP, and if I missed it, some may have roaming enabled.

ChasR said:

Harlam,
As the economy forces me to turn off some of my farm rigs, I thought of a feature you could add to HFM. I could use a hide inactive clients feature. I think you'd have to have a check box in the Add/Modify instance screen that let you set a client as inactive and under the edit/preferences a selection to hide clients set as inactive.
I like to be able to tell at a glance when a client stops running, but if I have 6 or 7 inactive clients at the bottom of the screen, an 8th one doesn't stand out. I don't want to delete the clients from HFM, because I fully intend to turn them back on.

Click to expand...

I'll enter an Issue on this Charles... it's basically the same as the FahMon feature allowing clients to he 'disabled'.

However, in the meantime... you can take your current config, remove the unwanted clients, and then use the "Save As..." feature to save the altered config with a different filename. Then you can change the default config file to the newly saved config file. Make sure you don't have the "Auto-Save Config" option checked when doing this.. or it will overwrite the currently loaded config with every change.

This would allow you to keep your current config available, yet remove the clients you're taking offline without losing their config. In the meantime, if your new config changes and you wish to propagate those changes back to the original config... you can use a tool like DiffMerge (my favorite compare/merge utility). The config file is just an XML file... so it's easily readable by humans or other utilities.

In fact, the ability to create, load, save, save as multiple config files are intended to handle this 'disable' situation.

ChasR said:

Another issue I'm dealing with is several clients that for some reason are intermittantly shown as off line after a normal refresh. Manually refreshing them usually works. I've checked the clock on the problematic instances and it is spot on, so it's not a time offset issue.

This is from the messages:
Auto refresh:

[8/26/2009-9:57:07 AM] X HFM.Instances.ClientInstance.RetrievePathInstance (BEN VM2) The path \\Bar-vm2\fah\FAHLog.txt is inaccessible.
[8/26/2009-9:57:07 AM] - HFM.Instances.ClientInstance.Retrieve (BEN VM2) Client Status: Offline

Manual refresh:
[8/26/2009-10:05:14 AM] - HFM.Instances.ClientInstance.RetrievePathInstance (BEN VM2) Execution Time: 109 ms
[8/26/2009-10:05:14 AM] - HFM.Instances.ClientInstance.Retrieve (BEN VM2) Client Status: Running
[8/26/2009-10:05:14 AM] - HFM.Instances.FoldingInstanceCollection.FindDuplicates Execution Time: 0 ms

The auto refresh does refresh the log shown at the bottom of the screen even though HFM shows the client off line. Client files and the cached log are available at all times. It happens to both Ubuntu VM instances running on 2 different machines.

Perhaps I need to look at how the Ubuntu network settings are configured on those machines. Most VMs that I have are static IP and entered into the router address table. However, some are static and not entered in the table (outside dynamic range though), a few are DHCP, and if I missed it, some may have roaming enabled.

Click to expand...

Humm, the code here is a standard copy operation... nothing fancy. In the first section of log... HFM is reporting that it cannot access the path at all... which tells it that the machine is not available and thus is marked 'Offline'. In this case, no new log is copied and the log file text will not be updated. Once a monitored path cannot be reached... that's it. No other processing is done on that client.

The cached log file will be available from the last successful attempt to retrieve the log files... so that's normal. Why viewing client files works and accessing the logs through retrieval does not is a bit of a mystery... however, I do have some thoughts/experiences on this.

I experience some issues sometimes accessing the client logs, but it does not "time-out" as you're seeing here... it just takes a bit for the machine running HFM to, for lack of a better term, "get a lock" on the log file. I believe this is due to times when the log is being written to by the client while HFM is simultaneously attempting to copy the log file to the logcache folder. Let me stress that I see this same behavior of "waiting to get a lock" on the log file even if I'm try to do a Ctrl+C on a log file in the standard Windows Explorer... so I believe this is more of an OS/networking issue. Not something I can immediately control with HFM.

Now, there is another option I could explore... and it may of may not help this situation. I could try to open the file as a read-only stream and see if that helps the "locking"... as right now I'm relying on the OS to do the copying "streaming"... which speaks to what I said in the previous paragraph.

I'd be interested in HayseK or Atlas is seeing this... as they're the only ones I'm aware of using HFM with a comparable number of clients.

I'll enter an Issue on this as well... but let's try v0.3.0 when it gets released (hopefully this weekend). The log file itself will write a full exception trace for me now, so if this error continues it may give me a better idea of what's going on with that extra info.

As always... I appreciate your help and support!

i have noticed laggy refresh from time to time, but just ignored it. None of my rigs have fixed address, just default assigned by the D-Link router. what file/log do you need from me?

The "lag" seen in the refresh cycle I believe is due to the OS attempting to access a log file which is currently being written... I believe this is tied to the same issue ChasR is currently experiencing. I'll have to do more testing to prove this however.

I see the same thing, sometimes it take 50-60 seconds to complete the refresh cycle on 15-18 clients, with a couple clients generally being the culprit for the "lag". Then other times it only takes about 7-10 seconds to complete the same cycle.

One might see one or two clients showing something similar to the following in the Messages/HFM.log file.

[8/26/2009-10:05:14 AM] - HFM.Instances.ClientInstance.RetrievePathInstance (BEN VM2) Execution Time: 20,000 ms

Which means it took the client 20 seconds to retrieve the log files... these files are small, so it shouldn't take that long. But I'm sure this is happening at the point the Copy operation starts. If one turns the logging to Verbose and looks at the (copy start) and (copy finished) messages, you'll see that the Copy operation is definitely the point where the "lag" occurs. As NOTHING else is done on a client's retrieval cycle in between those two messages. This is even more easily seen if one turns on "In series (synchronous)" retrieval.

Again, I find this behavior the same even if in Windows Explorer (I just don't have a stop-watch on it).

Hayes... send me your current HFM.log file please.

Harlam my good man .. Hats off !! its an amazing app..

Two seconds to install .. import FaHmon Config file and hey presto .. didn't even miss a beat.

and whilst wondering why it was reporting I had processed 33,852 WU's when infact I have done 82 ! you have now introduced me to the wonders of the EOC Stats pages ... I am utterly addicted .

Cheers fella..

New Version: 0.3.0 - Revision 53 - Beta - Download

- md5: 9c7f1f2b20f0347bb09e4e1cafe81753

- sha1: fde168a5d04491da73058c0d1dc0ca56672913d8

Change Log

• Enhancement: Log Parsing... Log Parsing... Log Parsing... a new approach, more being identified, just a huge improvement in reliability and future enhancements.
• Enhancement: Add support for 'GettingWorkPacket' Status (Purple Status Color).
• Enhancement: Email Reporting - Configure a reporting Email Address and SMTP Server and option to report clients detected in a 24hr. EUE Pause state (not yet tested on live data).
• Enhancement: Encrypt sensetive data before storing in XML. This includes Host Server Passwords (encrypted the next time the configuration file is saved) and the following preferences fields: Proxy Server Password, SMTP Server Password, & HTML Output Folder or FTP URL (these fields will be encrypted on the first run of HFM v0.3.0).
• Enhancement: Support for Log Text Coloring. Current Color Key: Blue="Key" Line / Green=Frame Progress Line / Red=Core and Client Shutdown / Grey=Not Identified
• Enhancement: Add Auto-Run on Windows Startup option (tied to user account via reg key in HKCU).
• Enhancement: Update code to write Core Name and Core Version, Average Frame Time based on all frames, and upgrade support from previous file layout for CompletedUnits.csv.
• Enhancement: Indentify a Core Shutdown Result of "INTERRUPTED" and add these to the failed WU count.
  
  
• Fix: Altered code to use DateTimeStyle values specifically for Mono Framework. Mono does not appear to like the NoCurrentDateDefault style, which results in the DateTime.ParseExact method returning a DateTime equivalent to DateTime.MinValue. This yields a TimeOfDay equal to TimeSpan.Zero, which results in no frame durations being calculated. The bottom line... I BELIEVE THIS FIXES THE LOG PARSING ISSUES ON MONO!!!
• Fix: Use local volatile list in Messages Form to hold current Debug messages in lieu of accessing the current message lines from the TextBox. This appears to have solved the problem with messages that go "missing" from the Messages Form (most evident when running under the Mono Framework).
• Fix: Unhandled exception when double-clicking a client with the Ctrl key held down - Thanks ixor!
• Fix: Progress Column sorting. The value 100% was not being sorted properly (sorting was based on text value, now based on float value) - Thanks ixor!
• Fix: Benchmarks Form to use TableLayoutPanel. Now scales properly when using Large Fonts (120 DPI) - Thanks ixor!
• Fix: Project ID has to be known before any work unit data is added to the benchmarks data. Any data added by previous versions with a Project ID of 0 will be deleted upon entering the Benchmarks Form.
• Fix: Fixed a long standing bug that output an incorrect Expected Completion time on Instance web pages.
• Fix: Correct spelling of "occurred" in process start error messages (ProcessStartError Resource String).
• Fix: File name validation (as used by the Host Configuration Dialog). FAHlog.txt and unitinfo.txt file names could be entered with grossly unacceptable values.
  
  
• Change: Remove requirement for unitinfo.txt file to be present for log parsing to run.
• Change: Update Main Form and HTML Summary to draw "Unknown" when Download Time or Deadline is DateTime.MinValue.
• Change: SysTray Icon ToolTip to read "x Working Clients" and "x Non-Working Clients" to use the same nomenclature as the HTML Output.
• Change (for anyone building from source): ScriptedRelease config is the only config that runs Pre or Post Build events. It is to be used for CruiseControl.NET CI Server Builds. The standard Debug and Release configs are available to use without any third-party dependencies (MSBuild Community Tasks, NUnit, NCover, FxCop, etc). Set AssemblyVersion.cs Revision number to 0, only official releases should contain the Revision number. This file will be updated only with Major.Minor.Build from now on.

Upgrading HFM to the latest release

• When upgrading HFM, please take the new Zip file and extract it to the same location as your current install and overwrite the older files.
  
  
• The user settings are tied to the location of the HFM.exe file. So if you move or otherwise rename any directory in the path to the HFM.exe file, you will lose your custom settings. Please choose your install location wisely, I recommend a very generic folder name like "\Program Files\HFM".

Donate to the HFM.NET Project with PayPal


I've been quite busy getting this ready the last month or so. The code has gone through so many changes that the notes above really just touch on the highlights. I really can't say much of anything else... long time coming.

Thank you for using HFM.NET.

Enhancement: Log Parsing... Log Parsing... Log Parsing... a new approach, more being identified, just a huge improvement in reliability and future enhancements.

Click to expand...

Maybe, without looking at the new source, a thank you is in order

Ok, I cheated and did take a glance! Think you can improve allot of aspects, but I really should just download the trunk and do it myself maybe? I don't want to step on your toes though, so again I 'offer' not only the source but also the author's help? But, only officially, as in a direct co developer.

If you don't need the help that's also fine, you're doing a terrific job without me already but I feel it could only get better if you allowed some people to work on the source alongside you!

Edit:

To my knowledge there is no way to access a PS3's log files via Windows or CIFS mounts... but I may be wrong. Don't have a PS3 nor have I ever seen any log files.

Click to expand...

Just a confirmation this is not possible atm, and requires an update from the sony development team ( I know they are aware of it, but their concern was with security.. like there are no homebrew's for it already )

Edit2: Sorry Harlam, I spoke to soon ( as I said the frametime calcs looked familiar and I didn't look further then that so again my apologies ) and no thank you is in order ( yet I hope! ).

As I said on EOC, the queue.dat class holds much more then alone the queue.dat structure info and properties, it's the central monitoring class of my project which is again suspended. I think you might be improving on things now which if we bundle our resources can be replaced for a great deal anyway, but maybe I overestimate the integrity of my code compared to your/the original parsing code. I'm not trying to brag, if I were I wouldn't reference to my own 'suspended' project which in all honesty is probably just over my head to finish alone ( in my defense, I did aim for more then only a monitor and the monitor on it's own is not the part which gave me the biggest headaches ). I'm maybe not tactfull but I'm sincere in the offer, I think your code base is stable and very very usefull, and I hope you'll allow me to participate, or atleast add some functions already worked out in maxFah.

Sincerly, Marvin