TennesseeTony
Elite Member
Running a pair of test WUs now, on a GTX 1070 under Windows. Estimated 33min until completion. Looks like Asteroids is STILL a CPU project (Ryzen 3000 series runs a CPU task in under an hour on average).
First one finished in 26m19s.Notes: 100% GPU usage, but only 55-60% of the power target, almost no CPU usage (some spikes occasionally). Progress bar and time remaining freeze then jump ahead significantly.
Last edited:
Rosetta@home
After a brief test of the https URL scheme at Ralph@home, Rosetta@home switched its project URL from
If you have still the old URL on your computers, you can keep using it. Switch over only at a time when you have no Rosetta tasks on the computer.
Furthermore, the application version was updated from v4.15 to v4.20 just half a day ago. I haven't looked up yet what the changes are. I wasn't attentive at Ralph@home for the testing period of v4.20, which lasted just 17 hours.
Edit,
v4.20 has a fix for occasional failures to create initial task files. This problem of the previous version would cause tasks failing with error very early during execution, AFAIK. I haven't found out yet whether there are any other fixes in it.
Edit 2,
the v4.20 update includes according to a forum post:
After a brief test of the https URL scheme at Ralph@home, Rosetta@home switched its project URL from
http://boinc.bakerlab.org/rosetta/ to https://boinc.bakerlab.org/rosetta/. They made this change because companies, who want to contribute computer time, asked for it.If you have still the old URL on your computers, you can keep using it. Switch over only at a time when you have no Rosetta tasks on the computer.
Furthermore, the application version was updated from v4.15 to v4.20 just half a day ago. I haven't looked up yet what the changes are. I wasn't attentive at Ralph@home for the testing period of v4.20, which lasted just 17 hours.
Edit,
v4.20 has a fix for occasional failures to create initial task files. This problem of the previous version would cause tasks failing with error very early during execution, AFAIK. I haven't found out yet whether there are any other fixes in it.
Edit 2,
the v4.20 update includes according to a forum post:
- extraction of the Rosetta database into the project directory with all following jobs reading from the same database rather than extracting into the slot directory for every job. This significantly reduces the disk usage per job.
- checkpointing in the Rosetta comparative modeling protocol. This should significantly reduce wasted cpu time if jobs are preempted often, particularly for jobs that take a long time to produce models.
Last edited:
PrimeGrid
An LLR2 applications is being tested since ~a week now. Its important change over LLR is that it incorporates runtime self-tests for software and hardware errors, by Robert Gerbicz. It will not replace LLR completely; LLR will continue to be used in subprojects which test k*2^n-1, as well as on 32bit hosts.
Translated from German:
The LLR2 application is already live. It's version 8.10 among the LLR-based applications:
CUL, DIV, ESP, MEGA, PPS, PPSE, PSP, SOB.
An LLR2 applications is being tested since ~a week now. Its important change over LLR is that it incorporates runtime self-tests for software and hardware errors, by Robert Gerbicz. It will not replace LLR completely; LLR will continue to be used in subprojects which test k*2^n-1, as well as on 32bit hosts.
stream said:
(found via a post from pschoefer in the SETI.Germany forum)Pavel Atnashev said:
Translated from German:
Update:pschoefer said:
The LLR2 application is already live. It's version 8.10 among the LLR-based applications:
CUL, DIV, ESP, MEGA, PPS, PPSE, PSP, SOB.
Last edited:
PS,
the potential big impact for less double-checking might come from the so-called "fast double-check" feature, alias "Proth/PRP test proof verification/ certification scheme" proposed by Pavel Atnashev. This feature is already implemented in LLR2, but not yet implemented in PrimeGrid's validator, hence not yet used in PrimeGrid's 8.10 application versions.
the potential big impact for less double-checking might come from the so-called "fast double-check" feature, alias "Proth/PRP test proof verification/ certification scheme" proposed by Pavel Atnashev. This feature is already implemented in LLR2, but not yet implemented in PrimeGrid's validator, hence not yet used in PrimeGrid's 8.10 application versions.
emoga
Member
- May 13, 2018
- 93
- 117
- 76
Fardringle
Diamond Member
- Oct 23, 2000
- 8,696
- 269
- 126
The tasks I'm getting are only 5 - 7 MB each...
Edit: Completed tasks receive 260 credits, regardless of how long they take. So far I've had run times anywhere from 10.5 minutes to 75 minutes on my Ryzen 9 3900X, with most of them in the 65-70 minute range.
Last edited:
RakeSearch (the one with the nicest badges of them all)
https://rake.boincfast.ru/rakesearch/forum_thread.php?id=234
(CPU, Windows, Linux)
Server status is showing 36 % completion of this run. Seems still to be a test of the waters to prepare for the real comeback.
Two weeks ago, RakeSearch rebooted with an application "SAT-based search for orthogonal pairs of DLS of order 10":
https://rake.boincfast.ru/rakesearch/forum_thread.php?id=234
(CPU, Windows, Linux)
Server status is showing 36 % completion of this run. Seems still to be a test of the waters to prepare for the real comeback.
TennesseeTony
Elite Member
Come on Rosetta......seriously? 40 GB RAM for one task?
Last edited:
The virtual set size is the less interesting figure. Especially on Linux which overcommits the system memory. The "working set size" or "resident set size" ("rss") is the more important figure, because this is what really lives in physical RAM at a given moment.
However, your second screenshot shows the horrible news that this task has got an RSS which is almost as big as the virtual memory size of this process, i.e. 40 GB indeed. :-O
A counter example: I've got GPUGrid's acemd3 running right now. Each of these tasks has got ~30 GB virtual memory size, but only ~400 MB working set size. I have three acemd3 tasks running at once (plus forty jobs of a CPU project) on a Linux system which has merely 32 GB physical RAM and a 32 GB swap partition. There you can see how the Linux kernel overcommitted the 2x 32 GB which are present in the system. This policy of overcommitment is possible and sensible because many programs never actually populate a more or less considerable fraction of the memory which they allocate.
(If suddenly the three acemd3 processes decided to access all of their memory, the Linux kernel's out-of-memory killer (OOM killer) would spring into action and snipe one heavy memory user after another until the OOM situation is cleared.)
But your Rosetta task did indeed access almost all of the memory which it allocated.
Edit,
your finding made me go look through the Rosetta forum for any announcement of such large jobs. I did not find any. I may have missed it though because the forum is so horribly disorganized and extremely noisy. But the more likely and expected explanation is that there really has not been such an announcement yet — if this large memory usage is by design, not due to a bug.
However, your second screenshot shows the horrible news that this task has got an RSS which is almost as big as the virtual memory size of this process, i.e. 40 GB indeed. :-O
A counter example: I've got GPUGrid's acemd3 running right now. Each of these tasks has got ~30 GB virtual memory size, but only ~400 MB working set size. I have three acemd3 tasks running at once (plus forty jobs of a CPU project) on a Linux system which has merely 32 GB physical RAM and a 32 GB swap partition. There you can see how the Linux kernel overcommitted the 2x 32 GB which are present in the system. This policy of overcommitment is possible and sensible because many programs never actually populate a more or less considerable fraction of the memory which they allocate.
(If suddenly the three acemd3 processes decided to access all of their memory, the Linux kernel's out-of-memory killer (OOM killer) would spring into action and snipe one heavy memory user after another until the OOM situation is cleared.)
But your Rosetta task did indeed access almost all of the memory which it allocated.
Edit,
your finding made me go look through the Rosetta forum for any announcement of such large jobs. I did not find any. I may have missed it though because the forum is so horribly disorganized and extremely noisy. But the more likely and expected explanation is that there really has not been such an announcement yet — if this large memory usage is by design, not due to a bug.
Last edited:
- May 16, 2002
- 20,566
- 8,413
- 136
a while back, my 7742 had 20 some tasks waiting on memory, and that box has 128 gig. But with 124 threads of Rosetta, thats only one gig per task. I have one box right now (my other 7742) with one task waiting on memory.
I will have to see if its the 40 gig tasks...
NFS@Home
Two new applications were added: "lasievee_small" and "lasievef_small". Actually, while they are new applications from the BOINC point of view, they use the existing executable files of lasievee and lasievef. Just the workunit space has been split off, in order to go with the times of ever growing numbers to be factored.
In total, there are now these applications which you can select in NFS@Home preferences:
Two new applications were added: "lasievee_small" and "lasievef_small". Actually, while they are new applications from the BOINC point of view, they use the existing executable files of lasievee and lasievef. Just the workunit space has been split off, in order to go with the times of ever growing numbers to be factored.
In total, there are now these applications which you can select in NFS@Home preferences:
- lasived (14e Lattice Sieve),
very small numbers, uses less than 0.5 GB memory, work may be infrequently available - lasievee_small (15e Lattice Sieve for smaller numbers),
small numbers, uses up to 0.8 GB memory - lasievee (15e Lattice Sieve),
medium numbers, uses up to 1 GB memory - lasievef_small (16e Lattice Sieve for smaller numbers),
large numbers, uses up to 1 GB memory - lasieve5f (16e Lattice Sieve V5),
huge numbers, uses up to 1.25 GB memory
- May 16, 2002
- 20,566
- 8,413
- 136
I can't figure out how to make screen copies in linux, but this is the thrird 40 gig process that I have seen. My 7452 has 128 gig of ram, and most processes in Rosetta are taking 1.5 to 2 gig ram (60 Rosetta tasks or so) but now I have 20 tasks waitng for memory and that 40 gig one.
arg !!!!
If you use the Cinnamon desktop of Linux Mint, simply press the [PrtSc] key to capture the whole screen, or [Alt][PrtSc] to capture the currently focused window.
After that, a window pops up which lets you save the screenshot as a file.
After that, a window pops up which lets you save the screenshot as a file.
- May 16, 2002
- 20,566
- 8,413
- 136
TennesseeTony
Elite Member
Mark, the Rosetta forum suggested that the 40GB tasks end up crashing, so you should abort any you find. Also suggested was that they only occur on Linux systems.
One reported that he managed to complete such a task. But the task spent all the time in the first "decoy" (IOW was unable to complete the first of several stages of computation), thereby took a lot longer than it should have, and received very low credit once its result was reported. This is another hint that such tasks are faulty.
Windows hosts appear to be afflicted too.
Windows hosts appear to be afflicted too.
![[H]Coleslaw](/data/avatars/s/344/344729.jpg?1560615061){kind=avatar}
TRENDING THREADS
-
-
-
Discussion AMD failure in notebooks really was due to giving igps priority over cpu?
- Started by Shivansps
- Replies: 95
-
Question Speculation: RDNA2 + CDNA Architectures thread- Started by uzzi38
- Replies: 2K
-
Facebook
Twitter