PrimeGrid
Please visit donation page to help the project cover running costs for this month

Toggle Menu

Join PrimeGrid

Returning Participants

Community

Leader Boards

Results

Other

drummers-lowrise
1) Message boards : General discussion : Enable Gerbicz correction in LLR2 (Message 147656)
Posted 10 hours ago by stream
Output looks like this:

1281979*2^881354+1 is not prime. Proth RES64: 5ED56E985D576B6A Time : 851.548 sec. Using zero-padded FFT length 96K, Pass1=128, Pass2=768, clm=4, a = 3, L2 = 246*224 1281979*2^881714+1, bit: 810000 / 881713 [91.86%], 771456 checked. Time per bit: 1.001 ms.


So it seems it's not enabled? I used llr2 -i tasks.pfgw -d as the command.

It's enabled - 771456 checked - this is amount of iterations passed Gerbicz check.
As far as I remember latest LLR2 has Gerbicz check enabled by default for Proth tests because it's fully compatible and has almost zero cost in Proth. Other types of tests need an option - enabling Gerbicz will change their mode and/or residue.

Also ignore my previous words about "few last iterations are not covered by Gerbicz check". Pavel later corrected me that they are also protected.
2) Message boards : Seventeen or Bust : Seventeen or Bust and the Sierpinski Problem (Message 147618)
Posted 2 days ago by stream
What happened with that 32M task?

You mean last unfinished task? Somebody crunching it since September, the host is alive and reporting but his last report was only 2% completed... The final deadline is February 06, hopefully next person will be faster.
3) Message boards : Generalized Fermat Prime Search : GFN-14 Consecutive Primes Hunt Season is open! (Message 147473)
Posted 8 days ago by stream
And... We're done!

All tasks returned. 10304 primes are now on the GFN-14 history page. A final statistic has been generated.

Congratulations to our top 3 users: Kellen, tng and Penguin, who found more then 1000 new primes each! Congratulations to all participants who made it possible! It was a long way since October 2017.

Server maintenance was successfully finished. The work on new GPU GFN project is also in progress, but exact start date is not determined yet. I'll create a new thread as soon as it'll be ready.
4) Message boards : The Riesel Problem : LLR TRP app Updated? (Message 147472)
Posted 8 days ago by stream
Boinc use "srw_win32_201105.exe" when I crunch TRP. but my PC win 10 64 and CPU AMD 2700X. Something wrong how do I get the 64bit app for TRP ? any help appreciated.

This is a not an app, this is a "wrapper" - a small program which controls big main program. Main program does all real work. Its name is "llr2" and this program is 64-bit.
5) Message boards : Generalized Fermat Prime Search : GFN-14 Consecutive Primes Hunt Season is open! (Message 147448)
Posted 10 days ago by stream
Server maintenance will happen Sunday, January 10, between 09:00 UTC and 15:00 UTC. During maintenance, scheduler and site may be temporary offline. File uploads should work.

Regarding GFN-14 cleanup. There are 181 tasks remaining, most of them will be recycled January 09. Last task will be recycled January 10 at 01:11 UTC. Hopefully they'll be returned fast and project will be finished.
6) Message boards : General discussion : Enable Gerbicz correction in LLR2 (Message 147436)
Posted 10 days ago by stream
I wanted to do some manual prime hunting and I'm not sure if Gerbicz is enabled by default or not. The help doesn't mention it at all, so I just had a look at PG's commandline and it has the option -oGerbicz=1. I added that but there is no confirmation the check is actually activated.

AFAIR in latest version it's enabled by default for Proth tests. For other types of tests you must use option above (of course you can just use this option always). The confirmation is a message "xxx checked" on status line (assuming you're running LLR with "-d" option for verbose output) and more parameters (L, M) on FFT status line. Non-Proth tests will also print "Gerbicz check requested, switching to PRP" message.

Note that Gerbicz test itself is not 100% bulletproof. First and few last iterations are not covered by Gerbicz check, only fast DC can catch errors at these places. But if your computer is stable and you've never seen a Gerbicz error in your testing, it's safe to consider that everything went fine.

Also, no check files are created, but if I understood correctly, those are only required for doublechecking?

Yes.
7) Message boards : Generalized Fermat Prime Search : Guessing the future of GFN-22 and DYFL (Message 147378)
Posted 13 days ago by stream
So, my question is do I run GFN-22 and/or DYFL for each card?

Yes please. As Mike noticed, both GFN-22 and DYFL must be tested because they're using different transforms.

If you're familiar with command line, it may be simpler to run tests manually, using, for example, candidates from current leading edges:

188626^4194304+1
925078^4194304+1

No need to run full test - after 2-3 minutes, Genefer will print "estimated time for ...". Write down the time, you can abort test at this point. I found one DYFL task in your results, Genefer' estimate was 54 hours and real runtime was 55 hours. Such precision will be enough.

If you're not familiar with command line, you can run tasks in Boinc and abort them after 5 minutes. We will see estimated runtime in stderr output of your tasks.
8) Message boards : Generalized Fermat Prime Search : Guessing the future of GFN-22 and DYFL (Message 147362)
Posted 14 days ago by stream
As to your question #1, from actual sieve job stats near your range, 800P at 1.5 candidates removed per P = 1200 candidates removed per day, not your 6055.

Manual sieving stats are rescaled to 400M sieving range. Sieving was started on 400M range and lately resieved to 2G, but Jim decided to keep all graph and stats in "old style" to simplify coding.

1200 candidates removed in 400M range are equal to 6000 candidates removed in 2G range. Your numbers matches my numbers exactly.

As to your question #2, your usable range of 245,000 is way too small.

As any prediction, it may be wrong, but it's based on facts about our throughput on each GFN project.

I recalculated predictions using current data.

2019-10-20, GFN-22 leading edge was 159180.
2021-01-04, GFN-22 leading edge is 188590

For more then a year. 'b' was advanced only by 29410 !

The prediction model is exponential, it considers that throughput in every year will be faster by 30% then previous one. After applying the formula, we'll get that in next 5 years leading edge of GFN-22 will be advanced by 285,5K - it's a bit better then our previous estimation of 245K, but not much. Expected leading edge in 2026 will be 474K. (This is mostly an answer for first post in this thread - GFN-22 is still on a looong way to meet DYFL).

Forget about DYFL?
DYFL is already to 925,000 for GFN22. And if a World record GIMP is found, DYFL probably will be bumped. So a much more reasonable 5 year range is 2,000,000.

Well... You're partially correct here.

You're absolutely wrong about "bumping". It's not working this way. It does not matter how far we bump starting point. We can start from anywhere, it'll not change number of usable candidates. What matter is how many candidates we test per year (and how far 'b' advances "naturally", by removing tested candidates).

You're right about... that we really forgot about DYFL! Candidates tested by DYFL were not included in our calculation of "usable ranges", although these two numbers should be summed up.

A prediction on DYFL is much better then on GFN-22. It may be advanced by 404K in 5 years. Summing this usable range with 285,5K from main search and rescaling number of factors to this sum, we'll have much better results - your system removes 2,09 usable candidates per day.

Now I'm asking once again: what are runtimes of real GFN-22/DYFL tasks on your GPUs? When I'll know runtimes, I can calculate how efficient sieve will be and how far it should go to stay efficient in your setup.
9) Message boards : Problems and Help : Can't figure out why CPU isn't being used 100% (Message 147355)
Posted 14 days ago by stream
If the temperature reading on the GTX 980 (64C) is anywhere close to correct, then heating is unlikely to be the culprit here.


why? cpu and gpu temps aren't linked.


An overheating CPU tends to stress the system and tick up heat everywhere. 64C is fairly cool on a crunching GTX 980 in general, and especially in a dual-GPU set up. An overheating CPU should raise the ambient temps enough to push that GPU over 70C when it is crunching GFN.


A fan/radiator which fall down from CPU is a simplest example when CPU will be immediately exposed to huge local overheating and throttled down, not affecting rest of the system. An improperly mounted radiator (e.g. with one mounting leg broken, or mounted awry - without contact with CPU cover) will lead to same effect.
10) Message boards : Generalized Fermat Prime Search : Guessing the future of GFN-22 and DYFL (Message 147353)
Posted 14 days ago by stream
What is sieving speed of your GPU (P/day) ?


With my 2 1080s and 2060, I was doing 800 P per day for n=22 manual sieving.

At a removal rate of 1.5 candidates per P, I was removing 1200 candidates per day.

OK. You're sieving 800 P/day. You see that lot of factors were found.

Question #1. How many of these factors are really removing a candidate (i.e. candidate wasn't removed earlier by smaller factors)?

Yves has formulas for everything related to GFN. He also has a formula to calculate number of candidates left at given sieving depth and range. Current GFN-22 sieving depth is 1100000P and range is 2G. How many candidates will be removed between 1100000P and 1100000+800P ? Put both depths to formula and find a difference. The answer is (you have to trust my word) 6055.

Question #2. How many of these 6055 factors are useful to us?

There is a problem with candidates located too far from our current position in search. Sieving can find these factors "for free", up to 2G, but why - if we'll need, for example, 100 years to reach this range?

So we use 5 years prediction for "usable" range, based on progress for few last years. And the sad truth is that prediction (advance of 'b') for GFN-22 is only 245000!

You removed 6055 from 2G range. How may candidates are within 245K range?

6055 * 245000 / 2000000000 = 0,7417375

Multiply by two due to DC tasks. So, your whole day of sieving on 3 GPUs saved only 1,5 useful (within next 5 years) tasks.

What is duration of real tasks on these GPUs?


Next 10 posts
[Return to PrimeGrid main page]
DNS Powered by DNSEXIT.COM
Copyright © 2005 - 2021 Rytis Slatkevičius (contact) and PrimeGrid community. Server load 4.24, 2.80, 2.12
Generated 19 Jan 2021 | 0:52:15 UTC