Folding Forum

If some of the clients I am running are using my passkey, and some are not, are they still credited to the same username? Some of my friends help me out in folding, and setting up the passkeys on all their computers would be a major pain. They're already all under the same username.

The work your friends do will be credited to your user name without a passkey. However, the WUs turned in without a passkey will not be eligible for the Quick Return Bonus on SMP Work Units.

Will only make a difference on SMP, if you are using the classic or GPU it will make no difference, as long as they get your name right and team number etc.. note misspelled names are different users as far as the system goes. If using SMPs they will only get base points.

Thanks, you all just saved me quite a job there

I was a bit worried about the work being listed under different usernames, or something.

It is still a good idea to use passkeys, although not compulsory, you could just copy the key and send it to them..

hmmm.... allright, i'll send them the passkeys and the passkey FAQ. Seems like a good idea.

Folding regular SMP WUs on an i7, the difference in points per day with a passkey and without is about 15,000 ppd.

ChasR wrote:Folding regular SMP WUs on an i7, the difference in points per day with a passkey and without is about 15,000 ppd.

Wow.... i think I might get into this passkey thing I already have my passkey, and it looks like I'll be rolling it out soon.

P.S. I have another problem: I have a Mac C2D running the latest client and it refuses to download cores..... What's up?

config: -verbosity 9 -smp 2 and normal WU's

I think all SMP are BIG WU , not normal size.

I mean I didn't change the setting in the config from 'normal' to 'big'

I think you are correct, I have an Athlon x2 Windows client running (SMP) and it has about 500,000 steps.

Anyway, is this some problem with the assignment servers? AFAIK, all clients are issued the same WU's, whether Mac, Windows, or Linux.

All clients are NOT issued the same work units. Some work units are linux only, some Windows only, some Mac only, and some are a mix and match of any or all of those.

Hence the "Operating System" column on the Server Status page. W, L, and X are possible values... and as you can see, not all servers have all values.


And even though the SMP client is hard coded to request BIG sized work units (and should ignore the WU size selection in the client setup), you should always configure your SMP client to request BIG work units, just to avoid any potential assignment server glitches.

7im wrote:All clients are NOT issued the same work units. Some work units are linux only, some Windows only, some Mac only, and some are a mix and match of any or all of those.

Hence the "Operating System" column on the Server Status page. W, L, and X are possible values... and as you can see, not all servers have all values.


And even though the SMP client is hard coded to request BIG sized work units (and should ignore the WU size selection in the client setup), you should always configure your SMP client to request BIG work units, just to avoid any potential assignment server glitches.

Sounds good... I will do that.
This is interesting... I thought all the WU's were coded in Assembly, and OS was irrelevant. Apparently not.
P.S. : I got the mac to work; by using the console client. The "Install" client, apparently was in beta.

The WUs are data, not code, so they're not Assembly or any other programming language.

Every WU requires a specific FahCore to process it, and portions of the FahCores are coded in Assembly as well as other languages, but that's not the real issue. Each OS has it's own peculiarities. The programmers that contribute to FAH go to great lengths to take advantage of whatever hardware you have so they sort of "push the limits" of what each OS can do. This requires an extended development time and it makes sense to concentrate on only one OS, so there may not be a version of a specific FahCore for your OS yet. It may also result in some rather obscure bugs in one OS that do not occur in other OSs, so additional restrictions can be applied even after a core is relased.

Stanford does have rather limited programming resources so often the limitations stay in place for long periods of time, as long as there's adequate work for each OS. (Remember that Stanford isn't making money from selling millions of copies of their software. Progress is often slow except when it limits an important aspect of the science that they need to do.)