6.24R3 windows SMP client released --Expiration July 4, 2010

[kasson]

We have posted the drop-in replacement binary for the windows v6 client. This can be found at:
http://www.stanford.edu/~kasson/folding ... 32-x86.exe
MD5 checksum: 5c14c566e11b69273477d7ca102c40c4

Refreshes of the full packages will follow.

This client has only minor modifications from the 6.23 client (it is near-identical to the 6.24 client currently released for Linux and OS/X). We are anticipating a major set of changes to the SMP client over the next several months, but we aren't quite there yet. Keep your eyes out for updates. (There are some big improvements to the SMP cores underway, and they will necessitate some new client code.)

As stated in the thread title, the 6.24R3 client will expire July 4, 2010. Assuming our new SMP cores are on schedule, you may wish to upgrade earlier, however, as we hope to phase out the SMP A1 core as we switch to the new future cores. But we'll release more details when the new software is released (date TBD--development is still ongoing).

Thanks for contributing to the project!

[geokilla]

Can it be? A2 cores?! Weeee!

Should we finish our WU first before dropping in the new client? I don't wanna risk losing my WU.

[7im]

With SMP Windows, you always run a small risk of losing a workunit on every restart. The risk keeps getting smaller as the client improves, but why risk it? Patience is...

[Rum@NoV]

My wu resumed fine after dropping in the new .exe But as 7im said, there's always a risk.

[tjmagneto]

I have to check this out. Thanks!

[bruce]

Can it be? A2 cores?! Weeee!

You're probably making an unwarranted assumption.

Kasson said "we hope to phase out the SMP A1 core as we switch to the new future cores" He did NOT say whether it would be the A2 core or something else. Moreover, since he used the word "cores" it's not hard to guess that there may be more than one replacement for the A1 core. Only time will tell.

[Zagen30]

Can it be? A2 cores?! Weeee!

You're probably making an unwarranted assumption.

Kasson said "we hope to phase out the SMP A1 core as we switch to the new future cores" He did NOT say whether it would be the A2 core or something else. Moreover, since he used the word "cores" it's not hard to guess that there may be more than one replacement for the A1 core. Only time will tell.

a2, GRO-A4, something else; whatever it is, I think the hope is that the replacement core(s) will use our processors as efficiently as a2 does (or more, that would be acceptable, as well ). I'm not particular on what it's called, as long as I'm maximizing my hardware's folding capability. It'd also be nice to not have to emulate Linux to maximize PPD, thus saving on the emulation overhead.

[rbpeake]

....It'd also be nice to not have to emulate Linux to maximize PPD, thus saving on the emulation overhead.

Agreed, although the emulation only uses 2 cores at a time, leaving 2 cores available for other aspects if one so wishes. The new Window SMP may use all 4 cores, with no choice to use only 2.

[bruce]

....It'd also be nice to not have to emulate Linux to maximize PPD, thus saving on the emulation overhead.

Agreed, although the emulation only uses 2 cores at a time, leaving 2 cores available for other aspects if one so wishes. The new Window SMP may use all 4 cores, with no choice to use only 2.

As long as you've got enough RAM, it shouldn't matter. If you use two cores for a normal priority job, FAH SMP will happily reduce it's consumption to two since it's at a lower priority and then scale back up whenever your foreground activity is suspended/stopped.

[kasson]

Yes, although if you're running in a VM, sometimes VM's don't play nice...

[rbpeake]

...As long as you've got enough RAM, it shouldn't matter. If you use two cores for a normal priority job, FAH SMP will happily reduce it's consumption to two since it's at a lower priority and then scale back up whenever your foreground activity is suspended/stopped.

Thanks, that is good to know!

[rbpeake]

Yes, although if you're running in a VM, sometimes VM's don't play nice...

Knock on wood, so far my 2 VM instances are playing quite nicely! (But I think if I had any intensive use planned on my PC, I would probably close one or both of the VM's just to be on the safe side! )

[tjmagneto]

Yes, although if you're running in a VM, sometimes VM's don't play nice...

Knock on wood, so far my 2 VM instances are playing quite nicely! (But I think if I had any intensive use planned on my PC, I would probably close one or both of the VM's just to be on the safe side! )

I run 3 not Fred VMs on my i7-920 with HT enabled and they are pretty happy. If I'm doing some light work I can get away with leaving my VMs running. When it's time to game, they all get closed along with the GPU client.

[toTOW]

Why are we talking about VM in a thread dedicated to Windows SMP client ?

[shdbcamping]

Why are we talking about VM in a thread dedicated to Windows SMP client ?

It is possible to run Windows SMP inside another OS VM. Not sure why one would, but they could.