But there's always Cosmology, as long as you are already have an account there

Cosmology has been off-line, including the website, since before the first of the year. Einstein@Home is still working.

---

We have to see this through. Eventually, the validation WUs will be sent; just be patient.

1300 WUs are waiting for validation from my side so far, and I allocated more cores to help get more WUs calculated.

---

Everything stays
But it still changes
Ever so slightly
Daily and nightly
In little ways
When everything stays...

At least the science here is being used and has value. The old Cosmology project is unattended and any tasks being done are at best for credit only. Any electricity used on it would be better used on Einstein@home or Asteroids or this project. Universe would be a good choice when they return to active work.

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.

A few validated WUs have shown up on my tasks list!

---

Everything stays
But it still changes
Ever so slightly
Daily and nightly
In little ways
When everything stays...

One valid here and I got now one _1 on my computer. The ready to send buffer also dropped by about 3k. That means we made it through that huge pile of _0s and now we need to make it through the same huge pile of _1s. :D

---

One valid here and I got now one _1 on my computer. The ready to send buffer also dropped by about 3k. That means we made it through that huge pile of _0s and now we need to make it through the same huge pile of _1s. :D

I have some _2 and _3 tasks on my pc, so we ARE getting closer to normal day to day stuff again.

Now 3 valids for me and the results ready to send are down to 682024. Yay.

---

Which problem with database? The inconclusive tasks are not a problem with database and it's not a problem at all,

It is a problem with volunteer relations. The process sending out tasks could trivially issue a quorum in rapid succession even if the number of workunits in the queue is large.

What useful purpose is served by operating in a manner that causes unnecessary concern for people who are donating their resources?

It is a problem with volunteer relations. The process sending out tasks could trivially issue a quorum in rapid succession even if the number of workunits in the queue is large.

What useful purpose is served by operating in a manner that causes unnecessary concern for people who are donating their resources?

I agree that the lack of proper communication requires us to extrapolate information. From our side, a sudden stop of credits being awarded is a big cause for concern.

However, I feel the sole developer here is overburdened and the lack of engagement is the consequence.

---

Everything stays
But it still changes
Ever so slightly
Daily and nightly
In little ways
When everything stays...

Jerry wrote:

The process sending out tasks could trivially issue a quorum in rapid succession even if the number of workunits in the queue is large.

I agree. It seems desirable that those who have insight into the NBody validator review whether or not the current minimum quorum of 1 really makes sense: *If* it is very unlikely that a single result can be validated (or worse: actually impossible),¹ then NBody workunits should be configured to minium quorum = 2 (and initial replication = 2). That's not only for the users' sake, it should (if the mentioned condition is true) also reduce the database size somewhat as it should reduce the number of workunits waiting for validation.

________
¹) I for one have never spotted a workunit which was validated from a single task. Hence it seems to me that it is indeed highly unlikely or impossible.

Jerry wrote:

The process sending out tasks could trivially issue a quorum in rapid succession even if the number of workunits in the queue is large.

I agree. It seems desirable that those who have insight into the NBody validator review whether or not the current minimum quorum of 1 really makes sense: *If* it is very unlikely that a single result can be validated (or worse: actually impossible),¹ then NBody workunits should be configured to minium quorum = 2 (and initial replication = 2). That's not only for the users' sake, it should (if the mentioned condition is true) also reduce the database size somewhat as it should reduce the number of workunits waiting for validation.

________
¹) I for one have never spotted a workunit which was validated from a single task. Hence it seems to me that it is indeed highly unlikely or impossible.

Separation tasks were almost always validated by a single task on "trusted" hosts.

---

It is a problem with volunteer relations. The process sending out tasks could trivially issue a quorum in rapid succession even if the number of workunits in the queue is large.

What useful purpose is served by operating in a manner that causes unnecessary concern for people who are donating their resources?

I agree that the lack of proper communication requires us to extrapolate information. From our side, a sudden stop of credits being awarded is a big cause for concern.

However, I feel the sole developer here is overburdened and the lack of engagement is the consequence.

It depends on the volunteers prospective. If a volunteer is donating their hardware and electricity for science then the "sudden stop of credits" is interesting and requires watching BUT is not a not a big cause for concern. If the volunteer is donating hardware and electricity for Credit's and recognition and / or badges then it might be a "big cause for concern" for that volunteer.

Science wins....

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.

It depends on the volunteers prospective. If a volunteer is donating their hardware and electricity for science then the "sudden stop of credits" is interesting and requires watching BUT is not a not a big cause for concern. If the volunteer is donating hardware and electricity for Credit's and recognition and / or badges then it might be a "big cause for concern" for that volunteer.

Science wins....

Bill F

I'm not folding for the "rewards." The sudden loss of credits concerns whether we are doing science at all since that's the only immediate empirical metric users see. None of the admin update posts mentioned that no one was getting credited, so it gave way to all the questions about "why aren't we getting credits? Is my machine broken? Etc..." If a proactive announcement had been made that explained what had happened in a manner the public understands, this wouldn't have been a big concern.

---

Everything stays
But it still changes
Ever so slightly
Daily and nightly
In little ways
When everything stays...

Keith Myers wrote:

xii5ku wrote:

It seems desirable that those who have insight into the NBody validator review whether or not the current minimum quorum of 1 really makes sense: [...]
I for one have never spotted a workunit which was validated from a single task. Hence it seems to me that it is indeed highly unlikely or impossible.

Separation tasks were almost always validated by a single task on "trusted" hosts.

Right; corresponding to that I specifically referred to the NBody validator, I should have written "I for one have never spotted an NBody workunit which was validated from a single task" for clarity.

[Even back in the time when both Separation and NBody were still active in parallel, it would have been technically possible to configure different quorum and replication settings for the two on the server. And perhaps not only possible but also potentially beneficial to the database size.]

--------

Bill F wrote:

Finn the Human wrote:

[...] From our side, a sudden stop of credits being awarded is a big cause for concern. [...]

It depends on the volunteers prospective. If a volunteer is donating their hardware and electricity for science then the "sudden stop of credits" is interesting and requires watching BUT is not a not a big cause for concern. If the volunteer is donating hardware and electricity for Credit's and recognition and / or badges then it might be a "big cause for concern" for that volunteer.

Regardless if the motivation is biased to scientific contribution or to nice scores, either way we are aiming that our hosts return results which are valid. Therefore the confusion among us when suddenly nothing was validated any more. However, the explanation of why this happened as well as estimations when validations were to resume could be found in the message board. (Although, as Finn the Human put it, this info was mostly extrapolated by users.)

I got the first of the de_nbody orbit_fitting tasks today. It seems like they will not follow the app_conf.xml. I have configured one of my "48 CPU" computers to run 4 tasks at a time using 12 CPUs each. All of the "old" nbody tasks obey this config file. But the 10 orbit_fitting tasks I got today are all listed as "Ready to start (16 CPUs) (none have run yet). Background, I have two identical computers. One has no app_config.xml file ( runs three tasks at a time using 16 CPUs ). The other has an app_config.xml file to run 4 tasks at a time using 12 CPUs. This has always worked. Even the plain ole nbody tasks I got AFTER the orbit_fitting tasks show "Ready to start (12 CPUs). Is this by design?[/img]

I got the first of the de_nbody orbit_fitting tasks today. It seems like they will not follow the app_conf.xml. I have configured one of my "48 CPU" computers to run 4 tasks at a time using 12 CPUs each. All of the "old" nbody tasks obey this config file. But the 10 orbit_fitting tasks I got today are all listed as "Ready to start (16 CPUs) (none have run yet). Background, I have two identical computers. One has no app_config.xml file ( runs three tasks at a time using 16 CPUs ). The other has an app_config.xml file to run 4 tasks at a time using 12 CPUs. This has always worked. Even the plain ole nbody tasks I got AFTER the orbit_fitting tasks show "Ready to start (12 CPUs). Is this by design?[/img]

You need to modify the app_confg file. This is mine which seems to work, you just need change the numbers to fit your need.

<app_config>

 <app>
  <name>milkyway_nbody_orbit_fitting</name>
  <max_concurrent>2</max_concurrent>
 </app>
 <app_version>
  <app_name>milkyway_nbody_orbit_fitting</app_name>
  <plan_class>mt</plan_class>
  <avg_ncpus>3</avg_ncpus>
  <cmdline>--nthreads 3</cmdline>
 </app_version>

 <app>
  <name>milkyway_nbody</name>
  <max_concurrent>2</max_concurrent>
 </app>
 <app_version>
  <app_name>milkyway_nbody</app_name>
  <plan_class>mt</plan_class>
  <avg_ncpus>3</avg_ncpus>
  <cmdline>--nthreads 3</cmdline>
 </app_version>

<project_max_concurrent>2</project_max_concurrent>
</app_config>

Been so long I forgot it was application specific. Thanks.

I got the first of the de_nbody orbit_fitting tasks today. It seems like they will not follow the app_conf.xml. I have configured one of my "48 CPU" computers to run 4 tasks at a time using 12 CPUs each. All of the "old" nbody tasks obey this config file. But the 10 orbit_fitting tasks I got today are all listed as "Ready to start (16 CPUs) (none have run yet). Background, I have two identical computers. One has no app_config.xml file ( runs three tasks at a time using 16 CPUs ). The other has an app_config.xml file to run 4 tasks at a time using 12 CPUs. This has always worked. Even the plain ole nbody tasks I got AFTER the orbit_fitting tasks show "Ready to start (12 CPUs). Is this by design?[/img]

Mine looks like this now and works for me:

<app_config>


<app_version>
<app_name>milkyway_nbody</app_name>
<plan_class>mt</plan_class>
<avg_ncpus>2</avg_ncpus>
<cmdline>--nthreads 2</cmdline>
</app_version>

<app_version>
<app_name>milkyway_nbody_orbit_fitting</app_name>
<plan_class>mt</plan_class>
<avg_ncpus>2</avg_ncpus>
<cmdline>--nthreads 2</cmdline>
</app_version>

<project_max_concurrent>1</project_max_concurrent>

</app_config>

You can see from mine that you have to add a new section with the new app name in it.

I run mine with 2 cpu cores each and they just take longer to run but they run just fie so far, I'm waiting for my wingmen to know for sure of course. I am also only running 1 task at a time on my laptop, my desktops will have different settings based on the capability of each one.

Thanks for the app_config reminder, guys. Much appreciated:)

---

Likely the name changed for the tasks and that is why your app_config does not work anymore. If they are releasing BOTH the old N-body and whatever the new Orbit tasks are named, just use two app_version sections.

---