Addendum: I tried one ARP1 task. Downloading the input files took two hours with countless retries, but I did not rely on BOINC's built-in retry periods... Executing the task took 21 h on my Haswell Xeon E3 (with all other CPU threads busy with concurrent work, mostly MilkyWay nbody). The seven result files were 94 MB big in total, but they uploaded within a quarter hour without a single interruption. (I had BOINC configured to only 1 transfer/project and 100 kB/s cap on upload speed, which this ARP1 upload fully used.) Either I was lucky and met an unusually quiet point in time at WCG for the upload, or WCG's HTTP troubles only affect downloads, not uploads. Or maybe all work of the current ARP1 batch had already been distributed to hosts and WCG's HTTP errors are over... until the next ARP1 batch.
Orange Kid
Elite Member
- Oct 9, 1999
- 4,453
- 2,223
- 146
Universe@Home is ending...
My dear friends,
For over 10 years, I have taken care of the Universe@Home project.
Unfortunately, since the passing of Prof. Krzysztof Belczynski, we have not been able to find a way to continue the project. Therefore, as funding ended at the end of August this year, I am no longer formally associated with the project. Still hoping that a scientific team will be found to carry it forward, I have continued to handle the ongoing maintenance of the server, and I intend to keep doing so in my free time until either a successor to Krzysztof is found or CAMK decides to shut down the servers.
I truly regret that such a long history of our shared work is coming to an end. Unfortunately, I lack the scientific expertise needed to continue the research myself.
I would like to thank all of you for years of support and express my hope that we may someday meet again on another project that I could manage from the BOINC side.
11 Nov 2024, 15:52:47 UTC · Discuss
Last edited:
Fardringle
Diamond Member
- Oct 23, 2000
- 9,200
- 765
- 126
Notice posted on the Symmetric Prime Tuples (SPT) 'news' feed. The new project does not have any work yet, and as of this posting, fewer than 10 people have registered. Account creation is active, but team creation has not been enabled yet. Since it looks like this is a placeholder for a new project, it might be a while before there is any activity...
---------------------------------------------------------------------------------------------------------------------------------------------------------
New BOINC project
Corporal created and configured a server for a new project
http://boinc.mak.termit.me/test/
Gentlemen!
Who can try to launch the BOINC project?
The software is ready.
You will get access to the server.
Please write to me
natalimak1@yandex.ru
26 Nov 2024, 11:42:16 UTC · Discuss
---------------------------------------------------------------------------------------------------------------------------------------------------------
New BOINC project
Corporal created and configured a server for a new project
http://boinc.mak.termit.me/test/
Gentlemen!
Who can try to launch the BOINC project?
The software is ready.
You will get access to the server.
Please write to me
natalimak1@yandex.ru
26 Nov 2024, 11:42:16 UTC · Discuss
Oh its the work she wanted everyone else to do outside of BOINC
I think its that the person who was helping her is... slow?
As seen in her first post:
In one place she says a new project. (above quote)
At ODLK1, she says a subject of SPT
"The PROJECT MAK is a subproject of the BOINC project Symmetric Prime Tuples (SPT)"
Shes been involved in way too many projects. ODLK, ODLK1, SPT (which she wants shut down), Gerisum, T Brada when some of these should have just been apps of other projects.
At ODLK1, she says a subject of SPT
"The PROJECT MAK is a subproject of the BOINC project Symmetric Prime Tuples (SPT)"
Shes been involved in way too many projects. ODLK, ODLK1, SPT (which she wants shut down), Gerisum, T Brada when some of these should have just been apps of other projects.
More specifically worded, she has fallen out with way too many project admins.
This would work if she could fire+hire admins (at the drop of a hat) *but* keep the server while doing so.
Radioactive@Home
Not really a change because this project had phases like this before, but…
…on December 3, the server stopped sending new work. Somebody posted about it at the message board, to no avail.
About ten hours ago the server started to send work again. But the validator is not working. (The map does work.) Furthermore, the message board alternates between responding quickly andnot responding responding extremely slowly. Likewise, the scheduler requests to send trickle-up messages alternate between success and failure to connect to the server.
Not really a change because this project had phases like this before, but…
…on December 3, the server stopped sending new work. Somebody posted about it at the message board, to no avail.
About ten hours ago the server started to send work again. But the validator is not working. (The map does work.) Furthermore, the message board alternates between responding quickly and
Last edited:
LHCathome-dev
added a Docker based version of Theory Simulation (already early inJuly March), as an alternative to the VirtualBox based application version. It's still a beta test.
https://lhcathomedev.cern.ch/lhcathome-dev/apps.php
Forum threads:
Theory Application : Docker on Windows
Theory Application : Docker on Linux
Theory Application : Docker on Mac
LHC@home
added a Docker based version of Theory Simulation (already early in
https://lhcathomedev.cern.ch/lhcathome-dev/apps.php
Forum threads:
Theory Application : Docker on Windows
Theory Application : Docker on Linux
Theory Application : Docker on Mac
LHC@home
They silently(?) removed the Sixtrack application from the server at some point in spring.
Last edited:
biodoc
Diamond Member
- Dec 29, 2005
- 6,338
- 2,243
- 136
They have a new application, Xtrack beam simulation, that does not require vbox or docker. It's linux only for now and they do release tasks from time to time. The last one I picked up completed successfully.
Oh indeed. Though this application is still limited to LHCathome-dev, not yet promoted to LHC@home.
biodoc
Diamond Member
- Dec 29, 2005
- 6,338
- 2,243
- 136
I forgot to mention that point. I did pick up one task recently and it was completed and validated. I assume the application is still in development (alpha or beta?).
climateprediction.net
In July, two new applications were added:
Work is not yet available, but should be sometime soon™.
The twist: Workunits for these "tl319" applications will have a memory footprint of 26 GB during peaks. Therefore, CPDN took two precautions:
(CPDN forum: announcement; prior discussion in October 2024)
Edit: tl319 tasks are projected to take 1.5...2 days using 4 cores on a desktop computer.
In July, two new applications were added:
- "OpenIFS 43r3 Multi-core Linear grid tl319 l91" = mt_oifs_bigmem version 1.06 (<name>oifs_43r3_omp_l319</name> in app_config.xml)
- "OpenIFS 43r3 parameter estimation multi-core linear grid tl319 l91" = mt_oifs_bigmem version 1.00 (<name>oifs_43r3_parest_omp_l319</name> in app_config.xml)
Work is not yet available, but should be sometime soon™.
The twist: Workunits for these "tl319" applications will have a memory footprint of 26 GB during peaks. Therefore, CPDN took two precautions:
- The maximum number of tasks in progress on a host is 1 for now. This is because BOINC client versions older than 8.0.2 may make a mess of concurrent tasks with high memory footprint.
- Distribution of tl319 work is blocked by default. A new option was added to the project preferences to opt in to this application.
(CPDN forum: announcement; prior discussion in October 2024)
Edit: tl319 tasks are projected to take 1.5...2 days using 4 cores on a desktop computer.
Last edited:
World Community Grid
From https://www.cs.toronto.edu/~juris/jlab/wcg.html, "Operational Status" tab:
It is down indeed, since several days now. They announced a downtime on short notice, for no less a purpose than a move of the infrastructure to a different server cluster. It didn't go over as it would have in a best-case scenario.
From https://www.cs.toronto.edu/~juris/jlab/wcg.html, "Operational Status" tab:
Rosetta@Home
According to @Kiska's server status tracker grafana.kiska.pw, Rosetta's latest batch was distributed to contributors' hosts on September 1, and it was a rather small one.
Rosetta@Home has had gaps in work supply like this. This is because they are a platform at which different scientists submit work batches for different experiments, larger and smaller.
According to @Kiska's server status tracker grafana.kiska.pw, Rosetta's latest batch was distributed to contributors' hosts on September 1, and it was a rather small one.
Folding@Home
Perhaps not so recent, but…
The user can add resource groups by clicking on the lock icon at the bottom right of the machine settings page of the client's Web Control. Each resource group has its own setting of how many logical CPUs may be occupied within this group, and which GPUs may be accessed within this group. There are some more per-group settings, such as whether to run only when idle, or whether to participate in beta projects. It is possible to over-allocate a host by means of two or more respectively configured resource groups; this should generally be avoided but can be useful under circumstances.
The upshot: Users lost some control of hardware resource usage going from FAHClient v7 to v8, but subsequent updates to v8 brought back effectively the same degree of control by subtly different means.
Perhaps not so recent, but…
In the v8.1 client software release, they introduced the concept of "resource groups". (In v8.2, this feature was retracted, and in v8.3 it was reintroduced. v8.4 and presumably v8.5 continue to offer this feature.) With this feature, the automatic and nontransparent allocation of CPUs and GPUs to workunits happens not across the whole host, but within each resource group.
The user can add resource groups by clicking on the lock icon at the bottom right of the machine settings page of the client's Web Control. Each resource group has its own setting of how many logical CPUs may be occupied within this group, and which GPUs may be accessed within this group. There are some more per-group settings, such as whether to run only when idle, or whether to participate in beta projects. It is possible to over-allocate a host by means of two or more respectively configured resource groups; this should generally be avoided but can be useful under circumstances.
The upshot: Users lost some control of hardware resource usage going from FAHClient v7 to v8, but subsequent updates to v8 brought back effectively the same degree of control by subtly different means.
Last edited:
climateprediction.net
Edit,
If you want to set CPU affinities, e.g. to confine all threads of the application instance onto a single CCX on Zen which should help a little bit with performance, pgrep for "oifs_43r3_omp_model.exe".
Points-per-day will probably be considerably higher than for previous OIFS work, except that you likely can't run as much work in parallel due to the high memory demand. (To run more than one task at once on a given computer, you have to set up additional BOINC client instances.)
You will also need plenty of upload bandwidth. There will be ≈700 MB largetrickle result files¹, and a task generates ≈39…46 of them during its ≈2…3 days of run time.
Edit:
Sigh. I have so much spare RAM that I could throw at this. But alas, my upload bandwidth, or lack thereof…!
Edit 2:
For work generated on Sep. 25 and later, size of the result files was halved. Contributors who aren't CPU or RAM limited but upload bandwidth limited can now run twice as many tasks at once. (Still only 1 task per client instance though.)
________
¹) These files aren't generated after the task is finished, but already while it runs (one file at every ≈2% computing progress) and are uploading in parallel with computing.
server_status.php shows a queue of new work for this now. This work batch was put on the server on September 5.
Edit,
The thread count of the application is hardwired to 4. As far as I can tell, there is no way for the user to change this, neither through a command line parameter nor through an environment variable.
If you want to set CPU affinities, e.g. to confine all threads of the application instance onto a single CCX on Zen which should help a little bit with performance, pgrep for "oifs_43r3_omp_model.exe".
Points-per-day will probably be considerably higher than for previous OIFS work, except that you likely can't run as much work in parallel due to the high memory demand. (To run more than one task at once on a given computer, you have to set up additional BOINC client instances.)
You will also need plenty of upload bandwidth. There will be ≈700 MB large
Edit:
Sigh. I have so much spare RAM that I could throw at this. But alas, my upload bandwidth, or lack thereof…!
Edit 2:
For work generated on Sep. 25 and later, size of the result files was halved. Contributors who aren't CPU or RAM limited but upload bandwidth limited can now run twice as many tasks at once. (Still only 1 task per client instance though.)
________
¹) These files aren't generated after the task is finished, but already while it runs (one file at every ≈2% computing progress) and are uploading in parallel with computing.
Last edited:
LHC@Home
The new application Xtrack, which is a successor of the SixTrack application, had been tested at LHC-dev for a while and went live at LHC@Home proper on September 24. Xtrack runs natively on Windows and on Linux (IOW does not require virtualbox) and is a singlethreaded application — much like SixTrack, but developed from an entirely new codebase. Even tough it was promoted from LHC-dev to LHC@Home, it is still marked as a beta application there. To receive work for it, "Run test applications?" needs to be enabled in project preferences.
From what I read: Also similar to SixTrack, Xtrack's task durations are rather variable, and cannot be predicted by boinc-client. My understanding is that the workunits' estimated FLOPS are set rather low on the server, plus that the the application does not report real progress to boinc-client. (This was subsequently improved in version 0.5 of the application, in which it reports an estimate to the client based on "turns" computed. But duration per "turn" remains variable.) Even the application cannot estimate how long each task will take, even after it ran for a while, due to the sort of physics which are simulated there. Furthermore, due to the far too low initial FLOPS estimation coming from the server, boinc-client fetches much more work than what you set as work buffer size. Therefore, better set the buffer to near zero days.
But at least SixTrack's notorious ultra-short tasks which greatly irritated boinc-client are supposed to be avoided in Xtrack. — Seems as if the problem remains, see @mmonnin03's reply below.
The workunits have a minimum quorum of 1, i.e. there are no wingman tasks for validation. This combined with varying and unpredictable task durations result in equally unpredictable credit relative to computer performance.
The new application Xtrack, which is a successor of the SixTrack application, had been tested at LHC-dev for a while and went live at LHC@Home proper on September 24. Xtrack runs natively on Windows and on Linux (IOW does not require virtualbox) and is a singlethreaded application — much like SixTrack, but developed from an entirely new codebase. Even tough it was promoted from LHC-dev to LHC@Home, it is still marked as a beta application there. To receive work for it, "Run test applications?" needs to be enabled in project preferences.
From what I read: Also similar to SixTrack, Xtrack's task durations are rather variable, and cannot be predicted by boinc-client. My understanding is that the workunits' estimated FLOPS are set rather low on the server, plus that the the application does not report real progress to boinc-client. (This was subsequently improved in version 0.5 of the application, in which it reports an estimate to the client based on "turns" computed. But duration per "turn" remains variable.) Even the application cannot estimate how long each task will take, even after it ran for a while, due to the sort of physics which are simulated there. Furthermore, due to the far too low initial FLOPS estimation coming from the server, boinc-client fetches much more work than what you set as work buffer size. Therefore, better set the buffer to near zero days.
The workunits have a minimum quorum of 1, i.e. there are no wingman tasks for validation. This combined with varying and unpredictable task durations result in equally unpredictable credit relative to computer performance.
Last edited:
FLOPs were set too high on some tasks at 500k and others more reasonable at 500 (no k). Due to the high FLOPs the client never thought any progress was made then would jump to completed. It also had very high ETA due to high FLOPs. The last batch ran only for a few seconds with some at less than 1 CPU second.
...and, I presume, due to BOINC having had increased the duration correction factor a lot while the FLOPS were too low.
Also, the sudden change of the FLOPS settings of the workunits apparently throw credits per computer time out of whack.
--------
A very technical presentation of the project was given on October 1:
https://indico.cern.ch/event/1559978/contributions/6664907/
Carlo E. Montanari et al, "DA [Dynamic Aperture] distributed-computing simulations via BOINC and ML modelling", 15th HL-LHC Collaboration Meeting at CERN
Edit, slide 17 of the presentation compares running the tracking simulation on a CERN internal cluster vs. on BOINC volunteer computers: "Xboinc provides a cost-free way for CERN to run large-scale simulation campaigns, harnessing significant computing power. It is not designed to replace standard HPC workflows (e.g. HTCondor), but rather to complement them, serving as a parallel resource for medium- to long-term data collection, while avoiding the saturation of local computing resources."
| CERN’s HTCondor | XBoinc | |
|---|---|---|
| CPU Job Throughput | Free capacity: 1k-10k jobs/hour Under heavy load: 10-100 jobs/hour | 100k+ jobs/hour available instantly (and still far from saturation) |
| Execution Efficiency | 1.0x (jobs run immediately once scheduled) | 3-4x slower due to volunteer old CPUs and execution delays |
| Execution Cost | Fully covered by CERN | Gracefully covered by volunteers |
| Supported Features | All workflows supported | Single particle tracking only |
Last edited:
500k FLOPs was not low.
Credit was high on a batch of work ~ a week ago. KetamiNO had 45m in a day.
Credit was high on a batch of work ~ a week ago. KetamiNO had 45m in a day.
For a while at least, the FLOPS which the project set in workunit batches were so low that volunteers reported that their clients got many more tasks assigned than desired, often more than could be finished before the reporting deadline. I suppose that it's now the opposite.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 22K
-
News NVIDIA and Intel to Develop AI Infrastructure and Personal Computing Products- Started by poke01
- Replies: 384
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
Facebook
Twitter