20220101, 01:37  #1893 
Jul 2003
So Cal
2×1,301 Posts 

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

20220101, 02:30  #1895 
Jul 2003
So Cal
A2A_{16} Posts 

20220103, 19:52  #1896 
Jun 2012
2·5^{2}·7·11 Posts 
Is it ok to download files for LA now, or is it better to wait until the challenge is over?

20220103, 21:15  #1897 
"Carlos Pinho"
Oct 2011
Milton Keynes, UK
7·733 Posts 

20220114, 12:03  #1898  
Jun 2012
111100001010_{2} Posts 
Quote:


20220114, 15:17  #1899  
Aug 2005
Seattle, WA
2·13·71 Posts 
Quote:
Code:
n: 3505977787209285091968931818986424997941305592162629858046013444282658804478379353491428452055056465267944599831189031983991025125888045576382102814280868751028405287402991369503492629479884494160042055556595085696787940484104369 skew: 0.84090 c8: 4 c6: 4 c4: 2 c2: 2 c0: 1 Y1: 1 Y0: 649037107316853453566312041152512 

20220125, 22:25  #1900 
"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 20220125 at 22:26 
20220215, 18:03  #1901 
Jun 2012
2×5^{2}×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 34bit but ultimately I found 33bit 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 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 Code:
Total yield: 8912 76 Special q 0.356 sec/rel Normalized yield: 6366 I then worked in the 33bit 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 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 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=50620M in the enqueued job  we can later bump up Q if it proves necessary. Last fiddled with by swellman on 20220215 at 18:05 Reason: Added Q0 values 
20220215, 18:37  #1902 
Apr 2020
1110100001_{2} Posts 
When testsieving 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.

20220215, 19:15  #1903 
"Curtis"
Feb 2005
Riverside, CA
2^{3}·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 mirrorimage 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 lowyield 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 maxQ by 10%. I wonder if 32/34 is faster than 33/33, too. 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Boinc Statistics for NFS@Home borked ?  thomasn  NFS@Home  1  20131002 15:31 
BOINC NFS sieving  RSALS  debrouxl  NFS@Home  621  20121214 23:44 
BOINC?  masser  Sierpinski/Riesel Base 5  1  20090209 01:10 
BOINC?  KEP  Twin Prime Search  212  20070425 10:29 
BOINC  bebarce  Software  3  20051215 18:35 