Well, here's the reason why it's not working (not an app issue)
(parameters_generated_1211968864_1027907)

As for dual booting, that's an option I guess, but I think I'd be switching around quite a bit, considering I do a lot of DirectX programming as well. (not to mention some GLSL stuff that's very easy to test in windows)

Either there is a huge difference in the motherboards, or the Phenom @ 2.5 is kicking the c#*p out of the Q6600 @ 2.9. Methinks AMD has a few secrets beyond ghz.

What say you?

Wish I could push my X2 3800+ further but its mobo won't go beyond 230MHz FSB (no PCI lock)

So switch the dual core into the good board. One of my X2 3800's is doing 2.8 on an nforce 4 board. Might as well use the single core with the Via chipset.

One of my budget backup boxes got a tune up today, running a new install of Hardy 64. It's an AMD 939 X2 3600 (2 X 256 L2) pushed to 2.7ghz, with 2 sticks of Geil pc 4000.

Best completion time is 249 seconds.

Hmm, I'm a bit overwhelmed by all the response

My machines aren't getting any new WU's, which is confirmed by the server status page, where it says 0 WU's ready to send. All services seem to be running, so is there a problem somewhere?

by faking the number of cores/CPUs with a certain program I won't mention (and don't use)

<-- uses it without speaking a word of French. :P But no matter what it's set to it won't DL more work than the limit set in your prefs. So if you're set at 0.1 days work that's all you'll get at any one time.

Be thankful my very old laptop doesn't have enough memory to run a Milkyway WU - its benchmark is about one third the speed of the above host!
And yes, I do actually get some credits for work done on it.

Q9550 overclocked 20% to 3.4GHz now. Completion times 155-158s. See http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=14685

I'm no expert on the server-side options of BOINC, but a search of the BOINC site shows the following seemingly relevant config options (at http://boinc.berkeley.edu/trac/wiki/ProjectOptions):

<max_wus_in_progress> N </max_wus_in_progress>
<min_sendwork_interval> N </min_sendwork_interval>

Here's what it says about that last option:

min_sendwork_interval
Minimum number of seconds to wait after sending results to a given host, before new results are sent to the same host. Helps prevent hosts with download or application problems from trashing lots of results by returning lots of error results. But don't set it to be so long that a host goes idle after completing its work, before getting new work.

What we are seeing on fast hosts, particularly with short (2 credit) work units is exactly as described - they run out of work before they are allowed to connect again... This may become even more prevalent if the new applications are faster.

Perhaps if that were set to 5 or 10 minutes, things would run more smoothly

numbers game ok, but it's rather a matter of CPU's than members.
We've a very large majority of "little" crunchers among the 500.
And don't be so modest, Aussies are really serious and interresting challengers.

ps : I never received a response to sign in the guest part of your forum