Folding Forum

PantherX wrote:

7im wrote:...As the F@h project progresses, WUs tend to get bigger over time, so the work unit sizes will tend to increase whether this flag is used or not.

Does it mean:
A) As the Gen # increases, the WU size increases?
B) As F@H releases more Projects, the general trend is larger WU Size?

Answer B, larger wu size because the proteine studied is larger, there are more added forces which influence the possible folding process, and the represented time slice get's longer ( any might apply or all might apply ).

PantherX wrote:

7im wrote:...As the F@h project progresses, WUs tend to get bigger over time, so the work unit sizes will tend to increase whether this flag is used or not.

Does it mean:
A) As the Gen # increases, the WU size increases?
B) As F@H releases more Projects, the general trend is larger WU Size?

MtM has the correct answer.

It's a general statement and about a general trend. It may not apply to all client types. GPU development has kind of been stuck in the same place while waiting to transition from CUDA and Brook to OpenCL, and so the WUs tend to be about the same size. (again, gpu=stuck = vague generality, not specific statement)

However, the SMP client is a good example of bigger WUs over time. We started with a small single core CPU client, and then added the 4 core SMP client. Then with SMP2, we can have more than 4 cores. And recently, we added the -bigadv switch for gigantic SMP work units, with an almost unlimited number of cores.

7im wrote:

MtM wrote: Only thing I feel like putting on the forums instead of pm, only because it's the best example I can find and well, you said earlier in this thread that I didn't know what I was talking about ( you hurt my pride boohoo ).

Install guide wrote:This is the same as using the -advmethods command line flag. This option states a preference to request newer late stage beta work units. Because newer work units tend to be larger, this setting my slightly increase your points per day. But because the mix of work units changes from week to week, using this setting might also reduce your PPD, or have no affect at all.

Fixed another place that Myth was mistakenly perpetuated.


Set -advmethods flag always, requesting new advanced
scientific cores and/or work units if available (no/yes) [no]?

This is the same as using the -advmethods command line flag, except -advmethods will not appear on the arguments line in the fahlog. This option states a preference to request late stage beta work units. Do not assume using -advmethods will enable FAH clients to get larger WUs or WUs with higher PPD. Because the mix of work unit projects change weekly or monthly, using this setting might reduce your PPD, increase your PPD, or have no affect at all. The same applies for work unit sizes, increasing, decreasing, or not. As the F@h project progresses, WUs tend to get bigger over time, so the work unit sizes will tend to increase whether this flag is used or not.

Removing the advmethods = bigger myth is a double-edged sword... In one hand, removing will allow to stop spreading the myth that it's always bigger but it will cause issues as well when people notice some WU get bigger than expected and complaint about that. The better solution is to word it so it's not automatically big when selecting advmethods but to still expect the small possibility of receiving bigger WU.

If you read his last sentence, isn't that already impleid?

Well, 7im might have pasted the incorrect section or showing the corrected one (I didn't check the actual entry). If that's the corrected entry, it's perfect for me.

Xilikon wrote:Well, 7im might have pasted the incorrect section or showing the corrected one (I didn't check the actual entry). If that's the corrected entry, it's perfect for me.

As the F@h project progresses, WUs tend to get bigger over time, so the work unit sizes will tend to increase whether this flag is used or not.

Works for me, but I'm not a native english speaker so idk. Doesn't it imply that work unit can get larger in size with this flag? Seems so to me

I rewrote that section again, and it just got bloated trying to make everyone happy.

The install guides are NOT there to answer every question and explain every concept in detail. They ARE there to provide just enough information to get the client installed.

Like a women's dress, long enough to cover the subject, but short enough to keep it interesting.



Set -advmethods flag always, requesting new advanced
scientific cores and/or work units if available (no/yes) [no]?

-> This is the same as using the ''-advmethods'' command line flag, except -advmethods will not appear on the arguments line in the fahlog. This option states a preference to request late stage beta work units. Do not assume using -advmethods will enable FAH clients to get larger WUs or WUs with higher PPD, although that is possible when using this flag. However, because the mix of work unit projects change weekly to monthly, using this setting could change the mix of work units you client receives resulting in a PPD descrease, PPD increase, or have no affect on PPD. The same applies for work unit sizes. Using the -advmethods setting could increase WU size, decrease it, or have no affect. Note that as the F@h project progresses, WUs tend to get bigger and more complex over time, so the work unit sizes will tend to increase whether this flag is used or not.


No one complained for the last two years when it was wrong, now all of a sudden everyone has an opinion. This crap is too much, and when I have more time, I am removing it.


And again, if you want something fixed in the install guides, please post in the corresponding threads. The editors will get to the fixes as they have time. Thanks.

The install guides are written and updated by the folding community, and managed by the Pande Group. Please post any suggestions, corrections, or update recommendations to the corresponding Guides topic in the Folding Forum. And thank you for helping to improve the install guides.

•Official CPU Install Guides topic
•Official GPU Install Guides topic
•Official Linux Install Guides topic
•Official MAC Install Guides topic
•Official SMP Install Guides topic

Hey 7im I think your new work is great, take it easy ( can't tell you to take your meds, but chill ).

Serieusly, do not take this to serieus, even if everyone has an opinion, who decides if that opinion is worth enough to raise your bloodpressure ( jezus look who's talking here eh! ).

Don't get me wrong, it's good feedback. I just have limited time, and redoing something 3 times with end result being worse than the start does start to get my heckles up. Sorry.

That, and I don't get notifications when people post update feedback in other random threads.

Okay, back to skirt mode. Pulled all the extra stuff out, put it in one of the FAQs, and then simply referenced it with a link if they wanted to know more than this brief entry.

Set -advmethods flag always, requesting new advanced
scientific cores and/or work units if available (no/yes) [no]?

-> This is the same as using the [[FAQ-Configure#ntoc3 | -advmethods]] command line flag, except -advmethods will not appear on the arguments line in the fahlog. This option states a preference to request late stage beta work units, which may be less stable than regular work units. May cause work unit size and PPD to increase, decrease, or not change.

For the install guide that's sufficient I suppose. Imho your last effort was atleast as good ( even if it was more 'bloated' ). But that's because personally I never find information to be to much, it's a matter of being able to filter out what you need. But if we're following your seperation of content, I agree that this short and coincise tidbit is enough.

As I said, how I feel about it isn't as important as how you feel about it, you will have to life with the people complaining about there being not enough/to much information.

Atleast there is no more information there which is non factual, which was the starting point of the debate about it. You succeeded, it's fixed. Let's move on?

Wait.. one more thing. The point I treid to make earlier as well. Why not link to a more elaborate explanation ( wether it's in a forum thread/post or wiki, the previous explanation which I said I liked more, might be worth linking to from the short description )? That way you're tackling all the 'issues' I had in one go ( for this short text atleast ), many more to go I suppose but I am beginning to understand that it will take allot of small steps to 'fix' that.

7im wrote:Okay, back to skirt mode. Pulled all the extra stuff out, put it in one of the FAQs, and then simply referenced it with a link if they wanted to know more than this brief entry.

MtM wrote:...
Wait.. one more thing. The point I treid to make earlier as well. Why not link to a more elaborate explanation ( wether it's in a forum thread/post or wiki, the previous explanation which I said I liked more, might be worth linking to from the short description )? That way you're tackling all the 'issues' I had in one go ( for this short text atleast ), many more to go I suppose but I am beginning to understand that it will take allot of small steps to 'fix' that.

Sorry must have been half awake half asleep, only read your post didn't check the actual changes with my own eyes

Looks great! But you forgot to remove the exclamation mark after FAH!, and the gpu guides still reference to service installs on vista ( and no mention of vista being equal to win7 like XP is equal to 2003. But it's 04:00, I couldn't sleep, and I come down and start nagging you... not nice Take your time.