I may have stumbled upon my issue. I noticed even after improving my cooling I was still getting into trouble at various times, and especially during the daytime while I was away. I ended up boosting the core a bump or two and so far everything is running fine. this chip just really needs some voltage to get churning WU's on all 6 cores. I went from 1.48125V to 1.4875V and so far I am 24 hours stable. After further testing I may try "client-type advanced" again.
I ran into a curious problem with the v7 client yesterday involving the SMP client; it wouldn't run or would take 2-4 hours to complete a fold that was taking 2-3 minutes.
I spent all day stopping and restarting the client, removing the slot client, adding a new slot client, still the same problem. This morning, with a project 8001 taking 18 hours to reach 25%, I decided to drop back the number of cores from the default "-1" auto select to a manually selected 3 cores. Now, I am running a PhenomII X4 945 at stock settings, so I only have 4 cores to work with and GPU folding seems to take almost an entire core to its self. I thought dropping it down from attempting to run all 4 cores to only running 3 would slow me down and/or drop my PPD.
Nope.
I am now blazing through the previously sluggish WU at around 3:51 TPF. Is this a problem that other people have run into? I was not having an issue until yesterday and I wonder if its something wrong with my client, the WU or did I successfully resolve an actual issue with load?
One thing you can check for is if there are multiple client's open (check taskmanager for more than one FAH.exe or fahgpux.exe). I've had that before and had to kill it from taskmanager then start over again. AMD GPU folding does still take an entire core for itself, unfortunately.
Ok, I may check that if it happens again, but I found it odd that even after restarting I was having that problem until I dropped it to three cores (SMP:3) and so far, in the past 5 hours I have not had a problem.
Since resolving the vcore and temperature issues I uncovered a GPU issue. I was experiencing a "Failed" after a successful fold of a single wu. All I could do was restart V7 and it would work again but fail again after a single wu.
I did a little search and found that Beta drivers could cause this ...so if anyone else has had experience with this please chime in. Also, if you're having this issue it may be worth a shot to fall back to non-beta drivers. I'll let you know after I turn in a few successful wu's.
The alternative to gdebi is to first run sudo dpkg -i fahcontrol_7.1.50-1_all.deb which will give you errors and then run sudo apt-get install -f.
There are probably good ways to do this via the GUI too.
Conclusion: If all goes well we will publish this release to the front page. If you think there are any compelling reasons not to do so please let us know but keep in mind that we are currently in a feature freeze
I have my 7.1.50 running on my Windows folding box, seems to "get out of the way" of the core more. Same Core 0xa4, but a P7006 is running at 2 min 2 sec per frame(confirmed by looking in log) here, and IIRC under 7.1.43 I got a P7006 and it took almost 7 min per frame. Like the new client/FAHControl set so far.
Install notes: I told the installer to keep the old config, installed right on top of the older client, it is running smooth. Installer ran an uninstall routine before updating, but kept WU in progress and resumed it from checkpoint. Only thing I do not like, is that it ran the FAHControl, and FAHControl ended up running in a window almost totally over the window that informed me the install was complete. The completion window was not quite covered, the top bar was visible, so I brought the installer window to front and closed the installer.
Many of the fixes were for non-windows clients, but there were PPD calc fixes within the last couple versions, so maybe depending on what you have. The actual clients themselves have not been changed to my knowledge, so you wouldn't get any actual increase in PPD/results.
Install notes: I told the installer to keep the old config, installed right on top of the older client, it is running smooth. Installer ran an uninstall routine before updating, but kept WU in progress and resumed it from checkpoint. Only thing I do not like, is that it ran the FAHControl, and FAHControl ended up running in a window almost totally over the window that informed me the install was complete. The completion window was not quite covered, the top bar was visible, so I brought the installer window to front and closed the installer.
I'm going to post a bug report about that. Basically, that the behavior should be something like a default "checked" box for "Launch FAH Control after installer exits" rather than what you experienced.
so maybe depending on what you have. The actual clients themselves have not been changed to my knowledge, so you wouldn't get any actual increase in PPD/results.
Well, IIRC the pointage for early turnin for 7006 has been upped also. I have an Intel 2600 K churning away folding, almost no apps on the computer except AV and CPU-Z (not running often) and Win 7 Pro updated. 8 GB of RAM, upgraded from 4 GB, happened after the first 7006 so maybe that affects that project some also. HD is a spindle drive due to funds limits here, so more RAM is my way of speeding up work some.
Sure, the points for a particular project might have been adjusted or the early turn in bonus have been tweaked but the actual core that runs the job is the same whether you are using v6 or v7. I don't believe that F@H has any projects non-bigadv projects that get close to 4GBs but don't have any citation for that. You might get a small PPD increase going to an SSD but I'd make sure you were getting it for other reasons first :)
Well, lessee.... First, I wanted Folding to be able to use more than 2 GB. I know Win 7, untweaked, will happily take 1.5-1.75 GB for itself. Then there is the always-on AV. That leaves maybe 2-2.25 GB for Folding if I have only 4 GB total installed.
So, I invested $20.00 in another 4 GB stick. And after that, average PPD all other things being equal jumped 2-10 K a day depending on what WUs I got. For my numbers, that is about 12-30% gain in PPD from a minimal investment.
The client sets up what the core is fed unless I am wrong, and how it is fed, so if the Client will grab lots of RAM and feed the core a whole chunk of work (read large chunk) from RAM, that is faster than from temp files on HD. With SMP, I am (I think) running 8 core equivalents simultaneously.
So, RAM for eight core instances plus a chunk of work for each, plus maybe the whole WU in RAM if the client is set up right and that much RAM is available for actual use. Else why have the client report what the system RAM is??? And why do those systems with large RAM outperform otherwise essentially same system with low RAM, or slower RAM???
The RAM reported matters at lower levels, or if you want to limit the amount possibly exposed to F@H for other reasons. Right now, my "server" is folding a 6097 through FAH GPU tracker (so, 6.34 rather than v7 beta client but the GPU tracker is really just what FAHControl does in v7) and 9800GX2 is folding a pair of GPU2 WUs.
The SMP core (what is actually doing the work) is only using ~178MB of RAM and the GPU2 cores are at 73MB each. The clients are at ~1MB each and the overall program (FAHControl, in your case, FAH GPU Tracker in mine) is at 29MB. Total memory hit: 356MB.
My main rig, which I run -adv and -big (which you should be for SMP) WUs is around the same total hit.
As to why you got a points increase, who knows. Maybe it was getting sent to swap when you were doing other things and now it doesn't. Faster RAM would feed the processor faster, but I don't know how much of a bottleneck that is and don't have the will power to test it out on my rigs (gotta keep folding :P). You are correct in stating that the client is what talks to the server (giving it stats about the machine on which it is running and pulling/pushing WUs) and then engages the core to do the work.
The RAM reported matters at lower levels, or if you want to limit the amount possibly exposed to F@H for other reasons. Right now, my "server" is folding a 6097 through FAH GPU tracker (so, 6.34 rather than v7 beta client but the GPU tracker is really just what FAHControl does in v7) and 9800GX2 is folding a pair of GPU2 WUs.
The SMP core (what is actually doing the work) is only using ~178MB of RAM and the GPU2 cores are at 73MB each. The clients are at ~1MB each and the overall program (FAHControl, in your case, FAH GPU Tracker in mine) is at 29MB. Total memory hit: 356MB.
Um, what about the WU data and work chunk data impact(you are giving process impact)???? And right now I am at a lower folding PPD level and machine processing ability level, my box is a humble single-CPU 2600K with no discrete graphics card to GPU fold.
However, EOC stats is guesstimating that I will hit a million points about April 1st-2nd. Started with zero points Feb 4. Same single dedicated Folding box the whole time. :D
My main rig, which I run -adv and -big (which you should be for SMP) WUs is around the same total hit.
As to why you got a points increase, who knows. Maybe it was getting sent to swap when you were doing other things and now it doesn't.
I have been getting consistently more for about 10 days now, in the range specified. So either the client and cores and other stuff were in swap for 22 days and ten days ago (when I increased the RAM) stopped being in swap, or something really weird happened.
Anyone installed v7 on a headless (read: no X installed at all) Linux box? I've not tried it yet, but it looks to me like they've gotten rid of the ability to configure it via the command line. All their documentation suggests that the GUI is the only way to config the damn thing.
I do not believe it can be installed on a headless machine, due to the issue you cited. I am using SMP client for my headless (no-longer bigadv) machine, but I don't know that there are any immediate plans for headless configuration.
Comments
I spent all day stopping and restarting the client, removing the slot client, adding a new slot client, still the same problem. This morning, with a project 8001 taking 18 hours to reach 25%, I decided to drop back the number of cores from the default "-1" auto select to a manually selected 3 cores. Now, I am running a PhenomII X4 945 at stock settings, so I only have 4 cores to work with and GPU folding seems to take almost an entire core to its self. I thought dropping it down from attempting to run all 4 cores to only running 3 would slow me down and/or drop my PPD.
Nope.
I am now blazing through the previously sluggish WU at around 3:51 TPF. Is this a problem that other people have run into? I was not having an issue until yesterday and I wonder if its something wrong with my client, the WU or did I successfully resolve an actual issue with load?
I did a little search and found that Beta drivers could cause this ...so if anyone else has had experience with this please chime in. Also, if you're having this issue it may be worth a shot to fall back to non-beta drivers. I'll let you know after I turn in a few successful wu's.
Link to FF
Link to download page
Install notes: I told the installer to keep the old config, installed right on top of the older client, it is running smooth. Installer ran an uninstall routine before updating, but kept WU in progress and resumed it from checkpoint. Only thing I do not like, is that it ran the FAHControl, and FAHControl ended up running in a window almost totally over the window that informed me the install was complete. The completion window was not quite covered, the top bar was visible, so I brought the installer window to front and closed the installer.
So, I invested $20.00 in another 4 GB stick. And after that, average PPD all other things being equal jumped 2-10 K a day depending on what WUs I got. For my numbers, that is about 12-30% gain in PPD from a minimal investment.
The client sets up what the core is fed unless I am wrong, and how it is fed, so if the Client will grab lots of RAM and feed the core a whole chunk of work (read large chunk) from RAM, that is faster than from temp files on HD. With SMP, I am (I think) running 8 core equivalents simultaneously.
So, RAM for eight core instances plus a chunk of work for each, plus maybe the whole WU in RAM if the client is set up right and that much RAM is available for actual use. Else why have the client report what the system RAM is??? And why do those systems with large RAM outperform otherwise essentially same system with low RAM, or slower RAM???
The SMP core (what is actually doing the work) is only using ~178MB of RAM and the GPU2 cores are at 73MB each. The clients are at ~1MB each and the overall program (FAHControl, in your case, FAH GPU Tracker in mine) is at 29MB. Total memory hit: 356MB.
My main rig, which I run -adv and -big (which you should be for SMP) WUs is around the same total hit.
As to why you got a points increase, who knows. Maybe it was getting sent to swap when you were doing other things and now it doesn't. Faster RAM would feed the processor faster, but I don't know how much of a bottleneck that is and don't have the will power to test it out on my rigs (gotta keep folding :P). You are correct in stating that the client is what talks to the server (giving it stats about the machine on which it is running and pulling/pushing WUs) and then engages the core to do the work.
However, EOC stats is guesstimating that I will hit a million points about April 1st-2nd. Started with zero points Feb 4. Same single dedicated Folding box the whole time. :D I have been getting consistently more for about 10 days now, in the range specified. So either the client and cores and other stuff were in swap for 22 days and ten days ago (when I increased the RAM) stopped being in swap, or something really weird happened.