Folding Forum

Posted: **Thu Nov 04, 2010 5:13 am**

Qinsp wrote:What I have done is to delete the installation, then reinstall. Whatever job it was running vanishes, I suppose without notification that the job has been quit.

Isn't there a way to tell the server that a WU has been rejected by the donor? Or is what I did the best solution?

Donors do not get the luxury of selectively rejecting WUs. Pande Group decides the WU assignments to best move the project forward.

However, in the rare case, as noted above, that a WU must be deleted to restart the client, the most common method is to stop the client, delete the Work folder, queue.dat file, and the unitinfo.txt file. Then restart the client. And sometimes, and additional step is required. Repeate the process after getting the same bad WU again, and add the step of changing the Machine ID.

Posted: **Thu Nov 04, 2010 5:19 am**

RAH wrote:...2. i7/AMD6 - OK, we know your doing this, and we aren't going to say no, just yet. But don't come crying
...
5. What is marginally - one hour - one day - why have preferred deadlines. You beat that, you should be fine, see #2....

I can only say this with reference to bigadv WUs:

kasson wrote:...Project 2681 is the initial project in this series. It is benchmarked at 25403 points, preferred deadline 4 days, final deadline 6 days.
We recommend running on systems that can complete this work unit in <= 3 days.

Source

So now we know that the bigadv has:
Researcher Preferred Deadline
Preferred Deadline
Final Deadline

EDIT -> I have included some more references, minor edits, made categories for easier identifications, etc:

Regarding The Project/Work Units (WUs)
1) Manipulating the Assignment Server (AS) logic in any way to obtain high PPD WUs and/or block low PPD WUs is strictly prohibited. This is commonly referred to as cherrypicking and is discouraged. (PG Member, Super Moderator)

2) Deleting/Dumping a WU for any reason other than the reasons mentioned below is prohibited. Deleting WU disrupts the Science since it will take longer for the WU to be completed as it will be reassigned once it crosses its Preferred Deadline. Dumping a WU if it gives you low PPD is again considered cherrypicking and is strongly discouraged. (Site Admin) The only permitted reasons for deleting/dumping WUs are:
A) WU Instability -> If it happens, please report it in this Forum
B) F@h Client instability -> If it happens, please report it in the appropriate F@h Client Forum
C) Inability of the host system to complete the WU before the Final Deadline -> If it happens, please visit this thread to select a F@h Client that fits your needs.

3) Using flags/switches to mislead the AS is prohibited. Please refrain from "experimenting" with flags/switches since they were designed to be used for specific purposes. (PG Member)

4) Using any means to force the F@h Client to download a WU that is not natively designed for the hardware it is running on is prohibited. (PG Member, PG Member)

5) Running a F@h Client on hardware that will only marginally meet the WUs Preferred Deadline is strongly discouraged. For example, it is not recommended to run bigadv units on slower i7 CPUs and it is not recommended to run SMP units on slower 2-core systems. If you notice that your hardware is not going to complete the assigned WU by the Preferred Deadline time, stop the client, delete the work unit, and please visit this thread to select a F@h Client that fits your needs.

6) Intentionally stopping/pausing the F@h Client to manipulate the completion time and wuresult upload time of time-sensitive WUs is prohibited.

7) Using unpublished client switches for any reason is prohibited.

Regarding The F@h Clients
1) Altering the F@h Client software, its associated data files or de-compiling/reverse engineering the software is in direct violation of EULA. (PG Member, PG Member)

2) Re-distributing the F@H files or packaging the F@H files inside another software package in a attempt to install F@H without the user's consent is strictly prohibited. (FAQs (see: running on authorized computers only), F@h Blog)

Posted: **Thu Nov 04, 2010 6:00 am**

7im wrote:
Qinsp wrote:What I have done is to delete the installation, then reinstall. Whatever job it was running vanishes, I suppose without notification that the job has been quit.

Isn't there a way to tell the server that a WU has been rejected by the donor? Or is what I did the best solution?
Donors do not get the luxury of selectively rejecting WUs. Pande Group decides the WU assignments to best move the project forward.

However, in the rare case, as noted above, that a WU must be deleted to restart the client, the most common method is to stop the client, delete the Work folder, queue.dat file, and the unitinfo.txt file. Then restart the client. And sometimes, and additional step is required. Repeate the process after getting the same bad WU again, and add the step of changing the Machine ID.

Half removal hasn't worked for me. Is there a specific reason to save any of the files?

So if I understand this right, it is not necessary or possible to notify to PG that I've left a job unfinished, or finished and not sent.

Sidebar - a few days ago, I had all machines running 6701/6702's concurrently, nothing else. Today, I didn't see even one of them load.

Posted: **Thu Nov 04, 2010 7:07 am**

Qinsp wrote:
7im wrote:
Qinsp wrote:What I have done is to delete the installation, then reinstall. Whatever job it was running vanishes, I suppose without notification that the job has been quit.

Isn't there a way to tell the server that a WU has been rejected by the donor? Or is what I did the best solution?
Donors do not get the luxury of selectively rejecting WUs. Pande Group decides the WU assignments to best move the project forward.

However, in the rare case, as noted above, that a WU must be deleted to restart the client, the most common method is to stop the client, delete the Work folder, queue.dat file, and the unitinfo.txt file. Then restart the client. And sometimes, and additional step is required. Repeate the process after getting the same bad WU again, and add the step of changing the Machine ID.
Half removal hasn't worked for me. Is there a specific reason to save any of the files?

So if I understand this right, it is not necessary or possible to notify to PG that I've left a job unfinished, or finished and not sent.

It is not possible to notify the PG that a WU will not be completed. It will be reissued when the preferred deadline passes.

The official way to delete a WU is to use the -delete N flag. People rarely do that. As 7im says, most people delete queue.dat and the entire work folder when a WU cannot be completed. That's not necessarily the BEST way to do it, just the quickest. If you happen to have another WU which has not been uploaded yet, it will delete it too. That situation is rare, but not impossible but in that situation you wouldn't want to use the quick method.

Posted: **Thu Nov 04, 2010 12:53 pm**

Thanks to everyone and especially PantherX for the comments and updates. The guidelines is shaping up to be a excellent reference for anyone having doubts about the best pratices and what is forbidden.

About running SMP on 2-core systems or bigadv on 4C/8T systems, if the client allow it, it's permitted. The thing to watch is the deadlines and if you can't complete them within the preferred deadline, it's better to get another different or adjust the flags. The AMD Thuban with bigadv is a good example of a violation because the client doesn't allow it to run on 6C (or 6 threads) and you must resort to software manipulations to download those units, which is forbidden.

There will always be some grey areas when things get borderline. Usually, in those cases, the PG will not clearly forbid but will just suggest to not do this.

Posted: **Thu Nov 04, 2010 3:28 pm**

bruce wrote:...

It is not possible to notify the PG that a WU will not be completed. It will be reissued when the preferred deadline passes.

The official way to delete a WU is to use the -delete N flag. People rarely do that. As 7im says, most people delete queue.dat and the entire work folder when a WU cannot be completed. That's not necessarily the BEST way to do it, just the quickest. If you happen to have another WU which has not been uploaded yet, it will delete it too. That situation is rare, but not impossible but in that situation you wouldn't want to use the quick method.

Thanks, that was what I was looking for. So:

>CTRL-C
>fah6 -delete 12345
>fah6 -smp

?

And this is the preferred way of getting "unstuck"?

Posted: **Thu Nov 04, 2010 3:47 pm**

Regarding The Project/Work Units (WUs)

1) Manipulating the Assignment Server ("AS") logic in any way to obtain high Points Per Day ("PPD") Work Units ("WU") and/or block low PPD WUs is strictly prohibited. Sources: (PG Member, Super Moderator)

2) Deleting/Dumping a WU for any reason other than the reasons mentioned below is prohibited. Deleting WU disrupts the project since it will take longer for the WU to be completed as it will be reassigned once it passes its deadline. Deleting a WU solely because it produces low PPD is prohibited. The only permitted reasons for deleting/dumping WUs are:
A) WU Instability -> If it happens, please report it in this Forum
B) F@h Client instability -> If it happens, please report it in the appropriate F@h Client Forum
C) Inability of the host system to complete the WU before the Final Deadline -> If it happens, please visit this thread to select a F@h Client that fits your needs.
(Source: Site Admin)

3) Using flags/switches to mislead the AS is prohibited. Please refrain from "experimenting" with flags/switches since they were designed to be used for specific purposes. Source: (PG Member)

4) Using any means to force the F@h Client to download a WU that is not natively designed for the hardware it is running on is prohibited. (Sources: PG Member, PG Member)

5) Running a F@h Client on hardware that will only marginally meet the WUs Preferred Deadline is strongly discouraged. For example, it is not recommended to run bigadv units on slower i7 CPUs and it is not recommended to run SMP units on slower 2-core systems. If you notice that your hardware is not going to complete the assigned WU by the Final Deadline time, stop the client, delete the work unit, and please visit this thread to select a F@h Client that fits your needs.

6) Intentionally stopping/pausing the F@h Client to manipulate the completion time and wuresult upload time of WUs is prohibited.

Regarding The F@h Clients

1) Altering the F@h Client software, its associated data files or de-compiling/reverse engineering the software is in direct violation of EULA. (Sources: PG Member, PG Member)

2) Re-distributing the F@H files or packaging the F@H files inside another software package in a attempt to install F@H without the user's consent is strictly prohibited. (Sources: FAQs (see: running on authorized computers only), F@h Blog)

3) Using unpublished client switches for any reason is prohibited.

I removed the "cherrypicking" lines because they said cherrypicking is "discouraged", but in fact this practice is strictly prohibited.
I clarified references to final vs preferred deadlines in certain scenarios.
Also made minor edits for clarity.

Good job PantherX.

Posted: **Thu Nov 04, 2010 5:36 pm**

Qinsp wrote: >CTRL-C
>fah6 -delete 12345
>fah6 -smp

?

And this is the preferred way of getting "unstuck"?

Yep, but 12345 is just a number 0 through 9. Look for something like this in FAHlog: "Working on queue slot 09" or a file called work/wuresults_02.dat

Also note that the servers are designed to be persistent. They'll probably assign the same WU again which is good if it's a WU that you can complete but you just need a second shot at it to meet the deadline. Otherwise, you may need to delete it more than once.

Posted: **Fri Nov 05, 2010 1:48 pm**

I have added a reference to a new source about deleting wu : viewtopic.php?p=164798#p164798. I have asked Vijay to make a statement to have a hardwritten reference.

So far, I believe we are almost done so if after some days, nothing is added, I would strongly suggest you circulate this on all teams forums to gather more feedback. I want this to be a full community project, not a single team project.

Posted: **Fri Nov 05, 2010 4:03 pm**

I thought that was the whole point of moving this thread to FF to begin with?

Looks good Xil. I noticed if we move the "list" tags to the numbered items instead of the headings, it looks a bit better IMHO. I did it in my post above if you want to see how it looks.

Posted: **Sat Nov 06, 2010 3:42 am**

jebo_4jc wrote:Regarding The Project/Work Units (WUs)

--SNIP--

5) Running a F@h Client on hardware that will only marginally meet the WUs Preferred Deadline is strongly discouraged. For example, it is not recommended to run bigadv units on slower i7 CPUs and it is not recommended to run SMP units on slower 2-core systems. If you notice that your hardware is not going to complete the assigned WU by the Final Deadline time, stop the client, delete the work unit, and please visit this thread to select a F@h Client that fits your needs.

I am running a SMP unit on a (Is an AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ considered slower?) 2-core system. I am thinking it might be helpful to add another gage to evaluate whether it is wise to be running bigadv or SMP. The log file entry; e.g., "Unit 6 finished with 47 percent of time to deadline remaining." My average is 54 percent of time to deadline based on the last 9 I completed. One of those was a 5 percent time to deadline. That was because we had an longer than normal power outage. I knew I was close but ran the WU to completion and made it. Without the 5 percent fluke my average would be 60 percent.

On deleting WU's. My experience and based on log entries. On the rare occasion a WU went past it's deadline, the client picked up on it, deleted that WU and started another. I also think the client does communicated to the sever on failed WU's. Example: One bad WU I received. It was download and processed, it failed, the client deleted it and downloaded the same WU. The second time it failed, again that slot was deleted and the same WU downloaded. The third time it failed, before that same WU was downloaded again, the core was re-downloaded, then the WU. The fourth time it failed the client deleted it and then download a different WU. In my eyes it gave the WU three shots, then download the core again to make sure that was not the problem, then after that failed, passed me on to another WU. Since I have been folding I can only remember once that I needed to manually delete a WU, aside from some file system problems I had a while back.

Posted: **Sat Nov 06, 2010 2:50 pm**

How are these issues and guidelines going to be affected by the imminent release of V7?
Is this the best timing?
Wouldn't the effort be better spent writing a practice guide given the new conditions imposed by the new client?

Just my 2 cents.

Posted: **Sat Nov 06, 2010 3:22 pm**

mdk777 wrote:How are these issues and guidelines going to be affected by the imminent release of V7?
Is this the best timing?

Depends. Imminent is relative and not all features or capabilities of the v7 client will be immediately available when the v7 client is first released to beta. Other than integrating all clients into one client we really do not know what other changes the first beta release of the client will bring. The overall work server code changes will also likely be rolled out very slowly. heck, there are still servers running v5 work server code. I suspect current guidelines will be relative for quite a few months to come and I also suspect not many people will upgrade immediately to the v7 beta unless they are forced to for some reason (because of new client server changes).

Posted: **Sat Nov 06, 2010 4:56 pm**

mdk777 wrote:How are these issues and guidelines going to be affected by the imminent release of V7?
Is this the best timing?
Wouldn't the effort be better spent writing a practice guide given the new conditions imposed by the new client?

There's a certain amount of logic here, but I question which of the guidelines might change when you substitute one client for another? Here is a key phrase from jebo_4jc's latest list.

The first group relate to current projects and that won't change (other than perhaps new projects using new cores but assigned in similar ways) so you guys can continue to work on that group. The ones listed as client items are from the EULA, so there's no reason to suspect that would change either. Perhaps somebody sees something that MIGHT change if we substitute a new client for the present one, but I certainly don't.
Regarding The Project/Work Units (WUs)

1) Manipulating the Assignment Server
2) Deleting/Dumping a WU
3) ... mislead the AS
4) ... force the F@h Client to download a WU that is not natively designed for the hardware
5) ... hardware that will only marginally meet the WUs Preferred Deadline
6) ... manipulate the completion time

Regarding The F@h Clients

1) Altering F@H ... files
2) Re-distributing the F@H files
3) ... unpublished client switches.

Posted: **Mon Nov 08, 2010 1:43 pm**

IMHO, the guidelines will still be very useful even with the v7 clients. At most, we might have to edit them to follow the new trends but the core of the guidelines is there to stay. bruce summed it very well and I don't think it's a waste of time.

With no new feedback to add, I think this set is complete so beside from some cosmetical changes, I will submit this to the PG for evaluation and inclusion in the F@H pages.

Folding Forum

Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline

Re: Folding pratices guideline