It would, I am sure, streamline SETI processing if all "In Progress" units prior to the date of any computer merge could be aborted in the merging procedures. Otherwise they just stay frozen until their completion expiry date about a month later.

If aborted at the time of merging, these work units would become immediately available for download to another computer/host for processing. Surely this must be a distinct advantage.

Also this allows other computer/hosts to make further downloads when the aborted units are cleared from the quorums (or should it be quora) for their work units. At present the units frozen in the merged computer/hosts are helping to preventing many a quorum from "requesting" a further download.

Surely this proposed "aborting" process must be an improvement to remove those frozen units, both for the merged computer, and for the many other computers unfortunate enough to have any quorums involving any of these frozen units.

I would assume that removal of these frozen "In Progress" units would not alter the statistics for the merged computer. In other words, the RAC and Total Credits would not be affected.

I do hope that this may be discussed, and, with maybe some embellishment, passed on to improve the programming procedures.

Keith

What's the real difference? It washes out in the end. So it takes some 6-8 weeks to finally get done. It's not hurting the science, it's not hurting the crediting system, it's really not hurting anyone. Getting the credits faster does not raise your RAC, because that would settle out again in some time. Think of it as interest on your investment. It will eventually be posted when the right time comes.

---

My movie https://vimeo.com/manage/videos/502242

What's the real difference? It washes out in the end. So it takes some 6-8 weeks to finally get done. It's not hurting the science, it's not hurting the crediting system, it's really not hurting anyone. Getting the credits faster does not raise your RAC, because that would settle out again in some time. Think of it as interest on your investment. It will eventually be posted when the right time comes.

Pooh Bear

The real difference is the smoother working of the SETI project.
The minor annoyance to me and others caused by the delay is of minor consequence.
As for my personal RAC - I don't care two hoots about that.

Keith

Actully, it is possible that work is progressing when a Host ID split occurs. In that case, aborting the work is a mistake as it will get done eventually.

---

BOINC WIKI

Actully, it is possible that work is progressing when a Host ID split occurs. In that case, aborting the work is a mistake as it will get done eventually.

John
I'm not quite sure what you mean by a "Host ID split" as my proposition relates to a host merging process. The only thing that springs to mind possibly is the question of a work unit being processed (i.e. "Running") at the time of the merge. If that is so, only that one partly processed unit is being "sacrificed" (and would be sent out again anyway, if needed) compared with hundreds (or even thousands sometimes) of frozen work units on the merged computer.
That seems right to me, but maybe I am missing some vital clue here?
Keith

Actully, it is possible that work is progressing when a Host ID split occurs. In that case, aborting the work is a mistake as it will get done eventually.

John
I'm not quite sure what you mean by a "Host ID split" as my proposition relates to a host merging process. The only thing that springs to mind possibly is the question of a work unit being processed (i.e. "Running") at the time of the merge. If that is so, only that one partly processed unit is being "sacrificed" (and would be sent out again anyway, if needed) compared with hundreds (or even thousands sometimes) of frozen work units on the merged computer.
That seems right to me, but maybe I am missing some vital clue here?
Keith

The other thing to do is to avoid merging computers until it is likely that all work sent to the old ID is complete.

---

BOINC WIKI

John

I agree absolutely, but reliance on individual hosts always to religiously carry out that chore will not happen. There still would need to be an inbuilt "aborting" process within the merging procedure for those hosts that decide to merge without taking your recommended manual precaution, which you rightly mention.

Another solution, rather than a long processing delay waiting for completion of all units, would be for the host to manually abort all work units not completed, but it is so much simpler and foolproof to include these steps into the programmed merging procedures. Another problem arises in the case of the merging of long time inactive hosts, in which case the manual clearance of "Ready to Start" units might well be difficult to achieve manually.

Keith