Message boards :
News :
Admin Updates Discussion
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 · Next
Author | Message |
---|---|
Send message Joined: 23 Feb 13 Posts: 1 Credit: 5,097,382 RAC: 61 ![]() ![]() |
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. |
![]() ![]() Send message Joined: 23 Dec 18 Posts: 23 Credit: 10,213,119 RAC: 0 ![]() ![]() |
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... ![]() |
![]() ![]() Send message Joined: 4 Jul 09 Posts: 90 Credit: 17,213,757 RAC: 1,775 ![]() ![]() ![]() |
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. ![]() |
![]() ![]() Send message Joined: 23 Dec 18 Posts: 23 Credit: 10,213,119 RAC: 0 ![]() ![]() |
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... ![]() |
![]() Send message Joined: 19 Jul 10 Posts: 618 Credit: 19,254,980 RAC: 26 ![]() ![]() |
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 ![]() |
![]() ![]() Send message Joined: 8 May 09 Posts: 3339 Credit: 524,010,781 RAC: 14 ![]() ![]() ![]() |
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. |
![]() Send message Joined: 19 Jul 10 Posts: 618 Credit: 19,254,980 RAC: 26 ![]() ![]() |
Now 3 valids for me and the results ready to send are down to 682024. Yay. ![]() |
Send message Joined: 16 Oct 17 Posts: 1 Credit: 44,795,616 RAC: 3,156 ![]() ![]() ![]() |
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? |
![]() ![]() Send message Joined: 23 Dec 18 Posts: 23 Credit: 10,213,119 RAC: 0 ![]() ![]() |
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. 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... ![]() |
Send message Joined: 1 Jan 17 Posts: 37 Credit: 109,930,961 RAC: 2,698 ![]() ![]() ![]() |
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. |
![]() ![]() Send message Joined: 24 Jan 11 Posts: 712 Credit: 551,845,226 RAC: 43,704 ![]() ![]() ![]() ![]() |
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. Separation tasks were almost always validated by a single task on "trusted" hosts. ![]() |
![]() ![]() Send message Joined: 4 Jul 09 Posts: 90 Credit: 17,213,757 RAC: 1,775 ![]() ![]() ![]() |
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. 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. ![]() |
![]() ![]() Send message Joined: 23 Dec 18 Posts: 23 Credit: 10,213,119 RAC: 0 ![]() ![]() |
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... ![]() |
Send message Joined: 1 Jan 17 Posts: 37 Credit: 109,930,961 RAC: 2,698 ![]() ![]() ![]() |
Keith Myers wrote: xii5ku wrote: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.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: [...]Separation tasks were almost always validated by a single task on "trusted" hosts. [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: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.)[...] 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. |
Send message Joined: 5 Sep 09 Posts: 9 Credit: 556,743,263 RAC: 49,334 ![]() ![]() ![]() ![]() |
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] |
![]() Send message Joined: 18 Feb 10 Posts: 57 Credit: 222,199,800 RAC: 2,358 ![]() ![]() ![]() |
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> |
Send message Joined: 5 Sep 09 Posts: 9 Credit: 556,743,263 RAC: 49,334 ![]() ![]() ![]() ![]() |
Been so long I forgot it was application specific. Thanks. |
![]() ![]() Send message Joined: 8 May 09 Posts: 3339 Credit: 524,010,781 RAC: 14 ![]() ![]() ![]() |
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. |
![]() Send message Joined: 7 Mar 20 Posts: 22 Credit: 105,446,854 RAC: 1 ![]() ![]() |
Thanks for the app_config reminder, guys. Much appreciated:) ![]() ![]() |
![]() ![]() Send message Joined: 24 Jan 11 Posts: 712 Credit: 551,845,226 RAC: 43,704 ![]() ![]() ![]() ![]() |
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. ![]() |
©2024 Astroinformatics Group