Thanks Sekerob

So what does 'inconclusive' mean in Results Status? I'm not being credited anything for these results.

Each work unit is sent to 3 hosts to be crunched. If the 3 results are all error free when they return then they are compared. If they match well enough then they are declared valid and credit is awarded to the hosts. If they do not match they they are declared inconclusive and a 4th work unit is dispatched. If it returns error free then it is compared with the first 3 results. Usually 3 will match so they are declared valid and then they receive credit. The one that does not match is declared invalid. If any result returns with an error then it receives error status and another work unit is dispatched in its place. When 3 match they have what is referred to as "the quorum of 3" or simply "the quorum".

Since making the report that started this thread, the same pc has had two more such uncredited work units in the last two days. Three other machines have crunched without incident. I have to start to think that this may be hardware related somehow.
Machine in question has a AMD A64 3500+, running at stock speed of 2.2 gHZ, with a gig of PC3200 RAM, running XP MCE 2005. It is used for crunching only and is less than a year old.

I've shut this rig down for now to avoid any further data corruption and to try and figure out what's going on.

Then again, maybe it isn't hardware at all. Just had an early, uncredited abort after 35% completion on another pc. This one much like the other but with an A64 3400+.

Was HPF2 tested in beta before release? If so, what kind of hardware was it tested on? Since there is no mention of a beta program on these boards, I'll have to assume that there was no testing, at least not by members. For the hardware, my guess is that the platform for any testing would have been on Intel hardware, they being the current predominant cpu maker.
In the last couple of years, AMD chips have been adopted by many serious crunchers in greater numbers than Intel, due to their supposedly superior fpu capabilities. I'm not going to argue that point here because, frankly my dear, I don't give a d*mn. I use both. My point is, since the platforms handle calculations differently, testing on both is very important to insure operational similarity and success. This is something for the "geeks" to figure out.

If it helps, here are some details of the agents running on the two pcs':
#1 that has lost 3 units - Device ID: 345145
#2 lost 1 unit - Devive ID: 324152
Both are Agent Version 3 (2844)

Sorry I don't have a record of the work unit numbers involved but I imagine those can be recovered from a search of the Device ID histories.

John Galbraith wrote:


John, can you please use the support emails and give me the device ID number (in the preferences window (checkmark icon) of the agent) of the UD device having the problem and the time in UTC about when it was working on the work unit in question. I should be able to identify the work unit in the logs using this information. There are a small number of work units which are causing Rosetta to abort and your's might be an example which we can use in our investigation and testing. We are testing some fixes in Rosetta before deploying a new version to the whole grid and such work units will be helpful for testing. Thank you for your assistance and patience.