Nope.. I saw those... the fold@home smp faq said not rec. for dual core, but fine for quad. so I steered clear. maybe I'll go ahead and give smp a shot later today... I also also saw something about running 2 instances in different folders for the reg client, and setting affinity... but I'd rather use smp if it works with the x2 boxes...
anyway, here's where I saw the dual core faq:
http://folding.stanford.edu/FAQ-SMP.html
KNOWN BUGS, COMPATIBILITY ISSUES, AND RUNNING NOTES
Please note that this is a beta release. While we have done lots of testing in house, there are limits to the bugs we can find in these limited tests (and hence the need for a beta test). Thus, we expect that there will be many problems with the client that need to be resolved. Below is a list of some of the relevant known issues or bugs for beta testers of this new client.
Known Bugs and issues
1. The core needs some time (often as much as 4 minutes) between work units to finalize work.
2. Printing to the log file sometimes gets weird due to multiple threads
3. The Linux client (and sometimes the OSX client) does not correctly detect RAM levels 2GB or greater. In this situation, please make sure to set the RAM by hand in the client configuration process (to reconfigure, run the client with the -configonly flag). If the memory is not read correctly, it defaults to a very low value. If your OSX client detects some huge amount of memory (eg 4294965248 MB), then you need to configure the RAM by hand with -configonly.
4. The core will print "No option -tpi" 4 times during the start up of the core
5. The core does not clean up its work files completely (can leave several files after the WU has completed)
Notes for running
1. We strongly suggest people run this client on 4-core boxes. While it will run on 2-core boxes, we have noticed some potential problems (we are looking into these issues now).
2. Most SMP WU's will be "big" WU's, so you'll have to configure the client that way. During the client configuration, when the client asks "Allow receipt of work assignments and return of work results greater than 5MB in size (such work units may have large memory demands) (no/yes)" say yes.
3. There is a brief pause (15-20 seconds) at the end of each WU. This is so we can make sure all the threads sync up. This is not a bug, as much as a limitation of SMP needing to synchronize the threads before moving on to the next WU.
4. The SMP core can get confused about disabling SSE, so we suggest running with the -forceasm flag if you notice that the SSE was disabled unnecessarily.
5. The linux client is a 32-bit executable, as we are planning on using a single client binary for SMP and non-SMP. However, this means that 64-bit linux distros will need to have 32-bit ELF support enabled.
Policy Notes
1. The client will stop working after 2 months (this is a limited release beta -- new clients will be available before the current version ends its test period)
2. Deadlines will be set to be much shorter than normal, as we need to get data back quickly in this beta test and we are releasing to a very specific set of hardware. This will likely change in time, as we move from a beta test and as we move towards supporting other platforms. However, the deadlines will be much shorter than the deadlines for normal WUs (as the reason for high performance clients like the SMP client is high performance!).
3. If a server with SMP WU's is not available or is overloaded, the client will be assigned to 0.0.0.0, which tells the client to wait and try again. As more SMP servers come on line, this won't be an issue, but during the beta test, we want to keep the SMP clients crunching SMP WU's.
Previous bugs believed to be fixed in the current version
1. Checkpointing is currently not supported (this means that if you quit the client and then restart it, the client will start from the begining of the WU). We will support checkpointing in future beta versions (hopefully released in a week or so), but it is a known issue that checkpointing is not working reliably in the current version.
2. The core can sometimes get confused about whether the previous core ended cleanly and will turn off assembly loops. For now, we strongly suggest that people run with the -forceasm flag.
-------------------------
*Q6600@3330mhz 1.35v - True120 | Abit IP35pro | 2x2GB Gskil | 2 x EVGA GTS 250- shader 1890 | Corsair HX520 | OCZ Vertex 60GB/Seagate 7200.11 500GB
*x4 810@3250mhz 1.32v - Xigmatek S1283 | MSI K9A2 CF-F 790X | 2x1GB Kingston HyperX | 2 x MSI GTS 250- shader 1890 | Antec EW 500
*Q6600@3330mhz 1.36v - Scythe Mugen | Gigabyte GA-P35-DS3L | 2x1GB Ballistx | XFX GTX 260 (192) shader 1512 | OCZ Stealth 500w
Search Topic
08/27/2007 05:46 AM
