## Other

drummers-lowrise

Message boards : Generalized Fermat Prime Search : First *megaprime* in GFN16 (or GFN15) series

 Subscribe SortOldest firstNewest firstHighest rated posts first
Author Message
JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127278 - Posted: 21 Feb 2019 | 21:28:04 UTC

First megaprime in GFN16 (or GFN15) series

Would anyone find it interesting to locate the first megaprime for GFN16?

The first megaprime for GFN17 through GFN20 is known. Clearly, for lower exponents, a much higher b value (base) is needed to reach the mega level.

For GFN16, we need b > 10^(999999/65536) = 1814570322693369.9

For GFN15, we need b > 10^(999999/32768) = 3292665455999520712131951278258.6

and so on.

With so huge b values, you cannot use Genefer, but it is possible to do a PRP test (and after that a deterministic test) with OpenPFGW. It is not going to be the fastest way to find a megaprime, of course, but would it be interesting?

There is going to be a tremendous number of GFN16 primes (Yves Gallot's statistic says 310'000 if I am correct) with exactly 1'000'000 digits before we would (theoretically) arrive at 1'000'001 digits.

/JeppeSN

Addition: As a test case, if you use switch -q"1814570322693370^(2^16)+1" with OpenPFGW, you should get a result like:

1814570322693370^(2^16)+1 is composite: RES64: [AEFE572D827EB01D]

out of the PRP test, if my computer behaved.

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127287 - Posted: 22 Feb 2019 | 0:13:28 UTC - in response to Message 127278.

First megaprime in GFN16 (or GFN15) series

Would anyone find it interesting to locate the first megaprime for GFN16?

The first megaprime for GFN17 through GFN20 is known. Clearly, for lower exponents, a much higher b value (base) is needed to reach the mega level.

For GFN16, we need b > 10^(999999/65536) = 1814570322693369.9

For GFN15, we need b > 10^(999999/32768) = 3292665455999520712131951278258.6

and so on.

With so huge b values, you cannot use Genefer, but it is possible to do a PRP test (and after that a deterministic test) with OpenPFGW. It is not going to be the fastest way to find a megaprime, of course, but would it be interesting?

There is going to be a tremendous number of GFN16 primes (Yves Gallot's statistic says 310'000 if I am correct) with exactly 1'000'000 digits before we would (theoretically) arrive at 1'000'001 digits.

/JeppeSN

Addition: As a test case, if you use switch -q"1814570322693370^(2^16)+1" with OpenPFGW, you should get a result like:

1814570322693370^(2^16)+1 is composite: RES64: [AEFE572D827EB01D]

out of the PRP test, if my computer behaved.

That IS interesting. Cpu? I'm not familiar with OpenPFGW. We would be in lucky territory though, wouldn't we in terms of sucess?
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127290 - Posted: 22 Feb 2019 | 8:44:51 UTC - in response to Message 127287.

That IS interesting. Cpu? I'm not familiar with OpenPFGW. We would be in lucky territory though, wouldn't we in terms of sucess?

There are many details I do not know about…

Yes, it would be CPU.

Yes, we should eventually find a megaprime with exactly 1'000'000 digits, possibly the smallest known proven megaprime. We may need to test a hundred thousand workunits or so.

I do not know the PFGW running time for such numbers, on different hardware, or when running many tasks at the same time.

I do not know how PFGW is working together with BOINC, but I believe it has been used before (with PRPNet it is in use right now, e.g. FPS).

I do not know if you would want sieve first. The lazy (but slow?) way is to just let PFGW trial factor every candidate before PRP-testing it. If we were to keep it as a permanent project, i.e. continuing after the first find, then surely sieving should be done in advance.

/JeppeSN

Joined: 4 Oct 09
Posts: 63
ID: 47976
Credit: 16,622,115
RAC: 0

Message 127291 - Posted: 22 Feb 2019 | 9:20:50 UTC

sounds interesting :)
____________

dukebg
Volunteer tester

Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0

Message 127304 - Posted: 22 Feb 2019 | 16:24:53 UTC

I mostly wanted to see how long will this take, so I DC'd your result.

PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6] 1814570322693370^(2^16)+1 is composite: RES64: [AEFE572D827EB01D] (22069.7406s+0.0391s)

This was this host, but take note that (1) PFGW is single-threaded (and I didn't see anything about multithreading in the help); (2) the computer was doing a lot of heavy computations on other cores, so the run time is bloated.

I also started running P-1 on this number to see how fast that will be (and in vain hope to just wham you with the factor), just a measly B1=1e4, stage 1 didn't find factors and took about 8 minutes. I ran out of memory on stage 2 even though i put -maxmem=100 in the command line, must be a bug of some sort (using gpm-ecm 7.0.5-dev, svn rev.3027). I've been looking at it closely, it ran first some blocks under 100MB, but then went over and beyond. This is of course also not a very good test, I know that giving just 100MB for such a task is ridiculous, but again, this PC was under a heavy load and memory restrictions at the time.

The sieving – yeah, it has to be done no question, though I'm not sure off the top of my head if there's a suitable software ready immediately for such a big b. I'll maybe run P-1 again in a few hours and hopefully show you that the number is very likely to have a quite a small factor.

P.S. Also, I think this should be a separate thread.

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127308 - Posted: 22 Feb 2019 | 19:08:01 UTC - in response to Message 127304.

Good my result was correct :-)

I think you are right PFGW is single-threaded. But you could run four different candidates, say

1814570322693370^(2^16)+1

1814570322693372^(2^16)+1

1814570322693374^(2^16)+1

1814570322693376^(2^16)+1

at the same time, and see what happens to the running time.

Of course some of them may have a small factor. If you use -f0, it will not search for the small factors.

When you run the P-1 test, do you use -t switch? This will not try to factor the number itself, but it will use the fact that the number minus 1, i.e. 1814570322693370^(2^16), is easy to factor, and that can be used for a deterministic proof that the PRP (if it had been one) is in fact prime.

If you want to only search for factors, maybe -f -o is what you use.

Somehow, a sieve may be said up for 400'000 even b values starting from 1'814'570'322'693'370?

/JeppeSN

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13958
ID: 53948
Credit: 393,418,261
RAC: 198,590

Message 127358 - Posted: 23 Feb 2019 | 20:01:25 UTC

This discussion now has a home of its own!
____________
My lucky number is 75898524288+1

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127360 - Posted: 23 Feb 2019 | 21:12:07 UTC - in response to Message 127358.

This discussion now has a home of its own!

Thanks Mike. Any thoughts on this yourself?

____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127361 - Posted: 23 Feb 2019 | 21:12:52 UTC

Btw anyone got a link to OpenPFGW?
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127363 - Posted: 23 Feb 2019 | 21:30:06 UTC

Thanks for moving to a separate thread. I should have created a new thread in the first place.

Yves Gallot's stats page predicts 3.89 primes in this interval of length 800'000: bmin=1814570322693370; bmax=1814570323493370.

The first candidate does not appear to have small factors.

The second candidate is composite as well:

1814570322693372^(2^16)+1 is composite: RES64: [EEB64155F963E8B7]

/JeppeSN

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127364 - Posted: 23 Feb 2019 | 21:42:59 UTC - in response to Message 127363.

Yves Gallot's stats page predicts 3.89 primes in this interval of length 800'000: bmin=1814570322693370; bmax=1814570323493370.

Expected number of megaprimes of form GFN16 less that the smallest currently known megaprime (which is 191273*2^3321908 - 1): approx. 72000

(Compare with the 310000 primes I mentioned in the first post.)

/JeppeSN

Eudy Silva

Joined: 26 Aug 17
Posts: 2114
ID: 918937
Credit: 588,947,434
RAC: 351,026

Message 127369 - Posted: 24 Feb 2019 | 2:37:43 UTC

I tried 1814570322693376^(2^16)+1

C:\Users\Eudy\Desktop\pfgw_win_3.8.3>pfgw64.exe -q1814570322693376^^(2^^16)+1 -Cverbose -V PFGW Version 3.8.3.64BIT.20161203.Win_Dev [GWNUM 28.6] Generic modular reduction using generic reduction FMA3 FFT length 336K, Pass1=448, Pass2=768 on A 3321925-bit number 1814570322693376^(2^16)+1 is composite: RES64: [A79EF7F1C7E0CB69] (15163.0477s+0.0289s)

It took a bit more than 4 hours on an i7-6700@3.4GHz with 16 GB DDR4 2400 (but running @2133 MHz, mobo limitation :(
Is this acceptable ?
Or should have I used some other tricky command line paramenter(s) ?

____________

"Accidit in puncto, quod non contingit in anno."
Something that does not occur in a year may, perchance, happen in a moment.

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13958
ID: 53948
Credit: 393,418,261
RAC: 198,590

Message 127370 - Posted: 24 Feb 2019 | 4:46:57 UTC - in response to Message 127360.

This discussion now has a home of its own!

Thanks Mike. Any thoughts on this yourself?

Not really.
____________
My lucky number is 75898524288+1

dukebg
Volunteer tester

Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0

Message 127375 - Posted: 24 Feb 2019 | 8:53:10 UTC - in response to Message 127369.

Is this acceptable ?
Or should have I used some other tricky command line paramenter(s) ?

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127376 - Posted: 24 Feb 2019 | 9:25:25 UTC - in response to Message 127375.

Is this acceptable ?
Or should have I used some other tricky command line paramenter(s) ?

I agree. If we were to run this as a project, you should try running four candidate numbers (out of four different file folders, I think) at the same time, and see how that goes. /JeppeSN

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127377 - Posted: 24 Feb 2019 | 10:01:51 UTC - in response to Message 127376.

Is this acceptable ?
Or should have I used some other tricky command line paramenter(s) ?

I agree. If we were to run this as a project, you should try running four candidate numbers (out of four different file folders, I think) at the same time, and see how that goes. /JeppeSN

There would have to be a reservation list or something similar to ensure no duplication of work.
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127378 - Posted: 24 Feb 2019 | 10:22:34 UTC

I'm sieving this stuff. Please don't run anything big until it's done.

I set it up on range b_start=1814570322693370 to b_start+1,000,000, i.e. 500,000 candidates. This number was quickly reduced to 270,000, where sieving radio drops to 1 candidate per second. Well, it's still better then 4 hours with PFGW :)

I'll run this for a while but I wonder if could get below 250,000. Multiplying by 4 hours, it's still a huge amount of work.

Note: the sieving software is my own, CPU-only and slow, written when Jim and me bootstrapped "2G" manual sieving. Generic sieving software does not knows about special properties of factors of GFN numbers.

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127379 - Posted: 24 Feb 2019 | 10:34:23 UTC - in response to Message 127378.

I'm sieving this stuff. Please don't run anything big until it's done.

I set it up on range b_start=1814570322693370 to b_start+1,000,000, i.e. 500,000 candidates. This number was quickly reduced to 270,000, where sieving radio drops to 1 candidate per second. Well, it's still better then 4 hours with PFGW :)

I'll run this for a while but I wonder if could get below 250,000. Multiplying by 4 hours, it's still a huge amount of work.

Note: the sieving software is my own, CPU-only and slow, written when Jim and me bootstrapped "2G" manual sieving. Generic sieving software does not knows about special properties of factors of GFN numbers.

Great. Thanks Stream. I'll wait to hear so. 👍
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127381 - Posted: 24 Feb 2019 | 11:38:42 UTC - in response to Message 127377.

There would have to be a reservation list or something similar to ensure no duplication of work.

Yes, I think someone should set up a BOINC server or a PRPNet server. /JeppeSN

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127382 - Posted: 24 Feb 2019 | 11:53:31 UTC - in response to Message 127378.

Note: the sieving software is my own, CPU-only and slow, written when Jim and me bootstrapped "2G" manual sieving. Generic sieving software does not knows about special properties of factors of GFN numbers.

Thank you very much.

Odd factors of b^65536+1 always have the form 131072k+1. You are saying that your software uses that?

I forgot that PFGW can utilize that. You would use -f{131072}. So when using PFGW, I think we should always use either -f{131072} or -f0 to make sure PFGW does not do "idiot's factoring" which does not know about the form of the factors.

/JeppeSN

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127386 - Posted: 24 Feb 2019 | 12:55:04 UTC - in response to Message 127382.

Note: the sieving software is my own, CPU-only and slow, written when Jim and me bootstrapped "2G" manual sieving. Generic sieving software does not knows about special properties of factors of GFN numbers.

Thank you very much.

Odd factors of b^65536+1 always have the form 131072k+1. You are saying that your software uses that?

Yes it is. But it's still slow because it does traditional powmod() for each factor on all possible candidates in the loop. Even with all these common programmer's optimizations (bitmap storage, powmod() optimized for GFN which only squares).

Right now sieving depth reached 100G and about 247,000 candidates remains. I'll let it run for a while, checking removal ratio. It's still a huge amount of work for few enthusiasts.

BTW first few entries in the candidate table currently are (if somebody feels lucky :)

4 65536
10 65536
12 65536
22 65536
28 65536

They are "offsets", add bmin (1814570322693370) to them first.

I forgot to check for 1814570322693370 itself (which has offset of 0) but it's already proven composite.

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127387 - Posted: 24 Feb 2019 | 13:02:26 UTC - in response to Message 127386.

BTW first few entries in the candidate table currently are (if somebody feels lucky :)

4 65536
10 65536
12 65536
22 65536
28 65536

For the first of them, I found a factor already, 128312147969.

/JeppeSN

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127394 - Posted: 24 Feb 2019 | 18:00:58 UTC - in response to Message 127387.

I even found a factor of 1814570322693370^(2^16)+1, but it took longer:

1809916758589441
= 3452142255*2^19 + 1

/JeppeSN

Crun-chi
Volunteer tester

Joined: 25 Nov 09
Posts: 3208
ID: 50683
Credit: 135,132,479
RAC: 57,320

Message 127397 - Posted: 24 Feb 2019 | 20:37:48 UTC - in response to Message 127394.

I try to do P-1 on those candidate but it looks like that b is to high :)

____________
92*10^1439761-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127399 - Posted: 24 Feb 2019 | 22:18:50 UTC - in response to Message 127397.

I try to do P-1 on those candidate but it looks like that b is to high :)

We can do the P-1 test by hand, then. But maybe you just feed in the factors of b (which are easy enough to find), since their powers are also the factors of "P-1".

PARI/GP is my friend.

See how 1109787959040393218^4096 + 1 was P-1 tested with PFGW; its b value is higher.

I will investigate that.

/JeppeSN

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127404 - Posted: 25 Feb 2019 | 5:52:17 UTC

Current sieving depth: 1.06T, candidates left: 227000

You can see how slow this type of sieving (with high b) is: we've just passed 1T but our standard manual sieving tasks are measured in 'P's.

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127405 - Posted: 25 Feb 2019 | 6:40:07 UTC - in response to Message 127404.

Current sieving depth: 1.06T, candidates left: 227000

You can see how slow this type of sieving (with high b) is: we've just passed 1T but our standard manual sieving tasks are measured in 'P's.

You removed 247'000 - 227'000 = 20'000 candidates since your previous post, then. That is nice.

It would be a huge effort to find the first prime. However, it should show up long before your candidates are exhausted, i.e. before bMin + 1'000'000.

/JeppeSN

Crun-chi
Volunteer tester

Joined: 25 Nov 09
Posts: 3208
ID: 50683
Credit: 135,132,479
RAC: 57,320

Message 127406 - Posted: 25 Feb 2019 | 6:59:38 UTC - in response to Message 127405.

Can LLR be used in processing of those candidates?
____________
92*10^1439761-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127408 - Posted: 25 Feb 2019 | 9:54:09 UTC - in response to Message 127406.

Can LLR be used in processing of those candidates?

Excellent question! Its answer appears to be yes:

> In this new version, the base b can now be an arbitrary large integer
> (however restricted to 64 bits for fixed b formats). This is especially
> useful while testing Generalized Fermat numbers.

The b values we discuss for GFN16-mega are 51-bit.

I will test:

.\cllr64.exe -q'1814570322693370^65536+1'

(LLR was not happy with 1814570322693370^(2^16)+1, so we say 65536 instead.)

/JeppeSN

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127413 - Posted: 25 Feb 2019 | 13:38:13 UTC - in response to Message 127405.

Current sieving depth: 1.06T, candidates left: 227000

You can see how slow this type of sieving (with high b) is: we've just passed 1T but our standard manual sieving tasks are measured in 'P's.

You removed 247'000 - 227'000 = 20'000 candidates since your previous post, then. That is nice.

It would be a huge effort to find the first prime. However, it should show up long before your candidates are exhausted, i.e. before bMin + 1'000'000.

In next few days, I'll try to make GPU version of this sieve using rogue's mtsieve framework. It has all necessary small bricks which I can use, including GPU mulmod/powmod with necessary precision. I hope we can squeeze another few thousands of candidates out of this. Considering that, even if we can lower number of candidates to 200'000, it still will require 200'000*4/24/365 = 91 year of computing on single core (not counting double-checking), one week delay will not do much harm :)

I could host this on my Boinc server. But this project definitely needs lot of participants or at least few big whales with tens and hundreds of hosts, to be able to complete in reasonable time (yes, there is a probability that we'll find this prime in first hundred of candidates, but let's hope for best and be prepared for worst).

dukebg
Volunteer tester

Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0

Message 127414 - Posted: 25 Feb 2019 | 14:27:16 UTC - in response to Message 127308.

Of course some of them may have a small factor. If you use -f0, it will not search for the small factors.

When you run the P-1 test, do you use -t switch? This will not try to factor the number itself, but it will use the fact that the number minus 1, i.e. 1814570322693370^(2^16), is easy to factor, and that can be used for a deterministic proof that the PRP (if it had been one) is in fact prime.

If you want to only search for factors, maybe -f -o is what you use.

/JeppeSN

I used GMP-ECM for P-1. From your comment I assumed that PFGW has P-1 too, but alas, it doesn't. -t is the N-1 deterministic primality proof based on factorization of N-1, which we obviously have, yes. The software also has the N+1 and the combined tests.

I'm not sure if the deterministic test is longer than PRP or not here. Won't be able to run right now, but just from starting them and looking at the iteration counts, seems to be the same? (Just in case, I provided the helper file with the -h option, after "manually" factoring the b).

The GMP-ECM does have a -go command line switch to tell the known factors of P-1, but in my experience it never made a difference (or I was using it wrong, dunno).

Crun-chi
Volunteer tester

Joined: 25 Nov 09
Posts: 3208
ID: 50683
Credit: 135,132,479
RAC: 57,320

Message 127415 - Posted: 25 Feb 2019 | 15:20:33 UTC - in response to Message 127414.

Why forcing PFGW?
In any way , and for needs of this project LLR is faster : so dont use PFGW.

____________
92*10^1439761-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127416 - Posted: 25 Feb 2019 | 15:36:30 UTC - in response to Message 127414.

I used GMP-ECM for P-1. From your comment I assumed that PFGW has P-1 too, but alas, it doesn't. -t is the N-1 deterministic primality proof based on factorization of N-1, which we obviously have, yes. [...]

All right, I was confusing the factorization algorithm "P-1" and the primality test "N-1". /JeppeSN

mackerel
Volunteer tester

Joined: 2 Oct 08
Posts: 2639
ID: 29980
Credit: 568,393,769
RAC: 1,834

Message 127418 - Posted: 25 Feb 2019 | 16:28:00 UTC - in response to Message 127415.

Has anyone done like for like performance comparison of LLR vs PFGW?

I vaguely recall that FFT size is related to N, and if LLR is used, the FFT may be too small to effectively make use of multiple threads. This would need testing.

dukebg
Volunteer tester

Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0

Message 127419 - Posted: 25 Feb 2019 | 16:33:56 UTC - in response to Message 127418.

Has anyone done like for like performance comparison of LLR vs PFGW?

I vaguely recall that FFT size is related to N, and if LLR is used, the FFT may be too small to effectively make use of multiple threads. This would need testing.

>cllr64.exe -q"1814570322693380^65536+1" -d Base factorized as : 2^2*5*7*12961216590667 Base prime factor(s) taken : 12961216590667 Resuming N-1 prime test of 1814570322693380^65536+1 at bit 2 [0.00%] Using generic reduction FMA3 FFT length 336K, Pass1=448, Pass2=768, a = 3

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13958
ID: 53948
Credit: 393,418,261
RAC: 198,590

Message 127420 - Posted: 25 Feb 2019 | 17:05:48 UTC - in response to Message 127418.

Has anyone done like for like performance comparison of LLR vs PFGW?

llr64 -d -t4 -q"1814570322693374^65536+1"

2.2 hours

llr64 -d -q"1814570322693374^65536+1"

5.5 hours

pfgw64 -V -q"1814570322693374^65536+1"

5.6 hours

That's running the PRP test in PFGW, which is how I would recommend you use PFGW.

Essentially they're the same speed, except, of course, that you can use multi-threading on LLR.

Note that this was running ONE instance of the program on a quad-core Haswell i5. On the single thread tests, if you were running four tests in parallel, you might see a decrease in performance due to memory usage. You would therefore want to run LLR to take advantage of multi-threading.

Also, the necessary BOINC wrapper already exists for LLR. I don't see any reason why you would want to use PFGW.

P.S. Although nobody has asked, for the record, PrimeGrid has no interest in this search. Although you're free to use our forums, this isn't something that I expect will be running on PrimeGrid's servers.
____________
My lucky number is 75898524288+1

mackerel
Volunteer tester

Joined: 2 Oct 08
Posts: 2639
ID: 29980
Credit: 568,393,769
RAC: 1,834

Message 127421 - Posted: 25 Feb 2019 | 17:08:47 UTC - in response to Message 127419.

336k FFT. By my estimates I think scaling to 2 threads might be ok, but not so great above that. For comparison, I only have one complete MEGA unit in history and that is 256k FFT.

When I said earlier that I thought FFT size was related to N, I now recall that was in relation to genefer. I don't know how PFGW/LLR would behave.

mackerel
Volunteer tester

Joined: 2 Oct 08
Posts: 2639
ID: 29980
Credit: 568,393,769
RAC: 1,834

Message 127422 - Posted: 25 Feb 2019 | 17:15:51 UTC - in response to Message 127420.

Note that this was running ONE instance of the program on a quad-core Haswell i5. On the single thread tests, if you were running four tests in parallel, you might see a decrease in performance due to memory usage. You would therefore want to run LLR to take advantage of multi-threading.

For most Intel CPUs, you'd want 2 cores worth of cache per task to not need to hit ram. Could you also do a -t2 for comparison?

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13958
ID: 53948
Credit: 393,418,261
RAC: 198,590

Message 127424 - Posted: 25 Feb 2019 | 19:02:50 UTC - in response to Message 127422.

Note that this was running ONE instance of the program on a quad-core Haswell i5. On the single thread tests, if you were running four tests in parallel, you might see a decrease in performance due to memory usage. You would therefore want to run LLR to take advantage of multi-threading.

For most Intel CPUs, you'd want 2 cores worth of cache per task to not need to hit ram. Could you also do a -t2 for comparison?

3.3 hours
____________
My lucky number is 75898524288+1

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127425 - Posted: 25 Feb 2019 | 19:09:10 UTC

LLR works well and even produced same residue as OpenPFGW (see first post):

Base factorized as : 2*5*11*199*1877*44163529 Base prime factor(s) taken : 44163529 Starting N-1 prime test of 1814570322693370^65536+1 Using generic reduction FMA3 FFT length 336K, Pass1=448, Pass2=768, a = 3 1814570322693370^65536+1 is not prime. RES64: AEFE572D827EB01D. OLD64: 0CFB0588877C1053 Time : 28416.130 sec.

(Don't look at time, on this PC it had only some leftovers after many instances of CPU and GPU Genefer)

mackerel
Volunteer tester

Joined: 2 Oct 08
Posts: 2639
ID: 29980
Credit: 568,393,769
RAC: 1,834

Message 127427 - Posted: 25 Feb 2019 | 19:53:54 UTC - in response to Message 127424.

Based on Michael's results, I'd estimates the units per day for that CPU as:
1x -t4 = 10.9
2x -t2 = 14.5
3x -t1 = 13.1 assuming 8MB cache CPU like i7, the i5 is only 6MB so will be worse than this (ram limited)
4x -t1 would be limited by ram speed

Assumes the clock is the same in all cases.

dukebg
Volunteer tester

Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0

Message 127435 - Posted: 26 Feb 2019 | 12:23:26 UTC - in response to Message 127420.

That's running the PRP test in PFGW, which is how I would recommend you use PFGW.

Why do you not recomment running the deterministic (N-1) test in PFGW?

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13958
ID: 53948
Credit: 393,418,261
RAC: 198,590

Message 127436 - Posted: 26 Feb 2019 | 12:32:05 UTC - in response to Message 127435.

That's running the PRP test in PFGW, which is how I would recommend you use PFGW.

Why do you not recomment running the deterministic (N-1) test in PFGW?

1) PFGW doesn't checkpoint when running deterministic tests.
2) Sometimes (not always) PRP tests run quicker, so it is beneficial to run the PRP test on the big search and only run the deterministic test on PRPs.

(#2 also applies to GeneferOCL, which can also do deterministic tests.)

I don't recommend using PFGW, however. LLR is a better choice because of multi-threading and an already existing BOINC wrapper.
____________
My lucky number is 75898524288+1

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127452 - Posted: 26 Feb 2019 | 19:15:33 UTC

Good news everyone. I found that hacked version of our manual sieving GPU app can work with huge b values. But it does something strange. It could only find factors above 1,8P. I did a minimal range of 1P-2P and it produced nothing first. I thought that my assumptions for this hack were wrong and moved to other things. But the app kept running. Later I've occasionally switched to this window and suddenly seen factors...

To be exact, the minimum factor it found was

1814652271329281 | 1814570323409552^65536+1

All factors are correct, I'm checking them. I don't know what's behind this and why it's not working at lower ranges. Although I've ported this app, most of math stuff in it is a black magic to me. I even cannot be sure that it's not missing some factors, there is no way to verify. Anyway, this will allow us to sieve much deeper and remove many thousands candidates.

The bad new is that it's still an open question how to sieve up to 1,8P; it's too slow on CPU but there are lot of candidates waiting to be removed from this range.

Rafael
Volunteer tester

Joined: 22 Oct 14
Posts: 909
ID: 370496
Credit: 531,793,905
RAC: 407,603

Message 127458 - Posted: 26 Feb 2019 | 19:24:44 UTC - in response to Message 127452.

Good news everyone. I found that hacked version of our manual sieving GPU app can work with huge b values. But it does something strange. It could only find factors above 1,8P. I did a minimal range of 1P-2P and it produced nothing first. I thought that my assumptions for this hack were wrong and moved to other things. But the app kept running. Later I've occasionally switched to this window and suddenly seen factors...

To be exact, the minimum factor it found was

1814652271329281 | 1814570323409552^65536+1

All factors are correct, I'm checking them. I don't know what's behind this and why it's not working at lower ranges. Although I've ported this app, most of math stuff in it is a black magic to me. I even cannot be sure that it's not missing some factors, there is no way to verify. Anyway, this will allow us to sieve much deeper and remove many thousands candidates.

The bad new is that it's still an open question how to sieve up to 1,8P; it's too slow on CPU but there are lot of candidates waiting to be removed from this range.

Jim said small sieving had to be done with specialized software back when we restarted 15/16 sieve to accomodate for the new OCL app, so I'm pretty sure that behaviour is expected, though I have no clue as to why.

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127463 - Posted: 26 Feb 2019 | 20:32:23 UTC - in response to Message 127458.

Good news everyone. I found that hacked version of our manual sieving GPU app can work with huge b values. But it does something strange. It could only find factors above 1,8P. I did a minimal range of 1P-2P and it produced nothing first. I thought that my assumptions for this hack were wrong and moved to other things. But the app kept running. Later I've occasionally switched to this window and suddenly seen factors...

To be exact, the minimum factor it found was

1814652271329281 | 1814570323409552^65536+1

All factors are correct, I'm checking them. I don't know what's behind this and why it's not working at lower ranges. Although I've ported this app, most of math stuff in it is a black magic to me. I even cannot be sure that it's not missing some factors, there is no way to verify. Anyway, this will allow us to sieve much deeper and remove many thousands candidates.

The bad new is that it's still an open question how to sieve up to 1,8P; it's too slow on CPU but there are lot of candidates waiting to be removed from this range.

Jim said small sieving had to be done with specialized software back when we restarted 15/16 sieve to accomodate for the new OCL app, so I'm pretty sure that behaviour is expected, though I have no clue as to why.

No, this is a different case. The small sieving which Jim mentioned was indeed small, comparing to current situation. I wrote OCL version of sieving app and worked together with Jim on restarting 15/16 sieve, so I'm familiar with this topic a bit :) We had to sieve very small range with this special software - just to work around a bug in AthGfn64 (CPU sieving software), then switched to AthGfn64 and sieved until GPU app started to work stable (it's main problem, really, was an overflow caused by huge amount of candidates removed by small factors).

I'm using this special software right now, but it's sloooow. It'll take a while until it reach 1,8P.

vaughan

Joined: 11 Aug 05
Posts: 323
ID: 224
Credit: 10,560,409,644
RAC: 7,477,755

Message 127464 - Posted: 26 Feb 2019 | 21:11:50 UTC - in response to Message 127463.

Stream is this something we can help you with after TdP concludes?

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127472 - Posted: 26 Feb 2019 | 23:09:44 UTC - in response to Message 127452.

Good news everyone. I found that hacked version of our manual sieving GPU app can work with huge b values. But it does something strange. It could only find factors above 1,8P. I did a minimal range of 1P-2P and it produced nothing first. I thought that my assumptions for this hack were wrong and moved to other things. But the app kept running. Later I've occasionally switched to this window and suddenly seen factors...

To be exact, the minimum factor it found was

1814652271329281 | 1814570323409552^65536+1

All factors are correct, I'm checking them. I don't know what's behind this and why it's not working at lower ranges. Although I've ported this app, most of math stuff in it is a black magic to me. I even cannot be sure that it's not missing some factors, there is no way to verify. Anyway, this will allow us to sieve much deeper and remove many thousands candidates.

The bad new is that it's still an open question how to sieve up to 1,8P; it's too slow on CPU but there are lot of candidates waiting to be removed from this range.

It looks like it finds only factors that are greater than b (or greater than bMin or similar)?

(Not related: When I searched for the first factor of the initial number, see my post "Message 127394 - Posted: 24 Feb 2019 | 18:00:58 UTC", I wondered why the smallest factor 1809916758589441 was quite close to the b value 1814570322693370, both near "1.8 Peta", but I am sure it is just a coincidence.)

/JeppeSN

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127488 - Posted: 27 Feb 2019 | 5:43:01 UTC - in response to Message 127464.

Stream is this something we can help you with after TdP concludes?

Not yet, later we may have to do manual sieving on GPU, using modified OCL sieving program. But I cannot say for sure, I need to deal with a problem of sieving lower range (up to 1,8P) fist - most probably write a GPU-assisted program to do this. Then I'll re-evaluate optimal sieving depth based on number of remaining candidates (I'm running GPU sieving myself, and number of accepted factors, which removed something, already falling down very quickly).

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127557 - Posted: 1 Mar 2019 | 11:38:41 UTC

I wonder how many peoples with significant computing power (e.g. >20 cores total) are interested in this project. Required computing power still look big, and I need to make some estimations about optimal sieving ratio.

Currently we have 190'800 candidates to test. This number is decreasing slowly thanks to GPU sieving at high area, but I'm still working on the problem of sieving in middle area between 0.008P (current CPU sieving progress) and 1.815P (start of GPU sieving). I finally wrote a GPU-assisted sieving program, it's working fine in test environment (software OpenCL) but crashes NVIDIA drivers/compiler... So I still have work to do, may be try other versions of drivers... or just find an AMD card :)

Rafael
Volunteer tester

Joined: 22 Oct 14
Posts: 909
ID: 370496
Credit: 531,793,905
RAC: 407,603

Message 127559 - Posted: 1 Mar 2019 | 12:02:42 UTC - in response to Message 127557.

I wonder how many peoples with significant computing power (e.g. >20 cores total) are interested in this project. Required computing power still look big, and I need to make some estimations about optimal sieving ratio.

Currently we have 190'800 candidates to test. This number is decreasing slowly thanks to GPU sieving at high area, but I'm still working on the problem of sieving in middle area between 0.008P (current CPU sieving progress) and 1.815P (start of GPU sieving). I finally wrote a GPU-assisted sieving program, it's working fine in test environment (software OpenCL) but crashes NVIDIA drivers/compiler... So I still have work to do, may be try other versions of drivers... or just find an AMD card :)

Wouldn't it be easier to Run a couple P on the GPU and remove those candidates to then have less stuff to sieve on the middle area? If I understand correctly, it doesn't matter how many factors you have on the GPU side, but it does on the CPU, so maybe that's a way to cut the CPU portion of the sieve.

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127561 - Posted: 1 Mar 2019 | 12:25:25 UTC - in response to Message 127559.

I wonder how many peoples with significant computing power (e.g. >20 cores total) are interested in this project. Required computing power still look big, and I need to make some estimations about optimal sieving ratio.

Currently we have 190'800 candidates to test. This number is decreasing slowly thanks to GPU sieving at high area, but I'm still working on the problem of sieving in middle area between 0.008P (current CPU sieving progress) and 1.815P (start of GPU sieving). I finally wrote a GPU-assisted sieving program, it's working fine in test environment (software OpenCL) but crashes NVIDIA drivers/compiler... So I still have work to do, may be try other versions of drivers... or just find an AMD card :)

Wouldn't it be easier to Run a couple P on the GPU and remove those candidates to then have less stuff to sieve on the middle area? If I understand correctly, it doesn't matter how many factors you have on the GPU side, but it does on the CPU, so maybe that's a way to cut the CPU portion of the sieve.

Of course it's already working this way. But percentage of removed factors is very small and does not affect speed of CPU sieving significantly (only 2K out of 180K are removed each day now).

Middle area is more interesting because it should contain more factors.

dukebg
Volunteer tester

Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0

Message 127564 - Posted: 1 Mar 2019 | 14:23:31 UTC

Maybe someone else can run it on their AMD card?

Most likely someone else has something more powerful, but I can try it on my mediocre Radeon HD 6950 (Cayman)

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127566 - Posted: 1 Mar 2019 | 14:36:09 UTC - in response to Message 127564.

Maybe someone else can run it on their AMD card?

Most likely someone else has something more powerful, but I can try it on my mediocre Radeon HD 6950 (Cayman)

R9 295 any use?
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Crun-chi
Volunteer tester

Joined: 25 Nov 09
Posts: 3208
ID: 50683
Credit: 135,132,479
RAC: 57,320

Message 127567 - Posted: 1 Mar 2019 | 14:47:58 UTC - in response to Message 127566.

____________
92*10^1439761-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127568 - Posted: 1 Mar 2019 | 15:28:39 UTC - in response to Message 127557.

I wonder how many peoples with significant computing power (e.g. >20 cores total) are interested in this project. Required computing power still look big, and I need to make some estimations about optimal sieving ratio.

Currently we have 190'800 candidates to test. This number is decreasing slowly thanks to GPU sieving at high area, but I'm still working on the problem of sieving in middle area between 0.008P (current CPU sieving progress) and 1.815P (start of GPU sieving). I finally wrote a GPU-assisted sieving program, it's working fine in test environment (software OpenCL) but crashes NVIDIA drivers/compiler... So I still have work to do, may be try other versions of drivers... or just find an AMD card :)

One anyway, >50 cores 😉
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

Joined: 4 Oct 09
Posts: 63
ID: 47976
Credit: 16,622,115
RAC: 0

Message 127574 - Posted: 1 Mar 2019 | 18:46:31 UTC

only 15 cores here...atm sieving at GCW.
____________

TimT

Joined: 2 Dec 11
Posts: 501
ID: 121414
Credit: 2,484,701,861
RAC: 1,777,665

Message 127642 - Posted: 4 Mar 2019 | 11:55:03 UTC - in response to Message 127574.

I'd throw a machine at this assuming I can figure out what to do (dual xeon 16 cores, possibly two of these) -- at least until the summer heat forces me to turn it off

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127658 - Posted: 4 Mar 2019 | 19:24:19 UTC

Status update.

My GPU sieving program is working, at last. I isolated the problem in NVIDIA compiler (it failed to unroll the loop of 16 iterations) and worked around it. Even almost non-optimized, it working with good speed of 0,25 P/Day, so I could sieve middle area (up to 1,8 P) is a reasonable time. CPU version of this program is also not bad, it's working much faster then my original software and gives nice additional boost of 0,008P * 6 cores (and I could add more cores, if necessary).

There are 168'000 candidates left. Time to start setting up the server.

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127659 - Posted: 4 Mar 2019 | 19:51:01 UTC - in response to Message 127658.

stream, thank you for picking up my loose idea from the first post and realizing it, even when it is going to be a looong search (unless luck prevails). /JeppeSN

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127661 - Posted: 4 Mar 2019 | 21:12:41 UTC - in response to Message 127659.

stream, thank you for picking up my loose idea from the first post and realizing it, even when it is going to be a looong search (unless luck prevails). /JeppeSN

168'000 candidates * 4 hours / 24 / 365 = 76,7 years on single core. I think it can be squeezed more, to 160'000. Give it 100 ideal cores and one pass will be done in 9 months. Not considering a luck and prediction about 3,89 primes in this range.

The GFN server currently have 543 hosts registered (each of them has many cores) but it's hard to predict how many of them will be used in this project.

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127663 - Posted: 4 Mar 2019 | 21:24:33 UTC - in response to Message 127661.

stream, thank you for picking up my loose idea from the first post and realizing it, even when it is going to be a looong search (unless luck prevails). /JeppeSN

168'000 candidates * 4 hours / 24 / 365 = 76,7 years on single core. I think it can be squeezed more, to 160'000. Give it 100 ideal cores and one pass will be done in 9 months. Not considering a luck and prediction about 3,89 primes in this range.

The GFN server currently have 543 hosts registered (each of them has many cores) but it's hard to predict how many of them will be used in this project.

Stream is that based on ht on or off? 4 hours I mean
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127674 - Posted: 5 Mar 2019 | 6:32:56 UTC - in response to Message 127663.

stream, thank you for picking up my loose idea from the first post and realizing it, even when it is going to be a looong search (unless luck prevails). /JeppeSN

168'000 candidates * 4 hours / 24 / 365 = 76,7 years on single core. I think it can be squeezed more, to 160'000. Give it 100 ideal cores and one pass will be done in 9 months. Not considering a luck and prediction about 3,89 primes in this range.

The GFN server currently have 543 hosts registered (each of them has many cores) but it's hard to predict how many of them will be used in this project.

Stream is that based on ht on or off? 4 hours I mean

Did you mean mt (LLR multi-threading?) instead of ht (hyper-threading)? It'll be LLR project with properties very close to MEGA search, and ht is not useful here.

4 hours is a time from this post, it was a single instance of the program on one core. Of course every host is different so time will vary. But usual LLR limitations will apply, i.e. running multiple workunits in parallel will hit memory throughput limit. Like in other PG LLR projects, you have to find out what's best for your hosts - how many LLR threads to use and how many instances to run. For example, Mike did a nice job testing different thread count on his PC:
llr64 -d -q"1814570322693374^65536+1" : 5.5 hours llr64 -d -t2 -q"1814570322693374^65536+1" : 3.3 hours llr64 -d -t4 -q"1814570322693374^65536+1" : 2.2 hours

Unfortunately it's not clear how many instances of LLR were run with 1 and 2 threads, increased memory concurrency will decrease performance. Best configuration may be either 2 instances * 2 cores either 1 instance * 4 cores.

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127813 - Posted: 7 Mar 2019 | 17:33:45 UTC - in response to Message 127674.

[quote]
Stream is that based on ht on or off? 4 hours I mean

Did you mean mt (LLR multi-threading?) instead of ht (hyper-threading)? It'll be LLR project with properties very close to MEGA search, and ht is not useful here.

4 hours is a time from this post, it was a single instance of the program on one core. Of course every host is different so time will vary. But usual LLR limitations will apply, i.e. running multiple workunits in parallel will hit memory throughput limit. Like in other PG LLR projects, you have to find out what's best for your hosts - how many LLR threads to use and how many instances to run. For example, Mike did a nice job testing different thread count on his PC:
llr64 -d -q"1814570322693374^65536+1" : 5.5 hours llr64 -d -t2 -q"1814570322693374^65536+1" : 3.3 hours llr64 -d -t4 -q"1814570322693374^65536+1" : 2.2 hours

Unfortunately it's not clear how many instances of LLR were run with 1 and 2 threads, increased memory concurrency will decrease performance. Best configuration may be either 2 instances * 2 cores either 1 instance * 4 cores.

Sorry Stream I seemed to have missed the fact we are going to use LLR.
i thought it was single core only.

If it's LLR the question no longer necessary.

____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127848 - Posted: 9 Mar 2019 | 10:36:19 UTC

I think we can start project soon after end of PG challenge. The server is ready and tested, all it need is 3-4 more days of sieving.

Sergey Kovalchuk

Joined: 29 Sep 15
Posts: 6
ID: 422666
Credit: 38,991,522
RAC: 0

Message 127849 - Posted: 9 Mar 2019 | 10:49:27 UTC - in response to Message 127848.

The server is ready and tested

on which server will these tasks be run?

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127850 - Posted: 9 Mar 2019 | 11:20:04 UTC - in response to Message 127848.

I think we can start project soon after end of PG challenge. The server is ready and tested, all it need is 3-4 more days of sieving.

Cool! I tested one on 6 threads, just over an hour ;)
On a Intel(R) Core(TM) i7-5930K CPU @ 3.50GHz
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127853 - Posted: 9 Mar 2019 | 14:05:53 UTC - in response to Message 127849.

The server is ready and tested

on which server will these tasks be run?

On my "Private GFN server", like all other experimental GFN-13/14 stuff.

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127898 - Posted: 11 Mar 2019 | 12:28:54 UTC - in response to Message 127848.

I think we can start project soon after end of PG challenge. The server is ready and tested, all it need is 3-4 more days of sieving.

Stream could you give us 24 hours heads up before you go live, so we can prepare and finish up cpu tasks in progress.

Thanks Rob.

____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127900 - Posted: 11 Mar 2019 | 12:58:36 UTC - in response to Message 127850.

I think we can start project soon after end of PG challenge. The server is ready and tested, all it need is 3-4 more days of sieving.

Cool! I tested one on 6 threads, just over an hour ;)
On a Intel(R) Core(TM) i7-5930K CPU @ 3.50GHz

Sorry not sure how/what happened. Tested again and it is in fact 2.24 hours.

____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127915 - Posted: 12 Mar 2019 | 6:19:30 UTC - in response to Message 127898.

I think we can start project soon after end of PG challenge. The server is ready and tested, all it need is 3-4 more days of sieving.

Stream could you give us 24 hours heads up before you go live, so we can prepare and finish up cpu tasks in progress.

Let's set estimated start time to March 14, 12:00 UTC. I'll make another post later.

But no need to hurry, this is not a challenge where every extra second may give you extra scores. This is more like a lottery - who'll be lucky to find first mega-prime. We'll have about 158'000 candidates to test, this is sufficient amount of work. On the other hand, there are 3-4 primes are expected in this range and we may find this prime on the second day...

mackerel
Volunteer tester

Joined: 2 Oct 08
Posts: 2639
ID: 29980
Credit: 568,393,769
RAC: 1,834

Message 127916 - Posted: 12 Mar 2019 | 10:02:19 UTC

A request if I may. Could this be added as default unselected? I randomly throw some small units through my systems and don't want to end up with a bunch of these by accident after it goes live but before I can review settings.

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127917 - Posted: 12 Mar 2019 | 10:12:25 UTC - in response to Message 127916.

A request if I may. Could this be added as default unselected? I randomly throw some small units through my systems and don't want to end up with a bunch of these by accident after it goes live but before I can review settings.

It'll be default unselected but, you may get some occasionally if you have both "get other work if no selected work available" option turned on and only GFN-13 selected (since there are no GFN-13 CPU work, you'll get a mix of GFN-14 and MEGA16 CPU tasks). In this case you should turn this option off and select GFN-14 if you plan to crunch it.

Sergey Kovalchuk

Joined: 29 Sep 15
Posts: 6
ID: 422666
Credit: 38,991,522
RAC: 0

Message 127918 - Posted: 12 Mar 2019 | 10:45:24 UTC - in response to Message 127917.

you can install the application on the server now. then users will be able to change personal settings before WUs appear

new application is already on the server (saw it in the /download/ folder), it is just not available in the settings

mackerel
Volunteer tester

Joined: 2 Oct 08
Posts: 2639
ID: 29980
Credit: 568,393,769
RAC: 1,834

Message 127920 - Posted: 12 Mar 2019 | 12:41:11 UTC - in response to Message 127917.

It'll be default unselected but, you may get some occasionally if you have both "get other work if no selected work available" option turned on and only GFN-13 selected (since there are no GFN-13 CPU work, you'll get a mix of GFN-14 and MEGA16 CPU tasks). In this case you should turn this option off and select GFN-14 if you plan to crunch it.

Understood and thanks.

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127921 - Posted: 12 Mar 2019 | 13:05:00 UTC

What will the app_config.xml look like?

Something like this?

<app>
<name>MEGA16</name>
<fraction_done_exact/>
</app>
<app_version>
<app_name>MEGA16</app_name>
<cmdline>-t 4</cmdline>
<avg_ncpus>4</avg_ncpus>
</app_version>

____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127922 - Posted: 12 Mar 2019 | 13:25:15 UTC - in response to Message 127918.

you can install the application on the server now. then users will be able to change personal settings before WUs appear

new application is already on the server (saw it in the /download/ folder), it is just not available in the settings

Ah, good idea. It was completely installed (I've tested one workunit to verify smooth operation on all steps), just hidden. I think I can open it now.

For those who want to start this project automatically as early as possible: select "GFN-16 Mega" in your preferences and deselect GFN-14 (GFN-13 is not important because this is GPU-only project). Keep "Get other work when no selected work available" checked. Since there are no GFN-16 tasks, you'll get GFN-14 for CPU. These tasks are small, server will be contacted quite often. As soon as GFN-16 tasks appear, server will send them to you.

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127923 - Posted: 12 Mar 2019 | 13:35:31 UTC - in response to Message 127921.

What will the app_config.xml look like?

Something like this?

<app>
<name>MEGA16</name>
<fraction_done_exact/>
</app>
<app_version>
<app_name>MEGA16</app_name>
<cmdline>-t 4</cmdline>
<avg_ncpus>4</avg_ncpus>
</app_version>

1. Application name will be gfn16_mega
2. The <app> block is superfluous in this trivial case. There are no other settings in it, so it can be removed completely (no block - no overrides).

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

This is a minimal file for 4 threads. It may be better to run 2 tasks * 2 threads on 4 true cores, but it's system-dependent.

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13958
ID: 53948
Credit: 393,418,261
RAC: 198,590

Message 127924 - Posted: 12 Mar 2019 | 13:51:30 UTC - in response to Message 127923.

What will the app_config.xml look like?

Something like this?

<app>
<name>MEGA16</name>
<fraction_done_exact/>
</app>
...

2. The <app> block is superfluous in this trivial case. There are no other settings in it, so it can be removed completely (no block - no overrides).

For some reason, if there's an <app_version> block, the <fraction_done_exact/> flag is set to 0. This overrides the directive set by the server. If you're using app_config, it seems that it's necessary to always include an <app> block in order to specify the <fraction_done_exact/> setting.

It's not a necessity, of course, but the if you like realistic estimates, its very nice to have.
____________
My lucky number is 75898524288+1

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127925 - Posted: 12 Mar 2019 | 13:58:27 UTC - in response to Message 127923.

1. Application name will be gfn16_mega
2. The <app> block is superfluous in this trivial case. There are no other settings in it, so it can be removed completely (no block - no overrides).

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

This is a minimal file for 4 threads. It may be better to run 2 tasks * 2 threads on 4 true cores, but it's system-dependent.

Thanks Stream
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

robish
Volunteer moderator
Volunteer tester

Joined: 7 Jan 12
Posts: 2197
ID: 126266
Credit: 7,325,369,167
RAC: 3,114,848

Message 127926 - Posted: 12 Mar 2019 | 13:58:43 UTC - in response to Message 127924.

What will the app_config.xml look like?

Something like this?

<app>
<name>MEGA16</name>
<fraction_done_exact/>
</app>
...

2. The <app> block is superfluous in this trivial case. There are no other settings in it, so it can be removed completely (no block - no overrides).

For some reason, if there's an <app_version> block, the <fraction_done_exact/> flag is set to 0. This overrides the directive set by the server. If you're using app_config, it seems that it's necessary to always include an <app> block in order to specify the <fraction_done_exact/> setting.

It's not a necessity, of course, but the if you like realistic estimates, its very nice to have.

Thanks Mike
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26

dukebg
Volunteer tester

Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0

Message 127927 - Posted: 12 Mar 2019 | 14:59:41 UTC - in response to Message 127848.

I think we can start project soon after end of PG challenge. The server is ready and tested, all it need is 3-4 more days of sieving.

What's the current candidate removal rate, if you don't mind looking that up / figuring that out?

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127930 - Posted: 12 Mar 2019 | 17:08:30 UTC - in response to Message 127924.

What will the app_config.xml look like?

Something like this?

<app>
<name>MEGA16</name>
<fraction_done_exact/>
</app>
...

2. The <app> block is superfluous in this trivial case. There are no other settings in it, so it can be removed completely (no block - no overrides).

For some reason, if there's an <app_version> block, the <fraction_done_exact/> flag is set to 0. This overrides the directive set by the server. If you're using app_config, it seems that it's necessary to always include an <app> block in order to specify the <fraction_done_exact/> setting.

No. Just look at the source. They're two separate lists handled in two separate loops.

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13958
ID: 53948
Credit: 393,418,261
RAC: 198,590

Message 127932 - Posted: 12 Mar 2019 | 17:15:49 UTC - in response to Message 127930.

What will the app_config.xml look like?

Something like this?

<app>
<name>MEGA16</name>
<fraction_done_exact/>
</app>
...

2. The <app> block is superfluous in this trivial case. There are no other settings in it, so it can be removed completely (no block - no overrides).

For some reason, if there's an <app_version> block, the <fraction_done_exact/> flag is set to 0. This overrides the directive set by the server. If you're using app_config, it seems that it's necessary to always include an <app> block in order to specify the <fraction_done_exact/> setting.

No. Just look at the source. They're two separate lists handled in two separate loops.

It may only happen when you use the remote ability to set app_config. I know BOINCTasks has this ability, but I don't think BOINC Manager does. Regardless, it's definitely happening, at least under the correct conditions.
____________
My lucky number is 75898524288+1

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127941 - Posted: 12 Mar 2019 | 21:53:34 UTC - in response to Message 127932.

It may only happen when you use the remote ability to set app_config. I know BOINCTasks has this ability, but I don't think BOINC Manager does. Regardless, it's definitely happening, at least under the correct conditions.

Post hoc, ergo propter hoc. This variable is used only on 3 lines of code, it's easy to check. In case of problems, I'd checked what wrapper is reporting. For example, it cannot know percentage done until LLR prints it, which may take a while for slow projects like SoB. During this period, Boinc will report any own wild guesses.

Anyway, it's not a error, it's just a superfluous entry which will not harm anything. But if you've intentionally included this block to the file (e.g. wish to tweak other settings), this variable MUST be here. Unspecified == zero.

TimT

Joined: 2 Dec 11
Posts: 501
ID: 121414
Credit: 2,484,701,861
RAC: 1,777,665

Message 127943 - Posted: 13 Mar 2019 | 0:41:41 UTC - in response to Message 127941.

Hey Stream, Can you post a quick and dirty how-to get connected to this project? I'll throw a machine in your direction. I just need the basic how to get boinc talking to it.

--Tim

Joined: 28 Feb 18
Posts: 284
ID: 984171
Credit: 182,080,291
RAC: 0

Message 127944 - Posted: 13 Mar 2019 | 2:48:06 UTC - in response to Message 127943.

Tim,

most of the info is here...

How to participate

To participate, please register at GFN-13/14 Boinc server at http://boincvm.proxyma.ru:30080/test4vm/

- Go to URL above;

- Click on "Your account" on left panel;

- Click on the "or create an account" link in the bottom left part of the page;

- In the "Invitation Code" field, enter PrimeGrid

- Fill other fields in usual way. It's preferred to use same email address as on PrimeGrid, it's required for possible transfer of credit (if it ever happens, see below).

- After registration, connect your Boinc client to the project using URL above. It's recommended to use "weak account key" in place of of true password. Your can get your key on "Your account" page, click on "Account keys"

For new users, your account will be automatically configured to work on GFN-14 project with GFN-13 project as backup (in case of temporary shortage of work). Existing users should manually select GFN-14 project, disable GFN-13 and enable "If no work for selected applications is available, accept work from other applications?" option if they like to keep GFN-13 as backup project.

The server is compatible with PrimeGrid and supports extra venues (Sun...Pluto). Note: this is not a PrimeGrid server. Although all discussion and support happens here on PrimeGrid forum, the server is running on my own resources.

Schedule

There is no specific start time. Instead, the hunt starts as soon as leading edge reaches 22M. There are some "standard" canidates from 21M to 22M which can be used to test and tune your systems. Time required to purge these candidates is unpredictable and strongly depends on participation level, it can be anywhere from 2 to 7 says.

Optimizing performance

CPU - it seems that hyperthreading improves overall performance, at least on Intel CPUs.

GPU - First, you MUST configure your systems to run few tasks at once, otherwise modern GPUs will not be fully utilized.

Second, you MUST keep one CPU core free to feed GPU. Unfortunately, Genefer requires significant amount of CPU time for low GFNs (not a full core, but still noticeable). Hypethreading helps here, one hypethread core is more then enough for this.

To limit number of CPU cores, use your Boinc client configuration dialog. Also you can manually create cc_config.xml file in the Boinc data directory. Example:

<cc_config>
<options>
<ncpus>3</ncpus>
</options>
</cc_config>

In this example, we'll tell Boinc to use 3 CPU cores (out of 4). Please change this number according to your CPU. If you already have cc_config.xml file, edit or add "<ncpus>" line inside "<options>" block.

Next, in the Boinc data directory, under projects/boincvm.proxyma.ru.... subfolder, create app_config.xml with following content:

<app_config>

<app>
<name>gfn13</name>
<fraction_done_exact/>
</app>
<app_version>
<app_name>gfn13</app_name>
<plan_class>opencl_nvidia_gfn_101</plan_class>
<avg_ncpus>0.01</avg_ncpus>
<ngpus>0.25</ngpus>
<cmdline>-x ocl4</cmdline>
</app_version>

<app>
<name>gfn14</name>
<fraction_done_exact/>
</app>
<app_version>
<app_name>gfn14</app_name>
<plan_class>opencl_nvidia_gfn_101</plan_class>
<avg_ncpus>0.01</avg_ncpus>
<ngpus>0.25</ngpus>
<cmdline>-x ocl4</cmdline>
</app_version>

</app_config>

AMD/ATI users please replace opencl_nvidia_gfn_101 with opencl_ati_gfn_101

This will run 4 GPU tasks. (ngpus=0.25). This is enough for low- and middle-class GPUs. 3 tasks are enough to get good utilization and 4th task is added to avoid "drops" on the utilizaton graph when one of tasks was finished and being reloaded. For optimal performance, please check that GPU utilization is at least 80%. You can use freeware GPU-Z utility. If you want to run more tasks, edit "<ngpus>" ratio - set it to 0.2 to run 5 tasks, and so on. Note: you will not reach optimal performance without free CPU core.

Don't forget to ask Boinc to reload configuration files after you've created or edited them.

Running PrimeGrid as backup project

It's a good idea to crunch something even if project server has temporary gone offline. Go to PrimeGrid Preferences page and set "Resource Share" to 0. If GFN server becomes out work or unreachable, your Boinc client will automatically switch to PrimeGrid tasks until GFN server recovers.

Credit

Credit is assigned according to PrimeGrid rules. But this is not a PrimeGrid server, so credit stays here. Only if we could convince Michael to transfer credit back to PG accounts :))) (to the GFN or PSA, during hunt period only). But even if we do, it will be manual procedure which will happen rarely (for example, each 10 days), similar to PSA. So why it's necessary to have same email address here and on PG - for automatic account matching.

Happy hunting everybody!

or at...

____________

Tonight's lucky numbers are

555*2^3563328+1 (PPS-MEGA)

and

58523466^131072+1 (GFN-17 MEGA)

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127947 - Posted: 13 Mar 2019 | 5:53:34 UTC - in response to Message 127927.

I think we can start project soon after end of PG challenge. The server is ready and tested, all it need is 3-4 more days of sieving.

What's the current candidate removal rate, if you don't mind looking that up / figuring that out?

Determining optimal sieving depth in not trivial in this case because it's not known when the prime could be and how many candidates we'll process before we find it. Considering 3-4 possible primes in this range, let's assume 300K range. For this count, current removal ratio is slightly above LLR ratio, but falling down quickly. Full range is undersieved. Sieving will continue during search to catch up for full range.

Michael Goetz
Volunteer moderator

Joined: 21 Jan 10
Posts: 13958
ID: 53948
Credit: 393,418,261
RAC: 198,590

Message 127948 - Posted: 13 Mar 2019 | 6:48:37 UTC - in response to Message 127278.

First megaprime in GFN16 (or GFN15) series

Would anyone find it interesting to locate the first megaprime for GFN16?

The first megaprime for GFN17 through GFN20 is known. Clearly, for lower exponents, a much higher b value (base) is needed to reach the mega level.

For GFN16, we need b > 10^(999999/65536) = 1814570322693369.9

This is the smallest GFN16 mega prime I'm aware of: 181937924208912465536+1

A.k.a 42654182131072+1, the smallest GFN17 mega prime at 1,000,075 digits.

____________
My lucky number is 75898524288+1

dukebg
Volunteer tester

Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0

Message 127949 - Posted: 13 Mar 2019 | 9:04:34 UTC - in response to Message 127948.

First megaprime in GFN16 (or GFN15) series

Would anyone find it interesting to locate the first megaprime for GFN16?

The first megaprime for GFN17 through GFN20 is known. Clearly, for lower exponents, a much higher b value (base) is needed to reach the mega level.

For GFN16, we need b > 10^(999999/65536) = 1814570322693369.9

This is the smallest GFN16 mega prime I'm aware of: 181937924208912465536+1

A.k.a 42654182131072+1, the smallest GFN17 mega prime at 1,000,075 digits.

That's a good point.
For b values that are perfect squares, the resulting number is really a GFN17 and is already either sieved out or tested by the PG GFN17-mega project.

Thus I propose we remove all perfect squares b's from this project's candidates.

(it'll probably be, like, 500 according to the my back of the napkin calculation of the density of the squares. Out of 158K candidates or so that we have from stream's last mention)

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127950 - Posted: 13 Mar 2019 | 9:21:45 UTC - in response to Message 127949.

That's a good point.
For b values that are perfect squares, the resulting number is really a GFN17 and is already either sieved out or tested by the PG GFN17-mega project.

Thus I propose we remove all perfect squares b's from this project's candidates.

(it'll probably be, like, 500 according to the my back of the napkin calculation of the density of the squares. Out of 158K candidates or so that we have from stream's last mention)

True. However, there are no perfect squares in our interval:

[1814570322693370, 1814570323693370].

I doubt we will ever reach the next perfect square, 1814570349755076.

/JeppeSN

dukebg
Volunteer tester

Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0

Message 127951 - Posted: 13 Mar 2019 | 9:36:57 UTC - in response to Message 127950.

d'oh. there must be an error in my napkin... oh, right, i was starting from zero, not b_min.
the density around bmin = 1814570322693370 is 1 in 42M... d'oh... x_x

JeppeSN

Joined: 5 Apr 14
Posts: 1806
ID: 306875
Credit: 49,107,162
RAC: 13,870

Message 127952 - Posted: 13 Mar 2019 | 10:11:57 UTC - in response to Message 127951.

Correct. In other words, this search takes place in the region between the mega threshold 10^(10^6-1) and the first GFN-17-MEGA candidate which was 42597774^131072 + 1 = 1814570349755076^65536 + 1. This candidate was certainly sieved away back then, it has a small factor 11272193 = 43*2^18 + 1. /JeppeSN

TimT

Joined: 2 Dec 11
Posts: 501
ID: 121414
Credit: 2,484,701,861
RAC: 1,777,665

Message 127970 - Posted: 13 Mar 2019 | 23:07:59 UTC - in response to Message 127944.

Thanks to Dad for showing me the instructions.

I feel like a complete dummy because I have not had to attach anything to boinc for many years (I generally use BAM! to manage projects when a new computer arrives)

anyhow, I created an account and trying to attach a linux machine using boinccmd and my account key -- it seems to 'try' to work, then something is failing.. this is all I get in the logs:

234917 3/13/2019 7:03:06 PM Project communication failed: attempting access to reference site

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127973 - Posted: 14 Mar 2019 | 5:41:46 UTC - in response to Message 127970.

Thanks to Dad for showing me the instructions.

I feel like a complete dummy because I have not had to attach anything to boinc for many years (I generally use BAM! to manage projects when a new computer arrives)

anyhow, I created an account and trying to attach a linux machine using boinccmd and my account key -- it seems to 'try' to work, then something is failing.. this is all I get in the logs:

234917 3/13/2019 7:03:06 PM Project communication failed: attempting access to reference site

Most probably you've mistyped project URL on the command line, may be missed a port number. Try cut and paste following:
boinccmd --project_attach http://boincvm.proxyma.ru:30080/test4vm/ your_account_key_here

I'm not familiar with BAM, but you may use at least standard Boinc GUI (or any other tool where you can specify your own "other" project URL) to attach with username and password. Account keys were invented to avoid possible exposing of your real password, but their usage is not mandatory and you always can go back to classic way.

TimT

Joined: 2 Dec 11
Posts: 501
ID: 121414
Credit: 2,484,701,861
RAC: 1,777,665

Message 127993 - Posted: 14 Mar 2019 | 14:53:49 UTC - in response to Message 127973.

Most probably you've mistyped project URL on the command line, may be missed a port number. Try cut and paste following:
boinccmd --project_attach http://boincvm.proxyma.ru:30080/test4vm/ your_account_key_here

I'm not familiar with BAM, but you may use at least standard Boinc GUI (or any other tool where you can specify your own "other" project URL) to attach with username and password. Account keys were invented to avoid possible exposing of your real password, but their usage is not mandatory and you always can go back to classic way.

I managed to figure out how to connect a regular PC boinc manager to the linux machine -- tried again to add the server there (copy / pasted the url Exactly as above, and tried both of the account keys listed on your server for my acct) -- I get the same result whether adding via command line or through the boinc manager -- here's what I see in the boinc log when I try to refresh that project:

3/14/2019 10:47:47 AM | http://boincvm.proxyma.ru:30080/test4vm/ | update requested by user
3/14/2019 10:47:52 AM | http://boincvm.proxyma.ru:30080/test4vm/ | Fetching scheduler list
3/14/2019 10:47:53 AM | | Project communication failed: attempting access to reference site
3/14/2019 10:47:54 AM | | Internet access OK - project servers may be temporarily down.

-- (edit 2) when trying to add as a new project, I see this:

3/14/2019 10:57:39 AM | | Fetching configuration file from http://boincvm.proxyma.ru:30080/test4vm/get_project_config.php
3/14/2019 10:57:41 AM | | Project communication failed: attempting access to reference site
3/14/2019 10:57:42 AM | | Internet access OK - project servers may be temporarily down.

any chance you can see what is going on from your side? perhaps something is being blocked by network somewhere? I'll try to refresh it a bunch of times to maybe help pick it out of any logs...

I can access the website just fine...

<EDIT>

Update: I decided to try adding the project on my windows laptop -- and it WORKED -- for some reason, the linux client reports " project temporarily unavailable"

stream
Volunteer moderator
Volunteer developer
Volunteer tester

Joined: 1 Mar 14
Posts: 1022
ID: 301928
Credit: 543,195,386
RAC: 1

Message 127998 - Posted: 14 Mar 2019 | 18:33:10 UTC - in response to Message 127993.

Update: I decided to try adding the project on my windows laptop -- and it WORKED -- for some reason, the linux client reports " project temporarily unavailable"

I'm afraid that there are some issues with network configuration on this linux machine, for example, firewall may block connection to non-standard port (30080). If you have access to and familiar with command line, try standard diagnostic sequence:

ping boincvm.proxyma.ru

There must be replies to ping proving that site itself is accessible.

wget http://boincvm.proxyma.ru:30080/test4vm/

Look for error messages. If there are no errors, look inside downloaded index.html. It is true web page of GFN server or some output from intermediate firewall?

TimT

Joined: 2 Dec 11
Posts: 501
ID: 121414
Credit: 2,484,701,861
RAC: 1,777,665

Message 128010 - Posted: 14 Mar 2019 | 21:26:38 UTC - in response to Message 127998.

Look for error messages. If there are no errors, look inside downloaded index.html. It is true web page of GFN server or some output from intermediate firewall?

Both of those tests seem to be fine:

[timt@Node1 boinc]\$ wget http://boincvm.proxyma.ru:30080/test4vm/ --2019-03-14 17:20:25-- http://boincvm.proxyma.ru:30080/test4vm/ Resolving boincvm.proxyma.ru (boincvm.proxyma.ru)... 37.147.149.51 Connecting to boincvm.proxyma.ru (boincvm.proxyma.ru)|37.147.149.51|:30080... connected. HTTP request sent, awaiting response... 200 OK Length: 5324 (5.2K) [text/html] Saving to: ‘index.html’ index.html 100%[===========================================================================>] 5.20K --.-KB/s in 0.01s 2019-03-14 17:20:26 (433 KB/s) - ‘index.html’ saved [5324/5324] [timt@Node1 boinc]\$ cat index.html <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html> <head> <title>PRIVATE GFN SERVER</title> <link rel="stylesheet" type="text/css" href="main.css" media="all" /> <link rel="stylesheet" type="text/css" href="white.css"> <link rel="alternate" type="application/rss+xml" title="PRIVATE GFN SERVER RSS 2.0" href="http://boincvm.proxyma.ru:30080/test4vm/rss_main.php"> <!-- <scheduler>http://boincvm.proxyma.ru:30080/test4vm_cgi/cgi</scheduler> --> <link rel="boinc_scheduler" href="http://boincvm.proxyma.ru:30080/test4vm_cgi/cgi"> (...definitely looks like it's the right HTML page, ignoring the rest)

...just another ignorant thought -- could it have something to do with the contents of this file? http://boincvm.proxyma.ru:30080/test4vm/get_project_config.php
-- if I do the same for primegrid, there seem to be a lot more mentions of linux, as well as some different system descriptions...
otherwise, is there any way to get more verbose logging out of boinc?

TimT

Joined: 2 Dec 11
Posts: 501
ID: 121414
Credit: 2,484,701,861
RAC: 1,777,665

Message 128013 - Posted: 14 Mar 2019 | 21:42:00 UTC - in response to Message 127998.

I'm afraid that there are some issues with network configuration on this linux machine, for example, firewall may block connection to non-standard port (30080).

Bingo, had to re-figure out how to use a modern log file reader, but found this in my system logs... I'll work on it...

Mar 14 17:17:38 Node1 python3[10761]: SELinux is preventing boinc_client from name_connect access on the tcp_socket port 30080. ***** Plugin connect_ports (92.2 confidence) suggests ********************* If you want to allow boinc_client to connect to network port 30080 Then you need to modify the port type. Do # semanage port -a -t PORT_TYPE -p tcp 30080 where PORT_TYPE is one of the following: boinc_port_t, dns_port_t, dnssec_port_t, http_cache_port_t, http_port_t, kerberos_port_t, ocsp_port_t, squi ***** Plugin catchall_boolean (7.83 confidence) suggests ****************** If you want to allow nis to enabled Then you must tell SELinux about this by enabling the 'nis_enabled' boolean. Do setsebool -P nis_enabled 1 ***** Plugin catchall (1.41 confidence) suggests ************************** If you believe that boinc_client should be allowed name_connect access on the port 30080 tcp_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'boinc_client' --raw | audit2allow -M my-boincclient # semodule -X 300 -i my-boincclient.pp

TimT

Joined: 2 Dec 11
Posts: 501
ID: 121414
Credit: 2,484,701,861
RAC: 1,777,665

Message 128014 - Posted: 14 Mar 2019 | 21:52:32 UTC - in response to Message 128013.

looks like I'm in business -- sorry for being such a pest and thanks for helping me through it!

Message boards : Generalized Fermat Prime Search : First *megaprime* in GFN16 (or GFN15) series