Hi Tom,
Things seem to have settled, much better - thank you.
Invalids rising slowly, now at 1077

Pity the validator can not be reprogramed to accept the size 7 workunits as a valid size
or is that just my dim way of solving the problem .

Hi Tom
Invalids are rising slowly now at 1239

I have been having issues with the nbody tasks failing. They should process in a couple of minutes (using 16 processors out of 24 on a pair of xeon 56xx's) But instead they get part way and then lock up for the rest of the day, which means that no other tasks will run on those 16 processors. It isn't an issue of them just trying to finish either, on what should be a couple of minute task it would be stuck for 12 hours at 0% cpu.

If anyone has any suggestions on this.

I will reach out to Eric and let him know to check this thread.

Hallo,

MilkyWay@home sounds very interesting "create a highly accurate three dimensional model of the Milkyway galaxy using data gathered by the Sloan Digital Sky Survey".

sounds like you are building a "google maps" software of the milky ways? (hope it is Open Source)

will it look like this? https://youtu.be/r97GWqMD7_c

https://skfb.ly/6QV7A

holy it is a probably not accurate 3D model that a 3D hobbyist did, but it looks just great & it run's in the user's browser and supports VR

neat :)

checkout this software http://universesandbox.com/scottmanley discover the universe like a video game :)

(it is more about inspiring people, if VR is brings any practical advancements is still in question https://sg.news.yahoo.com/vr-milky-way-model-open-100210956.html

have a good time despite everything

Hi fellow number crunchers. I have backed off a bit and not doing any work at this time because of no feedback as to all this effort being useful, for all I know I could be Crypto Mining. Can somebody point me to where all our effort is to be found or should I just go back to my telescope?

Hi fellow number crunchers. I have backed off a bit and not doing any work at this time because of no feedback as to all this effort being useful, for all I know I could be Crypto Mining. Can somebody point me to where all our effort is to be found or should I just go back to my telescope?

It's your pc's and your choice where you crunch but a simple look would have found this:

https://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3145

yes it's from 2019 but this is about REAL Science not fake Science where results are gathered today and dropped onto some fake website the next

https://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3145&postid=70502#70502
https://wcl.cs.rpi.edu/papers/Nbody_ApJ_19.pdf
https://iopscience.iop.org/article/10.3847/1538-4365/aadb92/pdf
https://iopscience.iop.org/article/10.3847/1538-4357/ab4f72/pdf
https://arxiv.org/pdf/2006.08764
https://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=2619&postid=69897#69897

Thanks guys, it's what I was asking for.

actually u are: "MilkyWay@home is a whitelisted gridcoin project.[8] It is the second-largest manufacturer of gridcoins"

https://en.wikipedia.org/wiki/MilkyWay@home

ok let's rectify: why 'am i burning fossil fuel to power a server that does MilkyWay@home instead of monero?

because a lemon tree is in need of heating X-D

(and the server at least does something usefull (i hope) than just give off heat)

(because would need a very very fast and 32x core or 64x core CPU ~$2000 to make sense https://dwaves.de/2022/01/14/server-heating-a-lemon-tree-crypto-experiment-rechnet-es-sich-in-2022-01-monero-zu-minen-does-mining-monero-pay-off-maybe-better-of-boinc/)

sensors; #says
Adapter: ISA adapter
Package id 0:  +56.0°C  (high = +85.0°C, crit = +105.0°C)
Core 0:        +47.0°C  (high = +85.0°C, crit = +105.0°C)
Core 1:        +56.0°C  (high = +85.0°C, crit = +105.0°C)
Core 2:        +53.0°C  (high = +85.0°C, crit = +105.0°C)
Core 3:        +55.0°C  (high = +85.0°C, crit = +105.0°C)

hint: it might run much more efficient on GPUs

https://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=4379#68005

than CPUs!

PS: what GPU would be recommended? (watt / GFLOPs?, should be way x < $1000)

I found some stale processes in the DB that were slowing things down. I cleared them out and the website is running faster now. It also looks like there are some more separation WUs in the well of jobs that are ready to be sent out.

Not sure about the validator back up, but I'm trying to figure out if something can be done. Same goes for the transitioner backup.

Work on GPU N-body is slow but still happening. Some major progress was made over the summer, but I wouldn't expect it anytime soon.

Maybe you could reach out to "Petri" thru Keith Myers in this thread and get his assistance, since he's done several already he may be able to get your thru the sticking points.

Work on GPU N-body is slow but still happening. Some major progress was made over the summer, but I wouldn't expect it anytime soon.

Maybe you could reach out to "Petri" thru Keith Myers in this thread and get his assistance, since he's done several already he may be able to get your thru the sticking points.

Hope it includes Intel GPU as well.

Since the Separation app is OpenCL based, it would be compatible with all card types.

Generally Petri develops on Nvidia cards as a preference with CUDA being the preferred platform owing to its inherent performance advantages over compiled OpenCL.

---

Since the Separation app is OpenCL based, it would be compatible with all card types.

Generally Petri develops on Nvidia cards as a preference with CUDA being the preferred platform owing to its inherent performance advantages over compiled OpenCL.

With the possibility of new gpu tasks here at MilkyWay maybe that would be the way to go if he decides to help.

I am sure you all remember the w/u =7 tasks that caused invalidations. Well, this morning I encountered the son of w/u=7. Its signature is w/u=5 and it causes validation errors. Que paso?

I am sure you all remember the w/u =7 tasks that caused invalidations. Well, this morning I encountered the son of w/u=7. Its signature is w/u=5 and it causes validation errors. Que paso?

No, I don't remember ...

I am sure you all remember the w/u =7 tasks that caused invalidations. Well, this morning I encountered the son of w/u=7. Its signature is w/u=5 and it causes validation errors. Que paso?

Yes, I vaguely remember some vinegar associated with that. Can you please refresh us on how to find these and exterminate them? Actually, do we need to exterminate them? Or will the 'system' do that for us?

I am sure you all remember the w/u =7 tasks that caused invalidations. Well, this morning I encountered the son of w/u=7. Its signature is w/u=5 and it causes validation errors. Que paso?

Yes, I vaguely remember some vinegar associated with that. Can you please refresh us on how to find these and exterminate them? Actually, do we need to exterminate them? Or will the 'system' do that for us?

I'm only a user, not a BOINC SysAdmin, but I'll have a go at this...

To address the "extermination" question first - I believe there is some code in the existing validator that spots results that don't have the expected number of parameters and invalidates them (it is potential bad science, after all!) I would hope that it also flags the entire BOINC workunit as bad so no further retries should be sent, but without looking at the code I can't be sure!

Regarding Frank's post: there's more than one reason a result can be declared invalid, so without being able to see the output from the Invalid task(s) it isn't possible to say whether there is a recurrence of that "too many WUs in a shipped task" problem. Current tasks have number_WUs = 5 and number_params_per_WU = 20, so that 5 isn't an issue!

In order to satisfy my curiosity on this, I went via Frank's profile to find his computers to see if I could spot the offending task(s). I found a relevant(*) Invalid task on two of the systems. In each case it was declared a Validation error because it had failed to calculate the likelihoods for the first of the five jobs in the task. Judging by the content of the result report, it appeared to try to start doing the first job twice and got confused about the state of the checkpoint file -- perhaps something interrupted BOINC whilst a checkpoint was being taken? The validator would spit this out at once because it couldn't find all the likelihood data!

I think it would be interesting to know whether the retry/retries also fail to validate - if they fail, then there's possibly a problem in the parameters, but if they don't fail the issue was specific to the computer(s) in question, not a work unit error.

Hope this helps clear things up a bit...

Cheers - Al.

* There were also some "completed, couldn't validate" tasks, and some orphaned invalid tasks from the big renumbering crash of late January 2021.