bruce wrote:One or two UNI-processor clients will be fine. It (or they) will use either processor and that's not something that's going to matter anyway. Assigning a specific CPU is called setting "affinity" and I recommend you just ignore the whole concept.
Each client needs a unique value for MachineID, but MachineID is not related to processor number.
By the way, I should have said something sooner. Welcome to the FoldingForum.
Thank you for all the help and the welcome =]
I'm very computer literate, programming in VB6/C++ so I know what I'm doing for the most part.
Currently I have the GPU2 console + 2x UNI running with WinAFC spreading them between the two CPU cores...hopefully this will provide maximum ouput for my current setup @ 12-16 hours a day.
Each uni should have a core for it's own, not two processes shared on two cores ( because of cache ).
The gpu2 should also not be spread over two cores but kept on one core for the same reason.
Smp offcourse does much more ppd that's right.
Also welcome btw, hope you're getting bitten by the same virus we all are ( the f@h virus, it's untreatable and hard to live with since you're contantly trying to fold more proteins quicker then before ( and sometimes reallity get's in the way of doing so )).
MtM wrote:Each uni should have a core for it's own, not two processes shared on two cores ( because of cache ).
The gpu2 should also not be spread over two cores but kept on one core for the same reason.
Smp offcourse does much more ppd that's right.
Also welcome btw, hope you're getting bitten by the same virus we all are ( the f@h virus, it's untreatable and hard to live with since you're contantly trying to fold more proteins quicker then before ( and sometimes reallity get's in the way of doing so )).
Yes, that's what I was doing...
I had 2 folders setup, folder 1 and folder 2. Each UNI client set to "idle" and 100% CPU usage, then I used WinAFC to set folder 1 to PAIR0::CPU 0 and folder 2 to PAIR0::CPU 1.
I'm going to stick with the SMP for now, it seems to work at the same pace, and will give me more PPD in the long run =]
Sorry wasn't entirely clear to me, should have asked before I jumped to a conclusion. Smp is the future, glad you're happy with how it runs on your machine. Again sorry for making an assumption on to litle information, I hate when it happens to me and yet here I was doing it to you
MtM wrote:Sorry wasn't entirely clear to me, should have asked before I jumped to a conclusion. Smp is the future, glad you're happy with how it runs on your machine. Again sorry for making an assumption on to litle information, I hate when it happens to me and yet here I was doing it to you
It's fine, sorry for not being more clear, blame me this time around...but don't let me see it again ! Ha
Well yes, for the most part the SMP seems to work quite well for me, but I have yet to find the "proper" way to shut it down via console. I've been using CTRL+C, but it keeps telling me that's incorrect. I'm not sure of another way that I've seen to do this...hmm.
Ctrl-c is the only proper way, as it sends a message to every child process/thread which runs below the console. It *should* make sure each worker process exits cleanly.
if you close with ctrl-c you're doing it the right way. The message 'working with standard loops' is false.
Only issue there could be is if you close the client with ctrl c and close windows immidiatly after ( the child process fahcore_xx.exe need time to properly exit ).
mpich2 process manager or Deino MPI process manager depending on which client. Don't need a bat file, and stopping the service that way changes it startup type from automatic to manual so watch out with it.
MtM wrote:mpich2 process manager or Deino MPI process manager depending on which client. Don't need a bat file, and stopping the service that way changes it startup type from automatic to manual so watch out with it.
Oops, I meant the GPU2 console client, my apologies...looks like there is no "alias" for it...so I have to use:
)).
