Yesterday I upgraded the Boinc client to 5.10.7 from 5.8.16 and have since then seen quite a few of my SETI WUs change their status to "aborted by project". This happened yesterday and now again today... anybody know anything about this? I'm wondering if the new client is causing problems...

---

If two results have already been received before you start crunching yours, it gets aborted.

---

Yesterday I upgraded the Boinc client to 5.10.7 from 5.8.16 and have since then seen quite a few of my SETI WUs change their status to "aborted by project". This happened yesterday and now again today... anybody know anything about this? I'm wondering if the new client is causing problems...

No, its not a client error, it is expected behavior.

S@H has recently enabled a server-side feature that will abort a result on your computer under certain circumstances.

The one that is likely affecting you is when you have not yet started a result, but the project already has that workunit validated (2 others have returned their results for that workunit, and the results are strongly similar), that result on your computer is aborted (because it is not needed) when your BOINC client contacts the scheduler. The newer BOINC such as 5.10.7 can handle this. The older ones do not, so there is no change to their behavior (ie. no aborts).

You are not out of any crunch time in this case, since it only triggers if you have not yet started that result. If you have started it, it does not abort. The only down side is that currently, an 'abort by project' will deduct one from your quota on that machine. But, this should not be a problem, because every successful result returned and validated doubles the quota (up to the max value).

Other cases where results in progress *might* be aborted include when the project determines that results are defective (such as being improperly split), or otherwise canceled by the project. I've only seen this happen a couple of times over at the S@H/Astropulse Beta project when all AP workunits were cancelled due to an error in the AP app under testing.

Again, what I believe to be happening to you is normal. The aborted results in your cache should be replaced the next time the BOINC client contacts the S@H scheduler, and you are not out of any crunch time. I could tell you for certain if you did not have your computers hidden.

Hope this helps.

(test edit)

---

https://youtu.be/iY57ErBkFFE

#Texit

Don't blame me, I voted for Johnson(L) in 2016.

Truth is dangerous... especially when it challenges those in power.

You are not out of any crunch time in this case, since it only triggers if you have not yet started that result. If you have started it, it does not abort. The only down side is that currently, an 'abort by project' will deduct one from your quota on that machine. But, this should not be a problem, because every successful result returned and validated doubles the quota (up to the max value).

Actually you could be out of crunch time in the following case even if you have started the workunit.....

The workunit has started but before the project server had been contacted, the workunit had already met a quorum, credit had been granted, the result was overdue and has been removed from the results database.

In this case, even if you are halfway through the workunit, it will be aborted.

---

You are not out of any crunch time in this case, since it only triggers if you have not yet started that result. If you have started it, it does not abort. The only down side is that currently, an 'abort by project' will deduct one from your quota on that machine. But, this should not be a problem, because every successful result returned and validated doubles the quota (up to the max value).

Actually you could be out of crunch time in the following case even if you have started the workunit.....

The workunit has started but before the project server had been contacted, the workunit had already met a quorum, credit had been granted, the result was overdue and has been removed from the results database.

In this case, even if you are halfway through the workunit, it will be aborted.

True, but note that it is a net savings in crunch time. Being past deadline the result would not get credit if crunched to the end, so the abort saves the time which would have been spent continuing to normal termination.

                                                                 Joe

Upgraded 5.8.16 -> 5.10.7.

BOINC aborted all my WUs that hadn't yet started, and refused to send new ones. ("No work from project.")

Is this expected? Should I not have upgraded?

---

Upgraded 5.8.16 -> 5.10.7.

BOINC aborted all my WUs that hadn't yet started, and refused to send new ones. ("No work from project.")

Is this expected? Should I not have upgraded?

Yes this is happening to most of the wu that have been in your computer for a while. S@H is now requiring only 2 completed results. If you have a wu that has already received 2 wu, and has not been started, then it will be marked as “not needed”. Unfortunately, the report of the unit is marked as "client error". Because of this your daily quota will be reduced. When I did it one computer was allowed no more than 1 wu per day. However, as you return good results your quota will be increased again. A little frustrating, but it will not take long for your computer to get back to it’s normal quota of 100 wu per day.

---

Upgraded 5.8.16 -> 5.10.7.

BOINC aborted all my WUs that hadn't yet started, and refused to send new ones. ("No work from project.")

Is this expected? Should I not have upgraded?

How large of a cache are you running?
If you have a large cache then many of the work units you had in it were probably already validated. A new feature of 5.10.7 is the ability of the project to abort work units that have already reached quorum and validated. Since at the present time the aborted work units show up as a client error your quota was reduced but as soon as you return a few good wu's your quota will go back up.

I'm just guessing, as your computers are hidden so we can't tell by the result data.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

A new feature of 5.10.7

Did you actually type that with a straight face? ;)


This as we are nearly crunching faster than they can split 'em...

You are not out of any crunch time in this case, since it only triggers if you have not yet started that result. If you have started it, it does not abort. The only down side is that currently, an 'abort by project' will deduct one from your quota on that machine. But, this should not be a problem, because every successful result returned and validated doubles the quota (up to the max value).

Actually you could be out of crunch time in the following case even if you have started the workunit.....

The workunit has started but before the project server had been contacted, the workunit had already met a quorum, credit had been granted, the result was overdue and has been removed from the results database.

In this case, even if you are halfway through the workunit, it will be aborted.

Bounty ... let me ask a difficult one ...
suppose quorum is met (suppose 2 results) AND i am NOT running BOINC client 5.10.7 (in that case, if computation has not yet started, i will get an "aborted by project") .... if credit is granted (on the first two host reporting the results) and wu removed from db, am i supposed to get a VALIDATION ERROR upon report of my result (suppose 3rd one) ? If it is like that, i could explain myself some "weird" behavior about a couple of host i am running ...

Hope i made my question "messy" enough :D


M.

---

Bounty ... let me ask a difficult one ...
suppose quorum is met (suppose 2 results) AND i am NOT running BOINC client 5.10.7 (in that case, if computation has not yet started, i will get an "aborted by project") .... if credit is granted (on the first two host reporting the results) and wu removed from db, am i supposed to get a VALIDATION ERROR upon report of my result (suppose 3rd one) ? If it is like that, i could explain myself some "weird" behavior about a couple of host i am running ...

Hope i made my question "messy" enough :D


M.

I beleive aborted by project should happen only if you are running 5.10.7, if the the quorum has been met....however over on Beta, according to Ingleside here on SETI main that might happen with 5.5.1 and above as well. I suppose Joe or Ingleside can shed light on that.

If the wu has been removed from the db then you probably would get a validation error....however with recent changes to the BOINC servers, lot of people who have "report immediately" enabled either because of the BOINC client they are running or because they are using 5.10.7 with connect set to "0" have been getting a validate error.

This is because after uploading the result, it has still not been linked in the db and when the BOINC client reports the result it is not found, resulting in a validate error. The workaround for this is to set the default connect to time to 0.001.

I hope this explains what you're asking about...

---

Yesterday I upgraded the Boinc client to 5.10.7 from 5.8.16 and have since then seen quite a few of my SETI WUs change their status to "aborted by project". This happened yesterday and now again today... anybody know anything about this? I'm wondering if the new client is causing problems...

If the work units in question are/were still being sent out to three users. Then this could be caused by the auto cancel. On reaching quorum of 2. The first two sucessful the third will be aborted. I think that is how it was explaned to me over on seti@homebeta yesterday. Well worth looking into.

---

Bounty ... let me ask a difficult one ...
suppose quorum is met (suppose 2 results) AND i am NOT running BOINC client 5.10.7 (in that case, if computation has not yet started, i will get an "aborted by project") .... if credit is granted (on the first two host reporting the results) and wu removed from db, am i supposed to get a VALIDATION ERROR upon report of my result (suppose 3rd one) ? If it is like that, i could explain myself some "weird" behavior about a couple of host i am running ...

Hope i made my question "messy" enough :D


M.

The answer to the question is a qualified yes. Keep in mind the main deciding factor to whether you get credit for a result when you are late is has the WU gone through the validator successfully. If the answer is yes, you'll get a validate error, even if the WU has not been purged. If the answer is no, then you would get credit as long as your host reports before any reissued result is reported which forms a quorum.

Also, once your host is issued a result, there is no way the WU would be purged before your host had reported or the latest deadline for any result in the WU had expired (unless there was a backend problem, of course).

HTH,

Alinator

Bounty ... let me ask a difficult one ...
suppose quorum is met (suppose 2 results) AND i am NOT running BOINC client 5.10.7 (in that case, if computation has not yet started, i will get an "aborted by project") .... if credit is granted (on the first two host reporting the results) and wu removed from db, am i supposed to get a VALIDATION ERROR upon report of my result (suppose 3rd one) ? If it is like that, i could explain myself some "weird" behavior about a couple of host i am running ...

Hope i made my question "messy" enough :D


M.

The answer to the question is a qualified yes. Keep in mind the main deciding factor to whether you get credit for a result when you are late is has the WU gone through the validator successfully. If the answer is yes, you'll get a validate error, even if the WU has not been purged. If the answer is no, then you would get credit as long as your host reports before any reissued result is reported which forms a quorum.

Also, once your host is issued a result, there is no way the WU would be purged before your host had reported or the latest deadline for any result in the WU had expired (unless there was a backend problem, of course).

HTH,

Alinator

Alinator, as far as i knew, the credit was granted for ALL results (valid, meaningful) received within the deadline, no matter if i was the first one to report, the second one or , in case of quorum set to 2 , the third one. If it is like that, now things are different, credit will be granted *JUST* to the first two valid results reported; obviously, the third one (same example as before, minimum quorum of 2) will find the result purged from db (assuming that validation report does not take much time) once results are successfully validated...

Is it working like that now or not ? did i got it all well or no ?

Thanks
M.

---

Mauro, look the the wuid in the "P60 thread". The other two finished it 12 days ago(and got credit then), yet I got credit for the third which took 16 days to complete. It has Boinc 5.10.7 installed.

Alinator, as far as i knew, the credit was granted for ALL results (valid, meaningful) received within the deadline, no matter if i was the first one to report, the second one or , in case of quorum set to 2 , the third one. If it is like that, now things are different, credit will be granted *JUST* to the first two valid results reported; obviously, the third one (same example as before, minimum quorum of 2) will find the result purged from db (assuming that validation report does not take much time) once results are successfully validated...

Is it working like that now or not ? did i got it all well or no ?

Thanks
M.

1.) If your host has started a result and gets it back before the deadline expires, you will always get credit for if it passes validation. Enabling auto-abort doesn't change this at all.

2.) The earliest time a WU can be purged from the BOINC DB:

a.) All of the outstanding results have been returned, a quorum formed, and credit granted.

b.) A quorum has formed and any trailers have been successfully auto-aborted and reported.

c.) The quorum has formed and the deadline for all outstanding results has expired.

The point you're missing here is your scenario is not possible under normal conditions. As long as any result in a WU has time left on the deadline, the WU will not be purged from the DB, and thus the result would be eligible to have credit granted if it passes validation. This has not changed since enabling auto-abort.

Proof:

My 'slugs' were almost never in the quorum before auto-abort was enabled but OTOH virtually never miss a deadline. IOW, they are the trailer over 95% of the time.

Since I don't have 5.10.7 on them, they don't have a clue about the 221 and so run whatever they're given to completion. I have yet to have one not get credit for it's trailer.

Alinator

...
I beleive aborted by project should happen only if you are running 5.10.7, if the the quorum has been met....however over on Beta, according to Ingleside here on SETI main that might happen with 5.5.1 and above as well. I suppose Joe or Ingleside can shed light on that.

The initial client side implementation was checked in by David Anderson May 25 2006. It used the tags <result_abort> for unconditional project aborts and <result_abort_if_unstarted> for conditional. That is in core client 5.5.1 through 5.8.16, but it was not implemented server side.

On March 21 2007, David checked in a fix for a bug which crashed the client when it got the conditional form, and changed the tag to <result_abort_if_not_started> so it could safely be sent to older clients. Mac and Linux 5.8.17 clients and Windows 5.9.3 clients were built after that date.

The server side Scheduler code changes to allow a project to use the feature were added April 5 2007, and a bugfix May 4 2007.

The server side changes are strictly in the Scheduler, it simply tells the core client to do the aborts. It doesn't change the status of the WU directly. If the core client does the abort then the report of that result allows early cleanup server side.

                                                                 Joe

Yesterday I upgraded the Boinc client to 5.10.7 from 5.8.16 and have since then seen quite a few of my SETI WUs change their status to "aborted by project". This happened yesterday and now again today... anybody know anything about this? I'm wondering if the new client is causing problems...

No, its not a client error, it is expected behavior.

S@H has recently enabled a server-side feature that will abort a result on your computer under certain circumstances.

The one that is likely affecting you is when you have not yet started a result, but the project already has that workunit validated (2 others have returned their results for that workunit, and the results are strongly similar), that result on your computer is aborted (because it is not needed) when your BOINC client contacts the scheduler. The newer BOINC such as 5.10.7 can handle this. The older ones do not, so there is no change to their behavior (ie. no aborts).

You are not out of any crunch time in this case, since it only triggers if you have not yet started that result. If you have started it, it does not abort. The only down side is that currently, an 'abort by project' will deduct one from your quota on that machine. But, this should not be a problem, because every successful result returned and validated doubles the quota (up to the max value).

Other cases where results in progress *might* be aborted include when the project determines that results are defective (such as being improperly split), or otherwise canceled by the project. I've only seen this happen a couple of times over at the S@H/Astropulse Beta project when all AP workunits were cancelled due to an error in the AP app under testing.

Again, what I believe to be happening to you is normal. The aborted results in your cache should be replaced the next time the BOINC client contacts the S@H scheduler, and you are not out of any crunch time. I could tell you for certain if you did not have your computers hidden.

Hope this helps.

Thank you very much for your reply and explanation, since I just upgraded to 5.10.7 I had not seen that behaviour before, though I suspected a possible connection as I did check those units and saw that 2 successful results had come in for each of those cases. The daily quota did drop quite a bit at that time, but as I was still getting work and had a decent cache, it was/is not a problem bringing said quota badk up... in other words no problems at all, I simply worried something could have been wrong on my end (which seems not to be the case).

Thanks again :)

---

I upgraded all my machines to 5.10.8 but then started getting a preponderance of Client Errors See Below


560510765 137433892 28 Jun 2007 18:03:18 UTC 29 Jun 2007 2:26:50 UTC Over Client error Aborted 0.00 0.00 ---

560510757 137433902 29 Jun 2007 12:17:44 UTC 23 Jul 2007 14:30:36 UTC In Progress Unknown New --- --- ---

560510717 137433888 28 Jun 2007 18:03:18 UTC 29 Jun 2007 12:17:44 UTC Over No reply New 0.00 --- ---

560510705 137433876 28 Jun 2007 18:03:18 UTC 28 Jun 2007 20:28:43 UTC Over Client error Aborted 0.00 0.00 ---


As a result I returned back to 5.8.16 last night (23H00 6/28) and so far the Client Errors have not appeared. Can anyone provide insight into this anomaly?

---

I upgraded all my machines to 5.10.8 but then started getting a preponderance of Client Errors See Below


560510765 137433892 28 Jun 2007 18:03:18 UTC 29 Jun 2007 2:26:50 UTC Over Client error Aborted 0.00 0.00 ---

560510757 137433902 29 Jun 2007 12:17:44 UTC 23 Jul 2007 14:30:36 UTC In Progress Unknown New --- --- ---

560510717 137433888 28 Jun 2007 18:03:18 UTC 29 Jun 2007 12:17:44 UTC Over No reply New 0.00 --- ---

560510705 137433876 28 Jun 2007 18:03:18 UTC 28 Jun 2007 20:28:43 UTC Over Client error Aborted 0.00 0.00 ---


As a result I returned back to 5.8.16 last night (23H00 6/28) and so far the Client Errors have not appeared. Can anyone provide insight into this anomaly?

Try reading this thread.

---