RickH, my HT machine is not extreme, plus alternates between FAAH & HPF2, whatever WCG sends. My log shows 29 HPF2 completed of which 2 invalid (5.06 from early days). Not seen a single 1 bombing or hanging permanently, sometimes sticking in one percentage spot, but CPU counter uninterrupted until 100%. Sometimes it will just sit there for longer time at the end, probably doing some indexing of the result and prepping it for transmittal barely using CPU time. Last few days even figured out to uptimize for HT, running UD+BOINC simultaneous......just happy as a clam, so guess i'm fortunate.

On your hi probability observation with the XP platform, I believe to have read that WU's send / the results returned for different platforms are not mixed i.e. macs go to macs only, linux to linux, win to win. Stand to be corrected on that. ***

Coming BOINC version has CPU instruction set recognition, so it will allow even more precise distribution and result matching.

Errata: As i was writing, now see Didactylos was faster to hit the send button....at least its not a factor in the inconclusive mix.

One of the techs did mention that some issues were caused by problems on the client, not with the work unit. You should be prepared to learn that it's something you have to fix yourself.

Might not be, though. We're not likely to get much further until after the weekend.

And you're right - the techs can easily mine the database for invalid results. What they are most interested in are stalled or abortive work units, and what happened when they died.

Well, standard defensive "it can't be ME" reaction aside, this machine is rock solid. Prime95 stable for 24+ hours, never got Invalids or Errors from HPF1, FAAH or other DC work.

I would argue that HPF2 should be expected to work on any system which can crunch other BOINC and similar DC projects for weeks or months without errors.

If HPF2 has managed to find some obscure thing that affects only it, on systems that work flawlessly otherwise, then pragmatically speaking, it's still going to end up as HPF2's problem to cope with.

If it turns out that on AMD X2 systems with socket 939 and PC4000 RAM the floating point FUBAR instruction (used only in HPF2) gives results which are wrong in the 15th decimal place, HPF2 will have to find a way to work around it.

Of course, if it turns out that only my system has such an error, then I'll just have to switch back to FAAH or something. There's no way I can find or fix such an obscure thing, when the machine runs perfectly otherwise and I have no other clues.

AMD 939 Socket times 3 is not a great statistical value, but if WCG have the capability to analyse which processors cause the large fallout, they will..... Think WCG knows what CPU it sends to or receives from in reasonable detail. Soon it will optimise as it will also be looking at the instruction sets of CPU's (BOINC Only?).

My P4 2.53 HT has done now 30 odd HPF2 of which 2 invalids on 5.06, and rest valids, all 5.07x, 1 is pending validation. Not many but confirms to me my platform stability.....i.e got 100% on HPF2 5.07x.

.....since my last re-image i boot only when required by software updates....that's now well over 7x24 ago, maybe come 'critical patch' Tuesday again. Used to have a BSOD every 3rd day, due a very hi memory address intermittent.

PS FUBAR, i'm not too familiar with american acronyms but recollect something that sounded like foobar

I got one of those errors recently and result just returned to WCG as follows:

Device Name: BlackBart00 Team ID: Boinc 10296 Acct Nr: 205644

Project Applic Name Report deadline Status

WCG hpf2 5.07 za110_00549_0 7/15/2006 10: Computation Error
7/9/2006 4:59:13AM Unrecoverable error for result za110_00549_0 (The environment is incorrect. (0xa)-exit code 10 (0xa))

hope this helps
PaulT