Arkaine23
01-07-05, 09:40 AM
Sticky this!
What are big packets?
Since the release of the 5.xx series folding client, Stanford has offered a new option to select work units that are extremely complex. These work units often take longer to fold, and cause the folding core to use significanlty more ram (as high as 154MB to date that I've seen). They also tend to exceed 5MB in size for uploading/downloading (some I have right now are 21MB). These work units take the folding project in some new directions. By their nature, high-end systems are best-suited for folding big packet work. Fast systems tend to have more ram installed and to be able to crunch the data quicker, so overclocking teams such as our own can really help contribute to this new aspect of the folding@home project.
What CPU's can benefit using them?
So far all big packet projects have been GROMACS. This means only CPU's with SSE can really get the most from them. SSE CPU's:
Pentium 3 above 500mhz
Celeron above 500mhz
Pentium M
Pentium 4/Xeon
Duron above 1000mhz
Athlon XP (all cores)
Athlon 64/Opteron (all cores)
CPU's with 3dnow! but no SSE should get some small gain, but they might still fold large tinker work units more efficiently. I have not had a chance to analyze how well these can handle big packets vs regular WU's:
Old Athlons (not XPs)
Old Durons (below 1000mhz)
Tip: If you have one of ^ you might want to upgrade to a cheap Athlon or Duron with a newer core if you motherboard supports it.
What about ram?
You'll want to have at least 150MB of ram free to be able to fold these without suffering from excessive swap useage. Also, keep in mind that with folding running all the time, this amount of ram would not be available for anything else. Not every big packet project uses this much ram. Some that I've seen have been as low as 60MB.
So... For a dedicated Windows big packet folding box you'd want at least 256MB installed. For a dedicated Linux big packet folding box running in text mode, you could get by with 192MB, or 256Mb for most GUI's. Running two instances would naturally double this requirement for say duallies or P4's with HT, however if the 2nd instance does not use big packets, then consider it more like and additional 5-30MB for the client doing regular work units.
For a system you plan on actually using you should consider more like 384MB or 512MB as the minimum amount of ram for folding big packets. And you may find yourself turning folding off to play games or benchmark and then turning it back on when done...
Tip: Disabling unused services and keeping close tabs on what starts up (with msconfig or xsetup for example) could help you maximize your free ram.
Why bother?
Stanford rewards people who elect to fold big packet projects by giving a 100% point bonus. They are worth double their benchmarked value. example- currently there are several projects worth 600 points, but they take about as long as a 300 point WU would take to complete. This is to offset the longer upload/download time for dial-uppers and also as reward for working units that take up more system resources.
Tip: Admins and employees and students be warned about increased BW useage if folding at work or school (with permission) when big packets are enabled.
How do I get them?
1) Use a 5.02 or newer folding client.
2) When configuring there is a question about whether you want to receive work units in excess of 5MB. Choose yes. Or if editing a client.cfg manually, the option is bigpackets=yes
3) Launch folding with the -advmethods flag by editing the registry (service install), or by editing target line of the shortcut you use to launch folding. Service installers tend to have -advmethods already set in the registry for you. -forceasm is also a good idea to use since if your client ever errors or shuts down wrong, it would disable SSE on the next WU if you did not use this flag.
-advmethods disclaimer: This flag will steer your folding client to get work units which may be less stable than those in standard ciculation. Its not uncommon to have WU's that do not complete. Most of the time you will get partial credit if part of the work unit can be returned to Stanford. If the errors are not recoverable, no credit would be given at all and production might suffer slightly. Overall though, I have not seen many lost WU's and the PPW gain for these units has always been advantageous.
What are big packets?
Since the release of the 5.xx series folding client, Stanford has offered a new option to select work units that are extremely complex. These work units often take longer to fold, and cause the folding core to use significanlty more ram (as high as 154MB to date that I've seen). They also tend to exceed 5MB in size for uploading/downloading (some I have right now are 21MB). These work units take the folding project in some new directions. By their nature, high-end systems are best-suited for folding big packet work. Fast systems tend to have more ram installed and to be able to crunch the data quicker, so overclocking teams such as our own can really help contribute to this new aspect of the folding@home project.
What CPU's can benefit using them?
So far all big packet projects have been GROMACS. This means only CPU's with SSE can really get the most from them. SSE CPU's:
Pentium 3 above 500mhz
Celeron above 500mhz
Pentium M
Pentium 4/Xeon
Duron above 1000mhz
Athlon XP (all cores)
Athlon 64/Opteron (all cores)
CPU's with 3dnow! but no SSE should get some small gain, but they might still fold large tinker work units more efficiently. I have not had a chance to analyze how well these can handle big packets vs regular WU's:
Old Athlons (not XPs)
Old Durons (below 1000mhz)
Tip: If you have one of ^ you might want to upgrade to a cheap Athlon or Duron with a newer core if you motherboard supports it.
What about ram?
You'll want to have at least 150MB of ram free to be able to fold these without suffering from excessive swap useage. Also, keep in mind that with folding running all the time, this amount of ram would not be available for anything else. Not every big packet project uses this much ram. Some that I've seen have been as low as 60MB.
So... For a dedicated Windows big packet folding box you'd want at least 256MB installed. For a dedicated Linux big packet folding box running in text mode, you could get by with 192MB, or 256Mb for most GUI's. Running two instances would naturally double this requirement for say duallies or P4's with HT, however if the 2nd instance does not use big packets, then consider it more like and additional 5-30MB for the client doing regular work units.
For a system you plan on actually using you should consider more like 384MB or 512MB as the minimum amount of ram for folding big packets. And you may find yourself turning folding off to play games or benchmark and then turning it back on when done...
Tip: Disabling unused services and keeping close tabs on what starts up (with msconfig or xsetup for example) could help you maximize your free ram.
Why bother?
Stanford rewards people who elect to fold big packet projects by giving a 100% point bonus. They are worth double their benchmarked value. example- currently there are several projects worth 600 points, but they take about as long as a 300 point WU would take to complete. This is to offset the longer upload/download time for dial-uppers and also as reward for working units that take up more system resources.
Tip: Admins and employees and students be warned about increased BW useage if folding at work or school (with permission) when big packets are enabled.
How do I get them?
1) Use a 5.02 or newer folding client.
2) When configuring there is a question about whether you want to receive work units in excess of 5MB. Choose yes. Or if editing a client.cfg manually, the option is bigpackets=yes
3) Launch folding with the -advmethods flag by editing the registry (service install), or by editing target line of the shortcut you use to launch folding. Service installers tend to have -advmethods already set in the registry for you. -forceasm is also a good idea to use since if your client ever errors or shuts down wrong, it would disable SSE on the next WU if you did not use this flag.
-advmethods disclaimer: This flag will steer your folding client to get work units which may be less stable than those in standard ciculation. Its not uncommon to have WU's that do not complete. Most of the time you will get partial credit if part of the work unit can be returned to Stanford. If the errors are not recoverable, no credit would be given at all and production might suffer slightly. Overall though, I have not seen many lost WU's and the PPW gain for these units has always been advantageous.