What to do, what to do

ok I have 2 options:
1) run the GPU client in windows at 1500-2000ppd (according to FahMon)
or
2) run the linux SMP client in a stable OS at 1200-1600ppd (according to FahMon in linux)

help me decide people

How unstable are you finding the GPU client in windows?

the SMP client is unstable in windows (before I ever had the chance to run the GPU client)
the GPU client is stable and works well in windows
the SMP client is stable and works well under linux...

So for now I am just letting it run through some of the GPU WUs... then when I disappear from home for 9 days I will switch it to linux where I won't need to worry about restarting the PC (of course will have to worry about the wife tampering with my system as she is prone to do).

Only under 64 bit flavors of Linux. It doesn't work at all on 32 bit flavors of linux, and its not clear if Stanford considers this a bug or a feature

true... but ever since the Athlon64s came out, any linux I install has been the 64-bit x86_64 version (unless it is an older machine, then I get the i686 installed). Especially nowadays when most available applications are not "bit" dependent, and if there is one that is 32bit only, you can install the 32bit libraries needed "ia32-libs" with no performance or "virtualization" hit.

That's your choice. It was not mine. 64 bit code is bigger. Not a problem when you have 8GB or more of ram, more of a concern with only 3GB.

I'm more than a little torqued that the Stanford folks blithely assume that everyone wants 64 bit OS. I don't. Then again, they are Stanford, they are smarter than all the rest of us.

Most of my systems only have 1-2GB of RAM since they are home machines, not commercial servers and I have had zero problems with them.
My main system (in my sig) runs x86_64 with 2GB of RAM very fast and very well... I can understand where the overhead may be worth running the 32bit in a commercial environment but native 64bit code running on native 64 bit processors will run that code much faster... this is because the system will fill up the registrars either way... if a single registrar is 64bits wide, current 64bit processors using AMD64/EM64T are designed so that 32bit code will still use the entire 64bit registrar. It is like 1 big truck traveling down the 2 lane highway... the other lane is open but because it is only designed to run that single truck at the time, other trucks need to file behind it signle file to get to the destination....
64bit is like 2 trucks side by side with the same load each which will means more of its payload will get there and faster than a single truck will. It may take up more room at the storage warehouse but there is more data that can get done in a much faster time frame....

from a computer perspective, this is a 1MB 32bit file compared to a 1.1MB 64bit file. Over the entire system it may take an extra 1GB but I found the speed of native 64bit code to be much more efficient than using 32bit code on 64bit hardware.

but you are right, this is my preference

And I thought that was just because Linux runs better....

I am not aware of any programs that I want to run (OK, SMP folding) that are only available in 64bit code. Most of the time, its just a variable in the make file, which can be auto set by the configure script.

When you are in 64 bit mode, there are more registers in the CPU, and that is a good thing. The more registers, the less you need to use memory, and any memory is way slow.

considering AMD has had the onboard memory controller for some time now, that gets rid of one roadblock, and with Intel adding them in finally (what 5 years later) that should help the memory along even better... but the real slowdown tends to be on heavy I/O applications where either the network or hard drive is the choke point.
with tri and quad channel memory coming soon from Intel plus at least a 1300MHz bus speed at the CPU and memory, it is less so nowadays than it may have been previously.

MTCW (my 2 cents worth).

I am folding on my quads with 2 x SMP and 1 x GPU on Vista 32.

All are generally stable :- except for some projects in particular that are known to give occasional problems like SMP 2665 and when I have to load OS updates (which is when I try and back up the folders before restarting so I can restore in case the SMP client trashes them when it restarts, which it seems to be good at).

I am using the SMP extended deadline 5.91 console client, not sure if that makes the difference (stability wise). I am using the GPU 6.2 tray client,

As Python has mentioned I will need to move up to the newer SMP clients before the extended deadline runs out. I must say I like it much more than the console client and will try and upgrade the SMP to tray when I do.