High duration workunits with result overflow

[sunu]

With the new 2.4 Win32  Chicken soup I'm seeing very high duration workunits that end up with result overflows.

Usually workunits with result overflows are discarded after a few seconds/minutes of computation. Now I am seeing many workunits with 15000+ sec computation times ending with result overflows giving me only 0.x credits.

Check this workunit http://setiathome.berkeley.edu/workunit.php?wuid=147539615

If you see both results, we are both using Chicken optimized apps. Mine is the P4 2.8 Ghz. The second result is from a C2D E6600 and it took him almost 11000 sec for this workunit and we ended up getting 0.43 credits!!!

Is there something wrong with the new apps?

I have many others such as  this one that are waiting validation. Check this http://setiathome.berkeley.edu/results.php?hostid=3690316&offset=20

[Richard Haselgrove]

Joe Segur has been looking into something similar for us on the main SETI board:

http://setiathome.berkeley.edu/forum_thread.php?id=41541&nowrap=true#619629

If your WU data has the same characteristic - negative <triplet_thresh> - then it's a splitter problem, not an application problem.

Joe's extremely good advice is to suspend any such workunits, until the project can cancel them: if you abort them, they'll just get re-issued to some other poor unsuspecting sucker!

[sunu]

I also just saw that thread. This isn't a chicken thing.

Well, we just have to wait for the little quirks of multibeam workunits to get ironed out. 

[michael37]

Nothing but lots of frustration with these workunits