Hello [B@H] Kokomiko,
No, it seems easy. If we were running only one project, I am sure that we would already be doing it. But we are already supporting well over a dozen queues on the servers. A few modest optimizations could increase this number to close to a hundred. If we could automate the queues so that the software could handle them without human intervention, it would change the manpower needs. A lot of our programming is on the servers. This year we are working hard developing a system of checks that let us validate results with little redundancy. We will need time and experience to see how it works. The talk when planning this change was to reduce the ratio of work units issued to valid results sent back to the project scientists from 2.1 to about 1.2. (This was just a planning estimate, please don't consider it a true fact.)

So we are busy programming changes that will speed up everything while migrating to larger servers, improving many of the server programs, adding new projects, continuing to change from UD to BOINC on the servers, etc. Multiplying the number of scripts we have to run to keep the server queues working by 4 (or 6 or more) while doing all this just does not seem efficient. The back end that users do not see is much more clunky than the front end. A lot of work has been done to make the front end work smoothly for non-programmers. The back end is much more primitive and manpower-intensive. It needs years of work to make it so automatic that we can think about multiplying the number of queues without wincing or hiring a whole bay of data base analysts to maintain the servers.

The situation is a bit funny because my natural inclination is to try to improve the application programs but I have to argue against this particular method. Anything that increases the number of different job queues imposes large burdens that we have to try to minimize. The critical point is developing validation methods that either allow different versions of programs to work on the same work unit, despite small differences in the results, or allow the server to automatically keep track of which type of computer should get additional copies of a work unit without a lot of manual intervention. Since we always have new projects being boarded for the World Community Grid, we need a variety of solutions to handle the varying problems. There is no one silver bullet that works in all situations.

We need a lot of programming done on the back end before we try to produce a lot of variant programs on the front end with different flags set on the compiler.

Just trying to point out where the problems are.

Lawrence

hmmm, FAAH factor 8. Now how much on DDDT since it uses the same AutoDock science engine? My P4HT used to run them at about 3x of the quad. Been retired since a few months. The quad does about 9x the work a day at virtually the same electricity use, which here is the most expensive in the world I know.

So to the point, Which processor on a newly built system would "Crunch" best? I recently had a power failure which all but destroyed an "older" system. My boss, the fiance has granted permission to build a new system. Recommendations?

Thanks for the advice... I am looking to sinking some money into this system so who knows what I will end up with.

Here's what my Q6600 looks like performance wise if this helps:

dddt0602l0692_ 100279_ 0-- sro1 Valid 08/18/2008 09:25:46 08/18/2008 14:33:30 3.99 90.7 / 90.8
dddt0602l0691_ 100159_ 0-- xxx Valid 08/18/2008 09:14:37 08/18/2008 13:28:32 3.29 74.9 / 74.6
dddt0602l0693_ 100365_ 0-- xxx Valid 08/18/2008 08:25:02 08/18/2008 13:28:32 3.99 90.8 / 95.6
dddt0602l0692_ 100586_ 0-- xxx Valid 08/18/2008 07:43:14 08/18/2008 12:23:22 3.90 88.7 / 89.1
dddt0602l0690_ 100684_ 0-- xxx Valid 08/18/2008 05:47:13 08/18/2008 11:40:24 3.65 82.9 / 78.1
dddt0602l0691_ 100834_ 0-- xxx Valid 08/18/2008 05:08:41 08/18/2008 11:40:24 4.09 92.9 / 93.9
dddt0602l0689_ 100038_ 0-- xxx Valid 08/18/2008 04:44:23 08/18/2008 08:25:01 2.97 67.6 / 67.9
dddt0602l0690_ 100570_ 0-- xxx Valid 08/18/2008 04:29:12 08/18/2008 09:14:36 3.88 88.2 / 89.0

And as it goes for some of those nasty big WU's here's what my q66 did, note this shows how others did the same WU.

Workunit Status

Project Name: FightAIDS@Home
Created: 07/29/2008 20:15:24
Name: faah5010_6fiv_1fiv_00
Minimum Quorum: 2
Initial Replication: 2


Result Name Status Sent Time Time Due / Return Time CPU Time (hours) Claimed/ Granted BOINC Credit
faah5010_ 6fiv_ 1fiv_ 00_ 3-- In Progress 08/17/2008 09:15:37 08/21/2008 04:27:37 0.00 0.0 / 0.0
faah5010_ 6fiv_ 1fiv_ 00_ 2-- Pending Validation 07/31/2008 09:56:29 08/01/2008 10:14:59 23.73 538.3 / 0.0
faah5010_ 6fiv_ 1fiv_ 00_ 0-- Error 07/30/2008 00:18:18 08/17/2008 09:00:17 109.70 543.5 / 0.0
faah5010_ 6fiv_ 1fiv_ 00_ 1-- Error 07/30/2008 00:05:21 07/31/2008 09:45:37 1.43 40.3 / 0.0

Now, to be fair, I do have my Q6600 OC'd to 3.4 up a full 1 Ghz from stock, which is about a 40% performance increase. Yes, I can and have had it higher, but then I need to over volt a lot of hardware components to get it stable and it's just not worth it to compromise the my systems hardware for a few extra Mhz.

Hope this helps you make an informed decision on hardware selection for your build.