I'm happy to say that new software, LLR2, is installed on almost all big LLR projects.

LLR2 is a rewrite of LLR with amazing new features:

- It does not requires second task to verify correctness of result. Instead, a "proof of computation" is built and later validated. Validation of the proof takes just about 1% of original task length.
- Since only one long test required to find a prime, you always will be first. Any, even old and slow hardware will find a prime. Prime hunting becomes more like lottery - if you got a lucky ticket from the server, you'll win no matter will you open it sooner or later.
- It can detect and correct computing errors. No more inconclusive tasks!

These new features have it's price:

- New tasks will use more memory and disk space;
- The proof of computation must be uploaded to server. Length of the proof, in bytes, is roughly equal to the "N" of the test. So a task with N=10M will need to upload about 10 MBytes of data. So:
- Be careful if you have a metered or paid connection;
- If upload speed of your connection is too low (DSL or some cellular types), limit upload speed in Boinc settings. This will not affect speed of calculations (Boinc will start calculations of new task first, then slowly upload results of previous task).
- A MAC application is not ready yet. If you're using a MAC, either switch to another project (see list below) either run Linux in a virtual machine. A MacOS application at 321 project requires MacOS 10.15 and above. Applications on other projects can work on older MacOS versions 321 project will be updated to compatible app when all it's old tasks will be finished.
- It seems that minimal supported MacOS version is 10.7.

Project currently converted to LLR2
321
CUL
ESP
PSP
SOB
TRP
WOO
GCW (2020-09-19)
SR5 (2020-09-19)
DIV (2020-09-25)
PPS-MEGA (2020-11-03)
PPS

Projects which status is unknown:
PPSE (currently in LLR2, but may be reverted back to LLR if servers will not handle load)

Project which will be NOT converted in nearest future:
SGS

Hi, i run 12 321 small Tasks and got full pending credit(6500+Credit).
Is this temporary, or a bug?

https://www.primegrid.com/workunit.php?wuid=674629315

https://www.primegrid.com/workunit.php?wuid=674629313

Thanks.

b n depth DC Temporary Upload Download ----------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- 321 2 16075875 7 1/128 245 MB 15 MB 1.9 MB CUL 2 18310545 7 1/128 279 MB 20 MB 2.2 MB ESP 2 14820654 7 1/128 226 MB 14 MB 1.8 MB PSP 2 22513138 7 1/128 344 MB 21 MB 2.7 MB SOB 2 32698611 7 1/128 499 MB 31 MB 3.9 MB TRP 2 10796670 7 1/128 165 MB 10 MB 1.3 MB WOO 2 18730248 7 1/128 286 MB 20 MB 2.2 MB GCW 121 2022636 7 1/128 214 MB 15 MB 1.7 MB DIV 2 6166918 7 1/128 94 MB 6 MB 0.7 MB SR5 5 3173566 7 1/128 112 MB 7 MB 0.9 MB PPS-MEGA 2 3337564 7 1/128 51 MB 3 MB 0.4 MB

Fab news ! You mentioned more RAM needed - let's say you were getting a 64 core threadripper and running 1 task per core (no hyper or multi thread as no rush to return result now to be first), how much RAM would you need running the 64 tasks ?

New tasks will use more memory

This changes how we use FFT x 8 for tasks to run in cache?

b n depth DC Temporary Upload Download ----------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- 321 2 16075875 7 1/128 245 MB 15 MB 1.9 MB CUL 2 18310545 7 1/128 279 MB 20 MB 2.2 MB ESP 2 14820654 7 1/128 226 MB 14 MB 1.8 MB PSP 2 22513138 7 1/128 344 MB 21 MB 2.7 MB SOB 2 32698611 7 1/128 499 MB 31 MB 3.9 MB TRP 2 10796670 7 1/128 165 MB 10 MB 1.3 MB WOO 2 18730248 7 1/128 286 MB 20 MB 2.2 MB GCW 121 2022636 7 1/128 214 MB 15 MB 1.7 MB DIV 2 6166918 7 1/128 94 MB 6 MB 0.7 MB SR5 5 3173566 7 1/128 112 MB 7 MB 0.9 MB PPS-MEGA 2 3337564 7 1/128 51 MB 3 MB 0.4 MB

Cool!! GCW, DIV, SR5, and MEGA joined the list too? Nice!

Fab news ! You mentioned more RAM needed - let's say you were getting a 64 core threadripper and running 1 task per core (no hyper or multi thread as no rush to return result now to be first), how much RAM would you need running the 64 tasks ?

First of all, the multi-threading thing must be used anyway. It will improve overall efficiency of your PC because internal CPU cache will be utilized better. You will finish more tasks per day with multi-threading.

As for RAM usage, some tasks may use up to 512M. Note the you don't heed to have so much physical RAM - RAM is used to cache some rarely used data so having a large enough virtual memory (swap file) in you OS will be sufficient (OS will automatically move this data to the swap file and back when necessary).

Greetings ... does the new llr2 application is going to be downloaded automaticaly ... ?

i've made a reset and detach, however ... the mt application for SoB ... has a value of 8.10 instead of 9.00 ?

should we wait ?

sincerely, Grzegorz Roman Granowski

Yes, it will be doiwnloaded automatically, but there's still "old" workunits that use 8.04 in the queue that have to be sent out first.

With SoB, there's about 164 old 8.04 candidates ahead of the ne 9.00 candidates.

Just to emphasise how bad an idea it is to run a task per core where multithreading is the better option I've kicked off 16 SoB tasks on my 3950x.
If I run 2 tasks with 8 threads each I can run roughly 2.5/day.
After 15 minutes of running 16 tasks the estimate was for 18.5 days.
18.5*2.5 = 46. So you'll get roughly 1/3 the throughput by loading up all cores and on a threadripper it will likely be even worse.

I am having trouble following your comment about threadrippers. TRs have 128mb or 256mb of L3. That is way more L3 per core than any other non-server CPU. You should be able to run 1 task per core without coming close to filling the L3.

Woodall has about 518 old workunits in the queue.

Prime hunting becomes more like lottery - if you got a lucky ticket from the server, you'll win no matter will you open it sooner or later.

Woodall has about 518 old workunits in the queue.

I read somewhere only Proth-types were getting LLR2 at the beginning, so this has extended to -1 as well?

Why are PPS/PPSE and SGS excluded for now? Aren't they all using cllr anyway? Has it to do with their smaller size?

I am having trouble following your comment about threadrippers. TRs have 128mb or 256mb of L3. That is way more L3 per core than any other non-server CPU. You should be able to run 1 task per core without coming close to filling the L3.

I didn't get the claim either, but current Threadrippers don't have any more cache than their desktop counterparts at 16MB/CCX. Per core varies depending on how many cores are active per CCX, but at max core configuration it is 4MB/core. That's only enough for smaller tasks, maybe up to MEGA without looking up actual current FFT sizes.

A MAC application is not ready yet. If you're using a MAC, either switch to another project (see list below) either run Linux in a virtual machine.

I'm running Macs, will I be sent LLR2 tasks and it comes back as an error, or will it just not send me anything once all of the straggler LLR tasks are finished?

It won't send you anything. However, we may have a Mac app "Real Soon Now"^TM. The 321 app has a Mac app right now, actually. Why don't you go ahead and test it?

There are several Mac LLR2 321 tasks out running now - assuming they verify and nobody hits any problems, the Mac code should be good to roll out to the other subprojects. The actual LLR2 code was thoroughly tested on Mac, it was the wrapper that was a problem and JUST got finished yesterday. So it had, um... minimal testing... The nature of the wrapper though is that if it runs at all, it's probably good to go.

could I please have an update how many more tasks are left for the old application for SoB? ... ???

Having no luck on an I7 Mac mini, even after installing latest Boinc and resetting project.

https://www.primegrid.com/result.php?resultid=1129704408

New MAC application, which should work on old versions of Mac OS down at least to 10.7, was installed on TRP project.

After we finish testing of this version on TRP for both new and old OS versions, it will be installed on all remaining projects except 321. Unfortunately, it's not possible to update an application at 321 until all old workunits are finished. So, if you have old Mac OS below 10.15, please switch to TRP and give new application a try.

An important note for anyone who has an app setting affinity for these processes is that they're now called llr2_1.0.0_win64_200814.exe rather than primegrid_cllr.exe.

all of them are marked first so I'm guessing they are "test" units. Either way dang it's fast... fast... fast...

It takes about the same time as the old tasks

greetings ... I have some 9.00 SoB wu's dowloaded ... so I guess there is none old, 8.04 work units ... left ...

Someone once posted a table with probabilities of a certain n producing a prime for the remaining k's of the various Sierpinski subprojects. It was quite low for some of them.

Generally, the larger n gets, the less likely it is that the number is prime just due to it being larger and larger... :D

Woodall still has 287 old workunits to go.

... Finally, ESP has 241 to go.

Using this statistical average, it appears that at n=4,096,000,000 will be the first doubling of n, that brings us under 1 k remaining.

After some testing, it seem that minimal supported MacOS version will be 10.7 (a task run on 10.6.8 failed due to incompatible C++ library, if I remember correctly Apple switched to new C++ library in 10.7).

Given that all of the work for DIV has been generated, would it make sense to remove, re-process, and move it to LLR2?
____________
My lucky #: 60133106^131072+1 (GFN 17-mega)

Given that all of the work for DIV has been generated, would it make sense to remove, re-process, and move it to LLR2?

Given that all of the work for DIV has been generated, would it make sense to remove, re-process, and move it to LLR2?

The state of DIV is currently being discussed. It's a big temptation to move it to LLR2 considering upcoming challenge, which will receive a 2x boost. On the other hand, the challenge is a problem - network bandwidth required to upload checkpoints and CPU resources to validate them in reasonable time may overload our current infrastructure.

Given that all of the work for DIV has been generated, would it make sense to remove, re-process, and move it to LLR2?

The state of DIV is currently being discussed. It's a big temptation to move it to LLR2 considering upcoming challenge, which will receive a 2x boost. On the other hand, the challenge is a problem - network bandwidth required to upload checkpoints and CPU resources to validate them in reasonable time may overload our current infrastructure.

One option would be to only send out the actual tasks during the challenge and then after it's over send out the checkpoint files. Since the checkpoint files are smaller they will be done very quickly and most people will get their credits for the challenge within a couple of days after it's over. There has always been 'cleanup time' after a challenge anyway so this would just be part of that. You could even put a 2 or 3 day time limit on the checkpoint tasks to ensure they get done asap.

There seems to be quite a bit of confusion as to how LLR2 fast double checking works. I'm going to describe what the process is, so you have a better understanding of what to expect, and also what the drawbacks are. I'm going to skip all the math parts that make this possible, because it's not necessary to understand the "how" in order to comprehend the "what".


OLD LLR process:

Identical tasks are sent to two computers, which run the full, long, computation. A very short result is sent back to the server, and the results from the two computers must match to be validated. We're all familiar with this paradigm.


NEW LLR2 process:

Just one full task is sent out. At the end of the computation, the same (or at least similar) short result is returned to the server.

There's an additional new step, however. At various times during the computation, LLR2 is recording checkpoints to disk. These are fairly large, and a substantial number of them are recorded. This takes up disk space on your computer, so you'll need somewhat more disk space for LLR2 than you did for LLR.

At the end of the computation, all of those checkpoints are compressed, and the compressed checkpoints are sent to the server along with normal short result. The checkpoints are then deleted from your computer, freeing up your disk space.

Sending the compressed checkpoints to the server uses a lot of bandwidth, and then the checkpoint files use a lot of disk space on the server. When we built these servers, our applications did not consume a lot of bandwidth and did not use a lot of disk space. The current servers aren't designed for LLR2's requirements, so we have to manage LLR2's rollout very carefully, or PrimeGrid will essentially die.

Once the short result and the compressed checkpoints are sent to the server, your computer tells the server that the task is completed. Your task then goes into the "pending validation" state.

The server now uses the compressed checkpoints from your full task to create the fast DC task. It decompresses the checkpoints, does a moderately lengthy FFT-style computation (single core takes a few tens of seconds for a TRP), and creates the fast DC task in a new workunit. The large checkpoint files are then deleted, freeing up disk space on the server. The new fast DC task then gets sent to a user, gets quickly processed (it's less than 1% of the main task), and sent back to the server. The server checks this result against information from the main result, and if correct, both are validated and get credit. The fast DC's credit is proportionally smaller than the credit for the main task, of course.

From the server's perspective, there are three problems here:

* The bandwidth used sending the compressed checkpoints from the main task up to the server.

* The CPU time consumed processing those checkpoints in order to create the fast DC tasks.

* The potential for exhausting all of the server's disk space if we fall behind in creating the fast DC tasks.

Smaller, more numerous tasks are a larger problem than a small number of larger tasks. This is why we're moving the big tasks to LLR2 but the small tasks, at least for now, are staying with the old style full double checking.

____________
My lucky number is 75898⁵²⁴²⁸⁸+1

On a side note - since DC tasks are much smaller, has deadline for those tasks been considered?

Not that it would solve just mentioned but while moving my resources from already LLR2 TRP to newly LLR2 SoB, it would nice to have DC tasks back sooner.
____________
My stats

On a side note - since DC tasks are much smaller, has deadline for those tasks been considered?

The Initial (Large) tasks and Double check (small tasks) all show up as 1st. Is/was this expected?

All seven of the projects where LLR2 fast double checking is enabled should now be primarily sending out tasks using fast double checking. There will be some stragglers with the old LLR for a while, because of resends, but the old tasks have all now been sent out.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

As the first test and the double check are now in two distinct work units, is it possible to "e-meet" each other or only when there is a prime and an official announcement?

We haven't looked at it yet, but since 321 now takes half as long to check as it did before, the optimal sieving point for the 321 sieve should be half of what it was before.

Off the top of my head, we're almost certainly now past the revised optimal sieving point. We haven't run the numbers yet, but those of you prone to panicking about getting that next/last badge whenever something is shut down should probably start thinking about your plans for 321 sieve badges.

It's entirely possible that the official 30 day warning may be given in the very near future. On the other hand, this decision has not been made yet, and there's other reasons to keep the sieve running. So it's not 100% certain that we'll be suspending the sieve soon, but it's certainly possible.

Consider this to be the pre-warning to the 30-day warning for the suspension of the 321-sieve.

____________
My lucky number is 75898⁵²⁴²⁸⁸+1

GCW and SR5 are on LLR2 now.

LLR2 tasks where b<>2 are running slower then standard LLR tests. Depending on test conditions (CPU type, single or multi-threaded LLR, etc), the loss is from 20 to 35%. Anyway, running one task in 1,35 of original time is still much better then running two full tasks (2,00).

Credit for these tasks has been scaled accordingly. Please note that pages which show "pending" credit may temporary show incorrect values until validator processes a workunit at least once. We're working on improvement of this behavior.

We haven't looked at it yet, but since 321 now takes half as long to check as it did before, the optimal sieving point for the 321 sieve should be half of what it was before.

Off the top of my head, we're almost certainly now past the revised optimal sieving point. We haven't run the numbers yet, but those of you prone to panicking about getting that next/last badge whenever something is shut down should probably start thinking about your plans for 321 sieve badges.

It's entirely possible that the official 30 day warning may be given in the very near future. On the other hand, this decision has not been made yet, and there's other reasons to keep the sieve running. So it's not 100% certain that we'll be suspending the sieve soon, but it's certainly possible.

Consider this to be the pre-warning to the 30-day warning for the suspension of the 321-sieve.