Thank you! I sure will!

Best regards,
GWGeorge007

---

George

Somewhat annoying...

https://milkyway.cs.rpi.edu/milkyway/result.php?resultid=1015374201

Well, this WU was created before the change (well, at least before Kevin's message), not sure if the change applies to new results or just new WUs.

Got another created after Kevin's message
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1003011105

Your message indicates that your link to https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1003011105 was created BEFORE Kevin's post:

Your link: Created 28 May 2025, 19:09:11 UTC

Kevin's post sent: Posted: 28 May 2025, 18:56:56 UTC - in response to Message 77453.

---

George

Well yes, he made a new post, will see if that solves the problem :)

Seems like I might have changed the wrong thing?
I changed what I think should be the right setting now to 100MB.
Again, let me know if the issue persists.

I'm still getting errors and invalids... as well as some Valid's also.
You seem to be on the right track but I think you need to make more changes.

---

George

I'm still getting errors and invalids... as well as some Valid's also.
You seem to be on the right track but I think you need to make more changes.

As far as I can see, all the WUs, that errored out for you, were created before Kevin's latest message. it will take some time, before those are out from the system, I'm not sure if Kevin was able to increase the limit for new results or only new WUs.

---

Slightly off current topic... but still a MilkyWay project problem we also still have the issue of GFLOPS being computing incorrectly.
Once this is resolved Task allocation for volunteer systems running multiple Projects should improve.

Thanks
Bill F

---

In October of 1969 I took an oath to support and defend the Constitution of the United States against all enemies, foreign and domestic;
There was no expiration date.

I don't know, if this had something to do with the recent changes, but I'm not sure this should have happened:

02/06/2025 15:10:05 | Milkyway@home | Result de_nbody_orbit_fitting_03_25_2025_v186_OCS__data__32_1740880091_2549890_3 is no longer usable
02/06/2025 15:10:05 | Milkyway@home | Result de_nbody_orbit_fitting_03_25_2025_v186_OCS__data__33_1740880091_2606249_5 is no longer usable

Both results had few days left until the deadline, so it can't be that.

---

There are two sorts of abort request that can be sent from the scheduler to the client. The one we are used to seeing is an "abort if not started"; it doesn't have a scheduler message text associated with it.

However, if a WU is marked as not needed for some reason (such as cancellation of bad units) it will send a "abort" request with the "Result xxxxxxx is no longer usable" message as accompaniment. Note that this sort of abort is mandatory (which might be why BOINC admins sometimes don't seem to like using it?)

The client handles the two abort types as separate cases; if it's a mandatory abort request the message from the scheduler will appear, and if the task happens to be active there should also be a client-generated "aborted by project - no longer usable" message in the BOINC log.

So if bad [batches of] WUs are killed off properly, there will be sightings of that message (and probably some users complaining about wasted CPU time!)

Cheers - Al.

References: current sources -- sched/handle_request.cpp and client/cs_scheduler.cpp

And the next two:

03/06/2025 09:54:29 | Milkyway@home | Result de_nbody_orbit_fitting_03_25_2025_v186_OCS__data__33_1740880091_2546703_6 is no longer usable
03/06/2025 09:54:29 | Milkyway@home | Result de_nbody_orbit_fitting_03_25_2025_v186_OCS__data__33_1740880091_2313614_5 is no longer usable

---

if a WU is marked as not needed for some reason (such as cancellation of bad units) it will send a "abort" request with the "Result xxxxxxx is no longer usable" message as accompaniment. Note that this sort of abort is mandatory (which might be why BOINC admins sometimes don't seem to like using it?)

I think this has something more to do with message 77440:
"I made a mistake when I was trying to perform some tests and cancelled a lot of workunits which included tasks that were in progress."

Those were WUs, that were canceled once, than send out to new hosts, but for some reason they were now purged from database just like they were completed at the time of cancellation (or at the time they were send to me, when it was the last time something happend with them). There were even other "completed, validation inconclusive" results waiting for me to return my result. Just like the server didn't notice, that the WUs were uncancelled and simply purged them x hours after the last update. If some of the three temporarily cancelled WUs, that I still have running, will become suddenly not needed, than this would confirm this theory, as I don't think someone is sitting there at Milkyway@home and cancels some WUs every now and than, if they need to do that, they'd do it at once for all not needed WUs.

---

I'm still getting errors and invalids... as well as some Valid's also.
You seem to be on the right track but I think you need to make more changes.

As far as I can see, all the WUs, that errored out for you, were created before Kevin's latest message. it will take some time, before those are out from the system, I'm not sure if Kevin was able to increase the limit for new results or only new WUs.

As far as I can tell myself, these are all resends - those ending in numbers greater than 1 - with #'s of 2 thru 5.
Am I mistaken, or were you supposed to have deleted these error prone tasks?
Either way, I have only a few left in my cache - less than 100. Do you still have more 'resends' to send out?

---

George

Am I mistaken, or were you supposed to have deleted these error prone tasks?

No, sometimes they succeed, like this one for example.

Either way, I have only a few left in my cache - less than 100. Do you still have more 'resends' to send out?

All v1.87 are resends now.

---

Am I mistaken, or were you supposed to have deleted these error prone tasks?

No, sometimes they succeed, like this one for example.

And this one errored out with EXIT_DISK_LIMIT_EXCEEDED on one computer, three other computers could however successfully complete it (one was invalid, but that's a different story). So no, definitely do not abort those.

---