The length of validation is completely dependent on who else gets the same copy of workunit as you do. This means that any number of factors can cause the delay: user quits and the workunit must reach its deadline before being sent out again; other user's computer doesn't come up with the same result yours does and thus must be send out to additional computers for "tie breakers"; other users computer trashing results.

Some people have workunits dating back 6 months or longer before they're validated.

I'm not sure why you'd stop running SETI over an issue like this when the data we're working with is not time-sensitive.

As a follow-up, I decided to investigate which workunits you were referring.

I found this workunit (note this URL will not be valid once the workunit has been validated) which you were given on July 16th and you returned the result the next day. Your quorum partner also downloaded the workunit on the 16th and hasn't returned their copy yet. They have a deadline of Sept. 11th. If they do not return their copy by then, a third copy will be sent out with a longer deadline, meaning a longer delay in getting credit validated.

I also found this workunit (same as above, this link won't be valid once the workunit has been validated) which you were given on June 30th and returned the result on July 1st. Your first quorum partner downloaded on June 30th but reported an error while crunching on July 8th. At this point another copy was sent on July 8th to a different computer which hasn't returned their result yet. They have a deadline of Aug. 31st. If they fail to return their copy by then, another copy will be sent out to another computer with a longer deadline, which will delay getting the workunit validated.

This is the nature of SETI@home. As I stated above, some people have workunits pending for 6+ months under certain circumstances. The only "fix" for this is to give out shorter deadlines - but that prevents slower computers from being able to complete the work on time, or computers that are not on 24/7. This is not a compromise that the Project Administrators are willing to make as it violates the principle of the project that states anyone should be able to donate their spare CPU cycles to the project.