FAH GPU Tracker V2

[Dead Things]

I have been using the Tracker for about a week now on one of my machines, and I must admit - I like it quite a lot! Didn't think I would, to be honest - but you've really done an excellent job with it.

I just have one question with regard to the native -oneunit setup. Every once in a while, Stanford's results server will take a little vacay. After a few failed uploads of a completed WU, the client will normally store it in queue and download a new WU anyway to work on. It will store as many completed WUs in queue (well, up to 10) as is needed until the results server comes back online - all the while, working away on new WUs.

Correct me if I'm wrong, but with the way you've set it up this won't happen. With the -oneunit flag always enabled, the client will not restart itself and download a new WU until the just-completed WU has been uploaded. Thus, if the results server is unavailable, the machine will sit idle until it comes back online.

Am I right about this? If so, is there a way to work around this so that if the results server goes kaput for a little while we don't suffer through every folder's worst fear: seeing "System Idle Process" at the top of their process tree!

Thanks - and I should qualify this as a minor gripe from somebody who has spent a week trying to find reasons to hate your software. You've done a truly outstanding job!

[LarkStarr]

aye I'm using this program too, to fold, everything integrated into an all in one program that's easy to set up? win.

The one thing I'd personally like to see, down the road, is a little more expansion of the gaming mode (into more general use ,almost like sreensaver mode) and perhaps a scheduler.

but honestly, everything is perfect otherwise. Thanks so much & keep up the good work!

[ilya]

Been having issues trying to update to 3.34, 3.33 is perfectly fine though, so I've stuck with that.

Downloading 3.34 and running it separately also just crashes and nothing shows up in the log file.

Here's a copy and paste of what gets put in the log file:

[17:34:01] FAH GPU Tracker v3.33 Startup
[17:34:01] --------------------------------------------------
[17:34:01] Detected OS: Windows XP
[17:34:02] Detected CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
[17:34:02] 4 Cores, 4 Threads, 2,400 MHz
[17:34:02] Attempting to update FAH GPU Tracker V2
[17:34:05] Updating Tracker..
[17:34:12] --------------------------------------------------
[17:34:12] FAH GPU Tracker v3.33 Startup
[17:34:12] --------------------------------------------------
[17:34:12] Detected OS: Windows XP
[17:34:13] Detected CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
[17:34:13] 4 Cores, 4 Threads, 2,400 MHz

[LarkStarr]

Actually as an amendment to my first post - I can't seem to start folding with R700 GPUs - it just errors out every time.

not too big of a deal for me though, at least at the moment.

[jedi95]

Originally Posted by ilya

Been having issues trying to update to 3.34, 3.33 is perfectly fine though, so I've stuck with that.

Downloading 3.34 and running it separately also just crashes and nothing shows up in the log file.

Here's a copy and paste of what gets put in the log file:

[17:34:01] FAH GPU Tracker v3.33 Startup
[17:34:01] --------------------------------------------------
[17:34:01] Detected OS: Windows XP
[17:34:02] Detected CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
[17:34:02] 4 Cores, 4 Threads, 2,400 MHz
[17:34:02] Attempting to update FAH GPU Tracker V2
[17:34:05] Updating Tracker..
[17:34:12] --------------------------------------------------
[17:34:12] FAH GPU Tracker v3.33 Startup
[17:34:12] --------------------------------------------------
[17:34:12] Detected OS: Windows XP
[17:34:13] Detected CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
[17:34:13] 4 Cores, 4 Threads, 2,400 MHz

Well, what that tells me is that it is crashing before the first log entry even appears. And since you have 3.33 working it can't be the usual cause of instant crash on startup. (not having .NET 3.5 installed) CPU detection is another likely possibility, but that entire function is enclosed in try/catch (so it should never cause a crash) Plus you have it working in 3.33, and I made no changes to CPU detection in 3.34

I have an idea of what might be causing this, but I have no way to test it on my end. This will be released in the next stable version, which I have no ETA on at this time.

[jedi95]

Originally Posted by Dead Things

I have been using the Tracker for about a week now on one of my machines, and I must admit - I like it quite a lot! Didn't think I would, to be honest - but you've really done an excellent job with it.

I just have one question with regard to the native -oneunit setup. Every once in a while, Stanford's results server will take a little vacay. After a few failed uploads of a completed WU, the client will normally store it in queue and download a new WU anyway to work on. It will store as many completed WUs in queue (well, up to 10) as is needed until the results server comes back online - all the while, working away on new WUs.

Correct me if I'm wrong, but with the way you've set it up this won't happen. With the -oneunit flag always enabled, the client will not restart itself and download a new WU until the just-completed WU has been uploaded. Thus, if the results server is unavailable, the machine will sit idle until it comes back online.

Am I right about this? If so, is there a way to work around this so that if the results server goes kaput for a little while we don't suffer through every folder's worst fear: seeing "System Idle Process" at the top of their process tree!

Thanks - and I should qualify this as a minor gripe from somebody who has spent a week trying to find reasons to hate your software. You've done a truly outstanding job!

You are absolutely correct about how that would work. A fix for this has been implemented in the latest beta. In the new version if a WU is waiting to upload the Tracker will stop the client, record the WU in the stats, then restart the client. The downside to this is that bonus credit will be calculated using the time the client is restarted, rather than the actual upload time. I figure that this small discrepancy is worth keeping the system busy.

NOTE:
If you do decide to get this version be warned that it has significant changes to the client control code, which may result in serious problems. There is a reason that changes like this go through beta testing before they end up in stable releases.

[jedi95]

Version 3.37 has been released!

This version fixes a crash on Windows XP that could occur when starting the Tracker, along with some other bugs. The main new feature in this release is that the Tracker will now detect WUs that won't upload due to server problems. In these cases the Tracker will restart the client so that it can get a new WU. This feature does not conflict with other Tracker features such as the OneUnit setting or Heat Control.

[jedi95]

Version 3.38 stable has been released.

This version fixes a long-standing bug where the Tracker windows appear to be resizable. It also adds support for bonus points on any WU with kfactor > 0 instead of just SMP A3. Also, if you still get the "Failed to read FAHlog.txt" error after updating to this version, you can use -debug to log more details about the error.

[LarkStarr]

This is an awesome program, keep it rollin'!

[jedi95]

Version 3.39 stable has been released.


This version is mostly a bugfix release, but it does add one new feature. The passkey used for GPUs can now be set differently by using the -gpupasskey <passkey> command line flag. Specifying none for the passkey (-gpupasskey none) will cause the Tracker to use a blank passkey on the GPUs.