Folding Forum

This is in response to the recent events about a folder admitting of running a script to block unwanted workunits from being downloaded. Lots of comments defending him argue there are no defined set of rules against them. For them, no rules = not forbidden. The PG admitted the current problem is caused by a lack of written rules and good communication so from our discussion, we agreed that writing the rules would be a good start to tell everyone what is good for them and what isn't. We hope this will reduce the abuse and the useless flamewars over what is right or wrong. As for punitive measures, they will come with some ways later but it's not in our hands unfortunately.

Without further ado, let's start with a exhaustive list of behaviors. Try to make it as simple but precise so we can avoid leaving a few holes. I'll start with some of the most obvious ones :

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 (source : PG Member). 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.

Thanks jebo_4jc and PantherX for providing a good list with excellent references and good phrasing to remove any ambiguity.

I trust everyone can come with more examples. It's a even better thing if you can find a link to a official comment from a PG member (especially Vijay Pande or Dr Kasson). Please don't turn this into a flamewar arguing what is right and what is wrong, it's not the purpose of this thread. In the end, the PG will use this for everyone's good.

Xilikon wrote:...-Using any means to trick the client into downloading a work unit not meant for the hardware it is running on is forbidden. Reference : http://foldingforum.org/viewtopic.ph...157380#p157380 and http://foldingforum.org/viewtopic.ph...158383#p158383...

The links doesn't work

Not Found
The requested URL /viewtopic.ph...158383 was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Cleaned up the links, added new suggestions.

-It's not allowed to circumvent the assignment server logic in any way to attempt to pick more desirable work units or block unwanted work units. Reference.
-Packaging the F@H files inside of another software package in a attempt to install without the user consent is strictly forbidden. Reference (see: running on authorized computers only) and EULA update.
-It's forbidden to distribute the F@H files yourself. Reference (See: running on authorized computers only) and EULA update.
-Using flags or client switches to mislead Assignment Servers (or for any other inappropriate purposes) is prohibited. Reference.
-Using unpublished client switches for any reason is prohibited.
-Using any means to trick the client into downloading a work unit not meant for the hardware it is running on is forbidden. Reference 1, Reference 2.
-Deleting a work unit for any reason other than the reasons below is not permitted. Deleting work units disrupts the priority of work assigned and causes delays in dependent work unit assignments. The only permitted reasons for deleting work units are:

• work unit or client instability
• inability of the host system to complete the work unit before the final deadline
• more?

Question Xilikon: the reference and link to the EULA update blog post were the same for items 2 and 3. Was this intentional?

jebo_4jc wrote:Question Xilikon: the reference and link to the EULA update blog post were the same for items 2 and 3. Was this intentional?

Yes, it was intentional since both refer to the same issue at the base, which is the distribution of F@H files by yourself. In addition, point 2 is about illegal installation without permission, hence the separate line.

Edit : After thinking about that, it seems indeed redundant so I merged both to cover both distribution or packaging files in another package.

-Circumventing the Assignment Server logic in any way to attempt to pick more desirable work units or block unwanted work units is prohibited. Reference.
-Using flags or client switches to mislead Assignment Servers (or for any other inappropriate purposes) is prohibited. Reference.
-Using unpublished client switches for any reason is prohibited.
-Altering the client software or associated data files or de-compiling or reverse engineering the software is prohibited.
-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. Reference (see: running on authorized computers only) and EULA update.
-Using any means to force the client to download and/or run a work unit that is not natively designed for the hardware it is running on is prohibited. Reference 1, Reference 2.
-Intentionally stopping or pausing a client to manipulate the time a work unit is completed and returned is prohibited.
-Deleting a work unit for any reason other than the reasons mentioned below is prohibited. Deleting work units disrupts the priority of work assigned and causes delays in dependent work unit assignments. The only permitted reasons for deleting work units are:

• work unit or client instability
• inability of the host system to complete the work unit before the final deadline
• more?

-Running a client on hardware that will only marginally meet the work unit 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 your hardware is not going to complete a work unit by the deadline time, stop the client, delete the work unit, and change your client to a less CPU-intensive WU type.

I updated some of the language in an attempt to be more consistent.

I also added items that addresses manipulating work unit turn in times, de compiling or reverse engineering the software, and meeting WU deadlines.


We also need a reference for the rule(s) against deleting WUs.

If I do run into a job that can't be completed, what is the proper way to purge it?

All you can do is delete it.

OK! This means that all i7/AMD6 core must stop folding SMP Bigadvanced. All dual cores must stop folding SMP.
GPU must fold only their respective WU's.
There's unpublished flags, (darn I didn't know that) that everyone is going to be looking for, to see what they do.
Intentionally stopping a WU so it late? Is a no no.

Why doesn't PG just initialize this with the client? Wasn't it supposed to be part of V5 or 6?
I am not against this, but I think its going to become a VERY BIG TAPE WORM!!!

GL

Please provide references for your assumptions, particularly the one about dual cores not running SMP and GPUs folding only their respective WUs.

By the way, the Mac Mini is a dual processor and the only assignments it can process are SMP. Clearly the Pande Group has no intention of prohibiting that from happening.

RAH wrote:OK! This means that all i7/AMD6 core must stop folding SMP Bigadvanced. All dual cores must stop folding SMP.
GPU must fold only their respective WU's.
There's unpublished flags, (darn I didn't know that) that everyone is going to be looking for, to see what they do.
Intentionally stopping a WU so it late? Is a no no.

SMP - 1.We strongly suggest people run this client on 4-core boxes. While it will run on 2-core boxes, we have noticed some potential problems (we are looking into these issues now).

This is the same argument used against AMD6/i7 with bigadv.

Xilikon's post. viewtopic.php?f=59&t=16011&p=159108#p159108

RAH wrote:SMP - 1.We strongly suggest people run this client on 4-core boxes. While it will run on 2-core boxes, we have noticed some potential problems (we are looking into these issues now).

Your point is valid, however nothing further has ever been said about 2-core limitations on SMP, to my knowledge. An update on this subject from PG would be helpful, however at this point there is no authority to say 2 core boxes shouldn't run SMP. In fact, here, the FAQ appears to contain updated information. 2 core boxes are more susceptible to missing deadlines, so perhaps a mention of that in the guideline would be appropriate.

This is the same argument used against AMD6/i7 with bigadv.

Xilikon's post. viewtopic.php?f=59&t=16011&p=159108#p159108

Now you've lost me. AMD hex core CPUs are not supported by bigadv at all. Running a bigadv unit on an AMD X6 requires manipulation that will violate at least one of the guidelines. And I see nothing in your link concerning bigadv units.

The only authority on i7/bigadv I can find is from Dr. Kasson's original post, which is self explanatory, and falls under the same umbrella as missing deadlines on 2 core boxes.

Q: What about Core i7 chips with 8 virtual cores?
A: In our testing, these have been found somewhat marginal for completing work within the target deadlines (ideally 3 days per WU). If you have a fast Core i7 that is a dedicated folder, feel free to give it a try. If you're doing a lot of other things with that system, standard SMP may be a better bet.

So, Xilikon, I'm going to add another suggestion to my post above regarding not running clients that cannot finish the deadline time.

Nothing further has been said, by PG, about i7's, AMD6's, or GPU's.
This is all assumptions, that I have never read a definite reply to.
Its like the "soon", these are all "possibilities".

The links posted above as references are not sufficient for you?

Ref - how to quit a WU

All you can do is delete it.

...

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?

Sidebar - AFAIK, most Mac's are dual core. A 2.4ghz mac dual-core takes an average of 1.3 days to finish a SMP job. I'd guess the mac WU's are designed for them.

Well after reading through all the references again, and again, this is my take IMO.
1. Ip blocking - a few do this I guess, and I don't see much can be done about it. Too much trouble for me.
2. i7/AMD6 - OK, we know your doing this, and we aren't going to say no, just yet. But don't come crying
if things get tough.
3. GPU - Hmmm, can cause problems. After 3 months you don't know?
4.F@H trojan, I totally agree, this is bad. But has been taken care, very well by PG in the past, IIRC.
5. What is marginally - one hour - one day - why have preferred deadlines. You beat that, you should be fine, see #2.
6. Wheres the list of unauthorized flags? I might check them out.

Don't get me wrong. I can see some of this very clearly. But I still think its just a big can of worms.
They may be very busy, but let PG, handle F@H.