There's an entry called "LLR2 testing" is the Private GFN server. What is it?
____________
My lucky number is 6219*2^3374198+1

Pavel Atnashev wrote a variation on LLR that can support very fast double checking at the cost of large download/upload sizes. I believe stream's plan is to test it on his server before considering moving it to PrimeGrid. There is a chance that we won't move it to PrimeGrid if the bandwidth requirements are too large.

Here's a quote from him (ATN Flux) on discord:

Let me present my Prime Test Proof Scheme. By using this scheme a double checker would have to do only 5% of work to prove that the first tester's residue is correct. The price for that decrease in work is increased amount of data the tester has to return to the server. About 10-100MB need to be uploaded depending on subproject. But that data doesn't need to be stored. After relatively fast processing it is decreased to 2-8MB that should be stored and downloaded by a double checker. Actually, there's an inverse relation between work and data, the more data available, the less work has to be done. The exact balance is configurable.

For now, LLR2 testing only has apps for Linux, so if you checked the last box on receiving tasks from other subjects if there's no WU, it will give you other work like GFN16MEGA
____________
My lucky number is 6219*2^3374198+1

is it possible to receive only wu "LLR2 testing"
it happens to receive another application and it is not normal
thank you

Stream does it support Multi Threading?

If so what is the appconfig.xml description?

Cheers

Rob.
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Oh they're quite fast, nevermind 👍
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Stream does it support Multi Threading?

If so what is the appconfig.xml description?

Oh they're quite fast, nevermind

Stream does it support Multi Threading?

If so what is the appconfig.xml description?

Like in old LLR, without plan class.

<app_config> <app_version> <app_name>llr2</app_name> <cmdline>-t 4</cmdline> <avg_ncpus>4</avg_ncpus> </app_version> </app_config>

Oh they're quite fast, nevermind

Biggest problem is that they are... unpredictable now. Right now we're testing missing DC residues for k=121 up to 3,05M (where PG PPS search currently stopped) and candidates are growing fast. But then I could load k=27 with small candidates again, or JeppeSN's project, or whatever else if I need to test specific behavior.

Thanks stream, experimenting with it now.

It would be cool if we found one that was missed :)

says that it was last updated 16 days ago :)
https://github.com/patnashev/llr2
____________
My lucky number is 6219*2^3374198+1

Okay, just wondering
____________
My lucky number is 6219*2^3374198+1

We're on to 27 now stream, is 121 completed? or is it a mix of both?

Back to single threads. :)
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

We're on to 27 now stream, is 121 completed? or is it a mix of both?

My scheme is most inefficient bandwidth-wise with small numbers. I suspect the upload going to stream's server right now is larger than it'd be on SoB. Stress-testing.

Thanks for everybody who is helping us to test new LLR. With all your help, we found and fixed an obscure bug which happened sometimes on CPUs with AVX-512. The fix is available starting from version 1.03 of the Boinc app.

Please note that this is a test project, so:
- It may run out of work without warning;
- It will serve workunits of unpredictable size (from few seconds to few hours) and type (Proth, Riesel, base-2, non-base-2, etc) - depending on which part of LLR we're testing now.

And a last word for those who didn't participated in this project yet - if you want to receive LLR2 test tasks, you must check "Accept test/beta work" option in GFN server preferences (must be done for each necessary venue).

Stream will you have separate stats for the LLR2 tasks?

I'll add my computer to it for at least a period of time later today. Really looking forward to this and how much it could speed up the progress through some projects from the simpler double check effort.
____________

An completely new version of LLR2 has been installed on server.

This version implements a thing called Pietrzak's function which can compress checkpoints in logarithmic scale. Imagine - now we can have 128 checkpoints and only 9 files - 7 Pietrzak's files and first and last checkpoints must transferred to server! On server, reverse operation can recover all 128 checkpoints and doublechecking time will be as small as 1/128 of original test!

The cost of this improvement is significant increase of disk space and memory required by LLR to keep so many checkpoints. This is not a problem for current tests which currently are in 3M-4M range. In Proth tests, each checkpoint occupies N/8 bytes. In a test with N=4M it's enough to have 64 checkpoints by 500KB each, using 32 MB of disk space and. optionally, memory. This is not much, but for numbers in SoB range usage these of resources will be significant. Disk activity can be increased at the end of the test because in some cases all these checkpoints must be read from disk for compression. Again, it most setups it should not be a problem for numbers which we are currently testing.

The database currently contains a mix of old and new tasks so it's impossible to say which type of test is currently used. If you're interested, you can check stderr output and look for "Pietrzak" option when task completes.

Please report bugs, anomalies and task errors which you encounter.
Known problem: task failed with "finish file present too long" message in stderr.
This is a long-standing Boinc bug which has been there for ages. The only solution is to update to one of latest versions, where some fixed were finally applied (although I'm not sure that they covered all possible scenarios). My server attempts to ignore this bug, but in many cases client (probably due to another bug) also not uploading all checkpoint files (some are randomly missing) so results cannot be validated anyway.

Wow that's a nice enhancement! very nice. Well done!! Exciting times ;)
____________
My lucky numbers 1059094^1048576+1 and 224584605939537911+81292139*23#*n for n=0..26

An completely new version of LLR2 has been installed on server.

The database currently contains a mix of old and new tasks so it's impossible to say which type of test is currently used. If you're interested, you can check stderr output and look for "Pietrzak" option when task completes.

Finally, I've cathed Pietrzak task in progress and seen it's 40MB upload.

http://boincvm.proxyma.ru:30080/test4vm/result.php?resultid=123910726
____________
My stats

...there might have been another one running

I've got other 2 in progress, will update soon.
____________
My stats

There should be 32 temporary files 0.4MB each, they get compressed into 5 products 0.4MB each. The 5 products and the last checkpoint are uploaded = 6*0.4MB.

Just noticed that two of my tasks were PPS-MEGAs, k=21, are these okay?
____________
My lucky number is 6219*2^3374198+1

Okay. So this is a complete double check or is this just a test task? I'm not gonna abort it either way tho.
____________
My lucky number is 6219*2^3374198+1

Excuse me for this newbie question, but what does "Accepted, waiting for certificate" mean?
http://boincvm.proxyma.ru:30080/test4vm/workunit.php?wuid=61860142
____________
My lucky number is 6219*2^3374198+1

ah ok, so there are two tasks for one test, and the faster tests are the DC ones? The slower is Initial check ones too right?
____________
My lucky number is 6219*2^3374198+1

Okay. So this is a complete double check or is this just a test task? I'm not gonna abort it either way tho.

Okay. So this is a complete double check or is this just a test task? I'm not gonna abort it either way tho.

All tasks are important. There are no useless random tests here. Any task is either a DC of something that has no double checker according to PG records, either a new test, never tested before, where you can find a new prime (theoretically, we may also find a missing prime in one of these DC tests).

If you want to concentrate on JeppeSN's project, it's OK to abort other k's, I will not object.

Hi, recently on my home page I discovered an entry called "LLR2 Testing Credit". All seems fine until the "average". This average seems to be higher than my RAC, which leads to my question--what is it?
____________
My lucky number is 6219*2^3374198+1

Hi, recently on my home page I discovered an entry called "LLR2 Testing Credit". All seems fine until the "average". This average seems to be higher than my RAC, which leads to my question--what is it?

Hi, recently on my home page I discovered an entry called "LLR2 Testing Credit". All seems fine until the "average". This average seems to be higher than my RAC, which leads to my question--what is it?

Probably average calculated over last 10 days, so your current Rac is lower than your average over that time maybe?

Also I have a question that may be off-topic: Why do new users have strange RACs?
For example here: https://www.primegrid.com/team_members.php?teamid=14&offset=1&sort_by=expavg_credit
Rich and Michael have the same amount of credit, Rich registered earlier, but he has more RAC. Why is this? And how is RAC actually determined?

As Mike already explained, Boinc developers thought about something like average credit per day, but they have no full history of tasks, so they ended up with weird function, which produces results which may be mathematically correct but unpredictable for human. So I've disabled this useless feature at per-subproject stats.

Also I have a question that may be off-topic: Why do new users have strange RACs?
For example here: https://www.primegrid.com/team_members.php?teamid=14&offset=1&sort_by=expavg_credit
Rich and Michael have the same amount of credit, Rich registered earlier, but he has more RAC. Why is this? And how is RAC actually determined?

tl;dr: The difference in RAC is due to the timing of when credit was granted.

If you really want to look inside the proverbial sausage factory...

RAC doesn't work the way you think it works, nor does it work the way you think it should work.

The way you might think it works (and that perhaps the way one would want it to work) is to calculate the total credit granted over the previous X days divided by X. This would require a lot of database access to calculate, so it's not done that way.

Instead, BOINC stores a value for RAC as well as the time at which RAC was last calculated. Given those two values and the credit to be applied, it calculates a new RAC value. The amount that RAC changes therefore depends on the time since the previous credit was granted.

Furthermore, once a day the system checks to see if you have been granted any credit in the last 24 hours. If you have not earned any credit in the last 24 hours then your RAC is decreased slightly. Since normally BOINC only adjusts RAC when you are granted credit, this is necessary to make RAC decrease over time when you're no longer doing any work.

Active LLR2 testing on GFN server is coming to the end. Thanks to your help, we tried many types of test- "+1", "-1", "b=2", "b <> 2" - in different combinations. Many things were changed on server, and we had to release urgent LLR2 patches once or twice... Thanks again, it was possible only with your participation.

Roadmap for LLR2 on GFN server

- LLR2 project will continue to exist. Right now we have about 9700 b=383 "-1" tests left to do, it's not much and can be completed in a week or less.

- When b=383 finishes, I will load double-check of PPS MEGA tests from PrimeGrid (again). This task is also very important because many PPS MEGA results for k < 100 lacks double-checking - they were either imported from PrpNet either tested in one pass. There is a chance to find a missing MEGA prime, although it's very small (there are about 1% of mismatching residues).

- At some point we'll continue JeppeSN's project on Proth-restricted Sierpinsky problem. It will be hard, but we may find new big primes on k's which were never tested before. I put many cores on sieving for this problem and soon will have sieve optimal enough to load n=4M to 7M. A very rough estimated date is a middle of the July, but it can be changed in any direction depending on state of sieving and other project (to avoid splitting of resources). Please check project thread for future announcements.

- Right after end of PPS Sieve PrimeGrid challenge, new project will be open on GFN server - GFN-15 First MEGA Search. It'll be similar to recently finished GFN-16 MEGA Prime Search - the goal is to find first GFN-15 MEGA prime and, if we'll be lucky, this prime is also expected to be new smallest prime with exactly one million digits. The project will be run on LLR2 completely, so I'm expecting 80% speedup comparing to classic searches (LLR2 efficiency is about 80% on these types of tests, but second pass is eliminated completely). Since only one task is required to test a candidate, you don't need fight to be first. If you got a task, it'll be yours. Just return you homework in time.

Roadmap for LLR2 on PrimeGrid

- The integration of Gerbicz check is in progress. Right now I'm working on new applications and changes in validator, which should accept new program version and probable new output message.

- After that, full integration of LLR2 into PG will be started. I will not give any promises about timings because this work is very, very, very difficult. PG is a very complex server, a LLR2 logic is absolutely different from anything that was ever run on Boinc. I wrote LLR2 processing on GFN Server as portable as possible, but it still will be crazy hard work to adopt in to existing extremely complex server having tens of scripts and different hand-written modules running.

Thank you for doing so much behind the scenes!
Wonder how amazing PrimeGrid will be when you guys leave ;)
____________
My lucky number is 6219*2^3374198+1

LLR2 project will continue to exist. Right now we have about 9700 b=383 "-1" tests left to do, it's not much and can be completed in a week or less.

- When b=383 finishes, I will load double-check of PPS MEGA tests from PrimeGrid (again). This task is also very important because many PPS MEGA results for k < 100 lacks double-checking - they were either imported from PrpNet either tested in one pass. There is a chance to find a missing MEGA prime, although it's very small (there are about 1% of mismatching residues).

Hi, is b=383 finished?

It is not, but we are getting close. My most recent tasks are at n= ~427,000, out of a maximum of 440,000.

Almost there :)

Hi, is b=383 finished?

Hi, is b=383 finished?

Almost. All tests has been converted to workunits. There are 900 WUs waiting to be sent and 650 are currently in progress.

Also, are the MEGA double checks long WUs or 1-2min validation WUs?

Also, are the MEGA double checks long WUs or 1-2min validation WUs?

To doublecheck, you must run this WU again. In case of missing or mismatching residue, additional short validation workunit will be sent to confirm that our result is correct one.