The MW@H tasks are highly variable. Some last 1 second, I had another take 5300 seconds (x16) as they use up to 16 threads.
Yes. The "Milkyway@home N-Body Simulation v1.83" tasks had two types of tasks, one shorter and one longer, and rather little variability of CPU times within each of these two types. In contrast, the few tasks of the new "Milkyway@home N-Body Simulation with Orbit Fitting v1.86" which I completed so far (28) have CPU times all over the place. Ones with less than a second CPU time are quite frequent too. Looks like one of those physics projects in which workunits with physically nonsensical starting values are generated often and need to be weeded out by the clients.
The longest one which I had so far had 10 hours CPU time, and server_status.php agrees with that. (server_status.php says "runtime", not CPU time, but I am under the impression that the figure there is actually the latter.)
Edit: Oh, I just realized that I have yet to extend my app_config.xml to the new application. I run the v1.83 with 4 threads for now. The new one executes with its default 16 threads on my computers, and the very low CPU time : run time ratios of the completed tasks shows that this is similarly inefficient as it was with the previous application.
The longest one which I had so far had 10 hours CPU time, and server_status.php agrees with that. (server_status.php says "runtime", not CPU time, but I am under the impression that the figure there is actually the latter.)
It may make sense to restrict the number of program threads to a lot less than those 16t. On modern CPUs, even running them single-threaded looks feasible. I haven't taken the time yet to measure what a good thread count would be, for host efficiency.
Edit: Oh, I just realized that I have yet to extend my app_config.xml to the new application. I run the v1.83 with 4 threads for now. The new one executes with its default 16 threads on my computers, and the very low CPU time : run time ratios of the completed tasks shows that this is similarly inefficient as it was with the previous application.
Last edited:
Yafu is also another one of those projects with "multi threaded" apps, but it doesn't make any sense with them.
I have a 64 core/128 thread EPYC running 1 task at a time on it. Checking top, I see that it's using as much as 100 threads at once at times, sometimes it dips to around 70, but it's always a good bit above 64 which is what it should be.
My points are all over the place despite this.
I even started a second instance on the host to run some ODLK on 32 threads on the same host. It's just wild how the run times are so vastly different on yafu and the PPD varies so much as well.
I have a 64 core/128 thread EPYC running 1 task at a time on it. Checking top, I see that it's using as much as 100 threads at once at times, sometimes it dips to around 70, but it's always a good bit above 64 which is what it should be.
My points are all over the place despite this.
I even started a second instance on the host to run some ODLK on 32 threads on the same host. It's just wild how the run times are so vastly different on yafu and the PPD varies so much as well.
SNAFU@Home uses CreditNew, but the CreditNew algorithm can never converge to a proper host performance estimation due to the dramatic and unpredictable differences between workloads of the workunits. During the run time of the application, there are different code portions with different degree of parallelization: From single-threaded to perfectly scaling n-threaded. But how much of these portions occur during the run time, and even if some of these portions are occurring at all, differs between workunits and can't be predicted. (The application is actually pieced together from a few different programs; some serial and some parallel.)
A while ago when I ran YAFU in Formula Boinc, I got good host utilization and good RAC by means of 1.) restricting the maximum number of tasks per threads, 2.) overcommitting the host's hardware threads. teamanandtech.org may have some info.
A while ago when I ran YAFU in Formula Boinc, I got good host utilization and good RAC by means of 1.) restricting the maximum number of tasks per threads, 2.) overcommitting the host's hardware threads. teamanandtech.org may have some info.
Last edited:
MilkyWay@Home
Example syntax:
XML:
<app_config>
<app_version>
<app_name>milkyway_nbody</app_name>
<plan_class>mt</plan_class>
<avg_ncpus>4</avg_ncpus>
<cmdline>--nthreads 4</cmdline>
</app_version>
<app_version>
<app_name>milkyway_nbody_orbit_fitting</app_name>
<plan_class>mt</plan_class>
<avg_ncpus>4</avg_ncpus>
<cmdline>--nthreads 4</cmdline>
</app_version>
</app_config>Doesn't seem like it. I think I might do what Stef suggests, just over commit the host with more tasks than the host has threads and see what happens.
- Dec 11, 1999
- 16,250
- 3,845
- 75
Primegrid has a new sieve application. SR5 Sieve is considered in beta right now, but it can get you a new badge and a new application in WUProp.
MilkyWay@Home
– added a single-threaded app_version of "NBody Simulation" and "N-Body Simulation with Orbit Fitting"
– added these options to project preferences:
I am not sure if the latter really means CPUs per project, or actually threads per task.
The single-threaded app_version is supposedly slightly better performing if you run just 1 thread per task. According to the admin, the single-threaded app_version is sent to clients which set Max # of CPUs = 1.
Unfortunately, by default folks will now have a wild mixture of multithreaded and single-threaded tasks in their workqueues. It is an open question how to prevent the downloading of single-threaded tasks if a user prefers to run multi-threaded tasks only (apart from writing an app_info.xml).
(IOW, it's another fine mess.)
– added a single-threaded app_version of "NBody Simulation" and "N-Body Simulation with Orbit Fitting"
– added these options to project preferences:
Max # of jobs for this project [default: No limit; options: 1…100]
Max # of CPUs for this project [default: No limit; options: 1…256]
Max # of CPUs for this project [default: No limit; options: 1…256]
I am not sure if the latter really means CPUs per project, or actually threads per task.
The single-threaded app_version is supposedly slightly better performing if you run just 1 thread per task. According to the admin, the single-threaded app_version is sent to clients which set Max # of CPUs = 1.
Unfortunately, by default folks will now have a wild mixture of multithreaded and single-threaded tasks in their workqueues. It is an open question how to prevent the downloading of single-threaded tasks if a user prefers to run multi-threaded tasks only (apart from writing an app_info.xml).
(IOW, it's another fine mess.)
Pretty sure this was done to allow the use of TSC 1-core droplets to get Milkyway work.
On a quick look, it seems as if switching "Max # of CPUs for this project" from "No limit" to something greater than 1 causes the server to send only multithreaded tasks to the host.
Fardringle
Diamond Member
- Oct 23, 2000
- 9,188
- 753
- 126
Is there a way to ONLY get the single threaded tasks? Since the project preferences on the site don't seem to have that option?
Try setting "Max # of CPUs for this project" = 1. This should give you single-threaded tasks only. (But should still give you as many tasks at once as you possibly could want. Unless you dial down "Max # of jobs for this project".)
If the "Max # of CPUsfor this project" setting at 1 does not work the way you want, add the app_config.xml from #232 and change <avg_ncpus> and <cmdline> of both appversions to 1 thread. But this really shouldn't be needed anymore.
And for completeness: As @Skillz pointed out, hosts which only have 1 active logical CPU should now receive (singlethreaded) tasks. Before the new singlethreaded appversion was added by the admin, such hosts did not receive any work at all.
________
OCD edit, the "for this project" words have been removed from the preferences page in the meantime. Or they never were there and I merely imagined them. — Edit 2: It's "Max # of CPUs" on the preferences page and "Max # of CPUs for this project" on the edit preferences page. :-)
If the "Max # of CPUs
And for completeness: As @Skillz pointed out, hosts which only have 1 active logical CPU should now receive (singlethreaded) tasks. Before the new singlethreaded appversion was added by the admin, such hosts did not receive any work at all.
________
OCD edit, the "for this project" words have been removed from the preferences page in the meantime. Or they never were there and I merely imagined them. — Edit 2: It's "Max # of CPUs" on the preferences page and "Max # of CPUs for this project" on the edit preferences page. :-)
Last edited:
Fardringle
Diamond Member
- Oct 23, 2000
- 9,188
- 753
- 126
I thought I had tried that previously and it didn't work, but I'll try it again when I'm in the mood to run MilkyWay again.
TRENDING THREADS
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 10K
-
Discussion Speculation: Zen 4 (EPYC 4 "Genoa", Ryzen 7000, etc.)- Started by Vattila
- Replies: 13K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 7K
-
Facebook
Twitter