Cappy - batting this backwards and forwards isn't going to help your issues regardless of whos right or wrong.........best have a good check for errors/invalids on your results status page for that machine so we can either confirm or disregard whether that is where your problems lie

dude im glad you said that lol i missed it earlier, people think im nuts lol

You're not a liar, Cappy - just misinformed.

I am closely involved with the development of BOINC, so I know exactly what happened.

You can check the release log and see for yourself.

It can also be a problem with bad memory or memory pairs. I took back 2 sets for one computer until I found one that worked under 100% load.

Y'all bring back one of those seti martians you are looking for and we'll talk about it.

"Simple as that" usually means something else.

A couple of asides. If BOINC has memory leaks e.g. it will effect the crunching since the core client and science operate in a 'shared memory' environment. A number of point releases were quickly passed in the 5.x.x. series for this reason (this is my understanding).

Any major release has a well established numbering convention. The 1 in the 6.1 is an uneven hence alpha or pre-alpha. 6.2 will be beta or production and future 6.4.x, 6.6.x in the development path will be too. Only those you will see on the official Berkeley download page. As opposed, what you see in the directory download listing has anything in there to allow e.g. the testers to pull any version or downgrade as some had to do due to e.g. proxy tribulations.

Notably in the crunch3r compile, the log mentions 2 items:

2/24/2008 12:41:12 PM||-cpu_affinity
2/24/2008 12:41:12 PM||-delayed return_results_immediately (1 min)

CPU affinity has been requested at times. Honestly i don't see a benefit to the general crunching populous and to me is very very niche and should be deeply hidden 4 layers down from the Simple View client and only used by the truly experienced.

The delayed return_result is a Ready to Report (RtR) flushing feature for those who can't stand it to wait for the scheduler to clear these. Off and on it is now going to be back in version 6 but not recommended as it does increase the loads on the server side (SETI project tested this and seemingly the load increase was just nominal, so we'll see what happens). Unless your client has problems i.e. is not a reliable cruncher, please don't use this option!

The scheduler really does suck the RTRs up if any single RtR in the Tasks window of BOINCmgr has reached the 24 hour aging status and then clears all newer ones inclusive. My quad flushed last night at 23:32 CET, so i know it will before the end of this day and there are now 50 or so already to be send. There are in fact like 5 conditions that make RtRs to clear (see Start Here forum FAQ for a list down). Automatic Work fetch (initiated by the client and not the user) usually also clears them, long as the user is not modifying the cache and connect settings in between.

Anyway, back on topic, i keep several versions on the disk and backup before upgrading. If it's the customized version in combo with the particular client or something else could best be determined by reverting to an official Berkeley release that includes e.g. for sure all the SSL/HTTPS comms requirements that WCG specifically needs (not sure it's not the source of the problem as we don't have info suggesting it would work with WCG given since Feb 2 there is no stats data for Cappy at WCG).

http://boincstats.com/stats/user_graph.php?pr=wcg&id=345682

cheers
ttyl