BOINC NFS sieving - NFS@Home - Page 173

frmky · 2022-01-01, 01:37

Quote:

Originally Posted by pinhodecarlos

Can't reach the server, Greg?

Works for me.

pinhodecarlos · 2022-01-01, 01:44

It's up and down, just keep an eye since we have more than 100k wus to upload..lol

frmky · 2022-01-01, 02:30

Quote:

Originally Posted by pinhodecarlos

It's up and down, just keep an eye since we have more than 100k wus to upload..lol

Just don't save them until the very end and overload the validator. If they validate after the deadline, then they don't count!

swellman · 2022-01-03, 19:52

Is it ok to download files for LA now, or is it better to wait until the challenge is over?

pinhodecarlos · 2022-01-03, 21:15

Quote:

Originally Posted by swellman

Is it ok to download files for LA now, or is it better to wait until the challenge is over?

It's fine now, thank you.

swellman · 2022-01-14, 12:03

Quote:

Originally Posted by charybdis

Haven't test-sieved this but I agree that the octic should be looked at too. From a small amount of test-sieving on 7,395+/- (diff. 268, the smallest remaining Cunningham quartics before the base-2 extension), the quartic appears to have a slight edge over the octic, but this is partly because the octic has larger coefficients, the largest being 7^4 = 2401. For 2,2622L, the quartic and octic have the same non-zero coefficients.

By the time you get to 2,1180+ (diff. 285), the octic is ~3 times faster than the quartic.

Bumping this topic back to the surface. Can someone post the octic? I am willing to run comparative testing on the quartic vs octic for 2,2622L.

jyb · 2022-01-14, 15:17

Quote:

Originally Posted by swellman

Bumping this topic back to the surface. Can someone post the octic? I am willing to run comparative testing on the quartic vs octic for 2,2622L.

Code:

n: 3505977787209285091968931818986424997941305592162629858046013444282658804478379353491428452055056465267944599831189031983991025125888045576382102814280868751028405287402991369503492629479884494160042055556595085696787940484104369
skew: 0.84090
c8: 4
c6: -4
c4: 2
c2: -2
c0: 1
Y1: 1
Y0: -649037107316853453566312041152512

pinhodecarlos · 2022-01-25, 22:25

Good to check this year at least for the 16eV5 Siever more CPU is allocated. Hope it is not cycled but instead upgrades from Christmas. Was wondering when we would achieve a steady 100k wus per day, this would be awesome.

swellman · 2022-02-15, 18:03

I've completed test sieving of 2,2622L, the next Cunningham job suggested by Sam Wagstaff. Based on discussions in this forum, I ran some comparative tests between the quartic and octic. Initial tries used 34-bit but ultimately I found 33-bit to be feasible.

For the quartic, the best performance was on the rational side came from using this set of parameters:

Code:

n: 3505977787209285091968931818986424997941305592162629858046013444282658804478379353491428452055056465267944599831189031983991025125888045576382102814280868751028405287402991369503492629479884494160042055556595085696787940484104369
skew: 1.414
type: snfs
size: 263
c4: 1
c3: -2
c2: 2
c1: -4
c0: 4
Y1: 1
Y0: -842498333348457493583344221469363458551160763204392890034487820288
rlim: 225000000
alim: 225000000
lpbr: 34
lpba: 34
mfbr: 100
mfba: 68
rlambda: 3.8
alambda: 3.1

When sieved on the rational side over a Q block of 1000 (with Q0=100M) using a version of ggnfs with the lpb limit of 33 removed, the following results were realized

Code:

Total yield: 3393
53 Special q
0.575 sec/ral
Normalized yield: 3475

And for the octic, using the following poly file on the algebraic side:

Code:

n: 3505977787209285091968931818986424997941305592162629858046013444282658804478379353491428452055056465267944599831189031983991025125888045576382102814280868751028405287402991369503492629479884494160042055556595085696787940484104369
skew: 0.84090
type: snfs
size: 263
lss: 0
c8: 4
c6: -4
c4: 2
c2: -2
c0: 1
Y1: 1
Y0: -649037107316853453566312041152512
rlim: 225000000
alim: 225000000
lpbr: 34
lpba: 34
mfbr: 68
mfba: 100
rlambda: 3.1
alambda: 3.8

Again using the modified ggnfs siever with Q in a block of 1000 (with Q0=100M) on the algebraic side:

Code:

Total yield: 8912
76 Special q
0.356 sec/rel
Normalized yield: 6366

While the yield of each job listed above could be slightly improved, the octic seems the better choice by far. So I ignored the quartic going forward.

I then worked in the 33-bit arena in an attempt to make this job a smaller monster. Running it as a 32/33 job, the yield dropped below 1.0 at the higher Q so in the end I went with 33/33.

Please note that I was testing with my Yafu rig, using the "standard" ggnfs sievers. I was forced to use mfba = 96, but NFS@Home will likely get better yield since it can use mfba = 97. Not sure how big a difference this fact will ultimately make.

Code:

n: 3505977787209285091968931818986424997941305592162629858046013444282658804478379353491428452055056465267944599831189031983991025125888045576382102814280868751028405287402991369503492629479884494160042055556595085696787940484104369
skew: 0.84090
type: snfs
size: 263
lss: 0
c8: 4
c6: -4
c4: 2
c2: -2
c0: 1
Y1: 1
Y0: -649037107316853453566312041152512
rlim: 316000000
alim: 134000000
lpbr: 33
lpba: 33
mfbr: 66
mfba: 96
rlambda: 3.0
alambda: 3.7

Results of test sieving on the -a side with Q in blocks of 1000:

Code:

MQ       Norm_yield      Speed (sec/rel)
50          3009              0.845
60          2985              0.834
100         2733              0.940
150         2468              1.034
200         1732              1.363
300         1555              1.394
400         1446              1.651
500         1165              1.913
600         1055              1.874

Suggesting a sieving range of 50-620M to produce 950M raw relations.

Greg tells me he prefers a target # of raw relations ~1 billion when sieving 33/33 jobs, but I suggest using mfba = 97 with Q=50-620M in the enqueued job - we can later bump up Q if it proves necessary.

charybdis · 2022-02-15, 18:37

Quote:

Originally Posted by swellman

While the yield of each job listed above could be slightly improved, the octic seems the better choice by far. So I ignored the quartic going forward.

When test-sieving a quartic against an octic, it is absolutely essential to compare a wide range of Q values. As you observed here, the yield from the octic drops off massively at higher Q. This doesn't happen nearly as much with a quartic. Picking a single low Q value for the comparison will always make the octic look better and the quartic worse than they really are.

VBCurtis · 2022-02-15, 19:15

Neither a large quartic nor a "small" octic should sieve with the same lim/LP size on both sides. Comparing the two is interesting, since the side to imbalance reverses for octic vs quartic; I wonder if a total mirror-image of params, like 32/34 vs 34/32, is the way to compare the two.

You should pick the LP size that best avoids the low-yield large Q for the octic- it's not like 33/34 is going to make a notably larger matrix than 33/33, but it could shrink max-Q by 10%. I wonder if 32/34 is faster than 33/33, too.

2022-01-25, 22:25	#1900
pinhodecarlos "Carlos Pinho" Oct 2011 Milton Keynes, UK 7×733 Posts	Good to check this year at least for the 16eV5 Siever more CPU is allocated. Hope it is not cycled but instead upgrades from Christmas. Was wondering when we would achieve a steady 100k wus per day, this would be awesome. Last fiddled with by pinhodecarlos on 2022-01-25 at 22:26

2022-02-15, 18:03	#1901
swellman Jun 2012 2×5²×7×11 Posts	I've completed test sieving of 2,2622L, the next Cunningham job suggested by Sam Wagstaff. Based on discussions in this forum, I ran some comparative tests between the quartic and octic. Initial tries used 34-bit but ultimately I found 33-bit to be feasible. For the quartic, the best performance was on the rational side came from using this set of parameters: Code: n: 3505977787209285091968931818986424997941305592162629858046013444282658804478379353491428452055056465267944599831189031983991025125888045576382102814280868751028405287402991369503492629479884494160042055556595085696787940484104369 skew: 1.414 type: snfs size: 263 c4: 1 c3: -2 c2: 2 c1: -4 c0: 4 Y1: 1 Y0: -842498333348457493583344221469363458551160763204392890034487820288 rlim: 225000000 alim: 225000000 lpbr: 34 lpba: 34 mfbr: 100 mfba: 68 rlambda: 3.8 alambda: 3.1 When sieved on the rational side over a Q block of 1000 (with Q0=100M) using a version of ggnfs with the lpb limit of 33 removed, the following results were realized Code: Total yield: 3393 53 Special q 0.575 sec/ral Normalized yield: 3475 And for the octic, using the following poly file on the algebraic side: Code: n: 3505977787209285091968931818986424997941305592162629858046013444282658804478379353491428452055056465267944599831189031983991025125888045576382102814280868751028405287402991369503492629479884494160042055556595085696787940484104369 skew: 0.84090 type: snfs size: 263 lss: 0 c8: 4 c6: -4 c4: 2 c2: -2 c0: 1 Y1: 1 Y0: -649037107316853453566312041152512 rlim: 225000000 alim: 225000000 lpbr: 34 lpba: 34 mfbr: 68 mfba: 100 rlambda: 3.1 alambda: 3.8 Again using the modified ggnfs siever with Q in a block of 1000 (with Q0=100M) on the algebraic side: Code: Total yield: 8912 76 Special q 0.356 sec/rel Normalized yield: 6366 While the yield of each job listed above could be slightly improved, the octic seems the better choice by far. So I ignored the quartic going forward. I then worked in the 33-bit arena in an attempt to make this job a smaller monster. Running it as a 32/33 job, the yield dropped below 1.0 at the higher Q so in the end I went with 33/33. Please note that I was testing with my Yafu rig, using the "standard" ggnfs sievers. I was forced to use mfba = 96, but NFS@Home will likely get better yield since it can use mfba = 97. Not sure how big a difference this fact will ultimately make. Code: n: 3505977787209285091968931818986424997941305592162629858046013444282658804478379353491428452055056465267944599831189031983991025125888045576382102814280868751028405287402991369503492629479884494160042055556595085696787940484104369 skew: 0.84090 type: snfs size: 263 lss: 0 c8: 4 c6: -4 c4: 2 c2: -2 c0: 1 Y1: 1 Y0: -649037107316853453566312041152512 rlim: 316000000 alim: 134000000 lpbr: 33 lpba: 33 mfbr: 66 mfba: 96 rlambda: 3.0 alambda: 3.7 Results of test sieving on the -a side with Q in blocks of 1000: Code: MQ Norm_yield Speed (sec/rel) 50 3009 0.845 60 2985 0.834 100 2733 0.940 150 2468 1.034 200 1732 1.363 300 1555 1.394 400 1446 1.651 500 1165 1.913 600 1055 1.874 Suggesting a sieving range of 50-620M to produce 950M raw relations. Greg tells me he prefers a target # of raw relations ~1 billion when sieving 33/33 jobs, but I suggest using mfba = 97 with Q=50-620M in the enqueued job - we can later bump up Q if it proves necessary. Last fiddled with by swellman on 2022-02-15 at 18:05 Reason: Added Q0 values

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Boinc Statistics for NFS@Home borked ?	thomasn	NFS@Home	1	2013-10-02 15:31
BOINC NFS sieving - RSALS	debrouxl	NFS@Home	621	2012-12-14 23:44
BOINC?	masser	Sierpinski/Riesel Base 5	1	2009-02-09 01:10
BOINC?	KEP	Twin Prime Search	212	2007-04-25 10:29
BOINC	bebarce	Software	3	2005-12-15 18:35

2022-01-01, 01:44	#1894
pinhodecarlos "Carlos Pinho" Oct 2011 Milton Keynes, UK 12013₈ Posts	It's up and down, just keep an eye since we have more than 100k wus to upload..lol

2022-01-03, 19:52	#1896
swellman Jun 2012 2·5²·7·11 Posts	Is it ok to download files for LA now, or is it better to wait until the challenge is over?

2022-02-15, 19:15	#1903
VBCurtis "Curtis" Feb 2005 Riverside, CA 2³·3·5·47 Posts	Neither a large quartic nor a "small" octic should sieve with the same lim/LP size on both sides. Comparing the two is interesting, since the side to imbalance reverses for octic vs quartic; I wonder if a total mirror-image of params, like 32/34 vs 34/32, is the way to compare the two. You should pick the LP size that best avoids the low-yield large Q for the octic- it's not like 33/34 is going to make a notably larger matrix than 33/33, but it could shrink max-Q by 10%. I wonder if 32/34 is faster than 33/33, too.