Albert: Validate Errors

I'm sorry, but you don't have to suspend a task at all.  You may choose to do that, but it certainly isn't necessary.  If you do so, you may well lengthen the time it takes to complete a task because, if the task isn't kept in memory when suspended, it would need to start from a somewhat earlier point in time, when you remove the suspension.

You have posted in a thread referring to the test site, albertathome.org.  Your tasks list here at einsteinathome.org shows that you are crunching the normal FGRP5 gamma-ray pulsar tasks and the current tasks for the Gravity wave tuning run.  Are you crunching test tasks at albertathome as well?  I'm guessing that perhaps you are not and that perhaps you have inadvertently chosen this topic without understanding the difference between the two sites.

This sounds like you are referring to the 'two crunching stages' behaviour (the main stage and the follow-up stage) for the processing of FGRP5 tasks.  If so, have a look at this thread to understand what is happening.  In addition, you need to be careful about assigning importance to estimates of the remaining crunch time.  Because there is no ongoing progress of the % completed during the follow-up stage, BOINC will be fooled into increasing the estimate of remaining time because it can't know that there is progress until the very end when the % completed jumps straight to 100%.

When you suspend a task, it may remain in memory ready to proceed immediately when allowed, or it may be removed completely, depending on your BOINC settings.  At regular intervals while crunching, the current status of a task is saved on disk as a checkpoint file. If you suspend a task and your settings say it should be removed from memory, it will be.  In that case, when the task is resumed, it will be reloaded into memory from a checkpoint file, if such a file exists.  Usually, the interval between checkpoints is of the order of several minutes but it can be a lot longer than that.  So it is possible to see a resumed task go back to an earlier stage when it's reloaded from a checkpoint file.  If you have sufficient memory (these tasks can be large) you can save the waste of some crunching by keeping tasks in memory when suspended.  Better still, stop suspending tasks.  It's not needed in normal circumstances.

I had a quick look at your current list of invalid tasks.  There is just one marked as invalid and 131 that are valid.  Different hardware, different operating systems, different compute libraries can all have an impact on the precise final results returned to the project.  It's generally accepted that these small differences cause approximately 0.5% to 1.0% of tasks to fail validation.  Since you have 1 out of 132, that seems pretty normal.  It is unlikely that an invalid result would have anything to do with a task having been suspended at some point.

This thread was about a different type of error - a validate error, and over at albertathome.org, the test site.  A validate error is one where what was returned to the project is so scrambled that it can immediately be declared as rubbish without having to go through the formal validation process.  These are usually caused by hardware problems or equipment being operated well outside the normal limits (inappropriate clock speed or voltage adjustments).  You have no examples of validate errors.