mersenneforum.org Queue management for 16e queue
 Register FAQ Search Today's Posts Mark Forums Read

 2021-09-12, 23:58 #45 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 22·3·797 Posts 8p3_930M is in LA; small; just a 2-days worth job. Can be moved to 'Post processing'. Fib 1409 will finish first (ETA tomorrow)
 2021-09-17, 12:43 #46 swellman     Jun 2012 3,203 Posts 8-3,341 QUEUED AS 8m3_341 The HCN 8-3,341 is ready for GNFS. As a c193, this job definitely belongs on 16f_small but I ended up splitting the lpbr/a into a 31/32 after extensive (and intentionally naive) test sieving of 24 parameter sets. The values of r+alim = 402M, presumably under Greg’s limit. Code: n: 2336386891136426579841809323098919425924681423702856026805990165735188655301084082303702367027719152311847987495284282076422827038922824223850944481171524784632058160171821029378539494253139241 skew: 38641852.276 type: gnfs # HCN 8-3_341 lss: 0 c0: 4406550827068543220574899900566398752743379 c1: 10635304037567138410619541930862659352 c2: -257904586189613106859667691910 c3: -15641949562904209308151 c4: 61790529410960 c5: 1466640 Y0: -17395768516108913114178572748025422408 Y1: 2981515822618563517895267 # MurphyE (Bf=8.590e+09,Bg=4.295e+09,area=2.684e+16) = 1.255e-08 # msieve gives skew 38641852.28, size 7.543e-019, alpha -4.910, combined = 1.480e-014 rroots = 5 rlim: 134000000 alim: 268000000 lpbr: 31 lpba: 32 mfbr: 62 mfba: 94 rlambda: 2.7 alambda: 3.5 Test sieving results on the -a side in blocks of 10k: Code: Q(M) Corrected Yield 50 22799 100 23198 150 20997 200 19610 250 18449 With a notional target of 350M raw relations, these results suggest a range of 45-210M for Q. I'll do the LA. Last fiddled with by swellman on 2021-10-04 at 16:45
 2021-09-30, 23:18 #47 swellman     Jun 2012 C8316 Posts C199_M31_k35 From the kosta project, caching this SNFS 261 here. The GNFS 199 was a contender for this factorization but ultimately went with the quartic. Code: n: 4950036370987531796596777020435431752821658735009564665203032637182311299258729058872170618265983042169789410985851232822128958988972946232939020745222679656170411937888556774248091592015827689480701  skew: 2.04458  type: snfs  size: 261  c4: 1  c3: 1  c2: 1  c1: 1  c0: 1  Y1: 1  Y0: -210624582650556372047028295576838759252690170086892944262392971263  lpbr: 33  lpba: 33  mfbr: 96  mfba: 66  alim: 225000000  rlim: 225000000  rlambda: 3.7  alambda: 3.0   Polynomial and skew both courtesy of cownoise.   Test sieving results on the rational side with Q in blocks of 5000:   Code:  Q0(M) Adjusted_yield  60 7333  100 8430  200 9681  300 9295  400 8658  500 8297  600 7925 Suggesting a Q-range of 60-570M will produce 900M raw relations. I hope others will propose jobs for the 16f_small queue. It is not my intent to monopolize it - my recent postings are a a buffer for those occasions when work runs low. Please post away!
 2021-10-01, 17:23 #48 VBCurtis     "Curtis" Feb 2005 Riverside, CA 33·5·37 Posts Don't large quartics benefit strongly from asymmetric lim's and LP bounds? I wager 32/34 will be much more effective than 33/33, and I think lim's of e.g. 200/250 would also help compared to 225/225.
2021-10-01, 17:33   #49
swellman

Jun 2012

62038 Posts

Quote:
 Originally Posted by VBCurtis Don't large quartics benefit strongly from asymmetric lim's and LP bounds? I wager 32/34 will be much more effective than 33/33, and I think lim's of e.g. 200/250 would also help compared to 225/225.
I always check 2/2, 2/3, 3/2 LPs but I didn’t consider shifting to 32/34(!) or asymmetry in the lims. Will msieve even run with a value of 34 lpbr/a?

2021-10-01, 20:48   #50
charybdis

Apr 2020

49810 Posts

Quote:
 Originally Posted by swellman I always check 2/2, 2/3, 3/2 LPs but I didn’t consider shifting to 32/34(!) or asymmetry in the lims. Will msieve even run with a value of 34 lpbr/a?
This should be lpbr/lpba 34/32 - not 32/34 which would be more appropriate for an octic. (the larger the degree the larger the algebraic side)

Msieve is fine with 34-bit large primes; it's the siever that is the issue. The standard 16e siever is limited to 33-bit but while it's apparently very easy to remove this restriction, I don't know whether this has been done for the NFS@Home version. Even if it has, the siever will still be unable to handle mfbr/a > 96. The 16f-v5 siever used for the huge NFS@Home jobs can handle larger mfb values.

 2021-10-01, 21:02 #51 VBCurtis     "Curtis" Feb 2005 Riverside, CA 33·5·37 Posts Sorry for transposing the lpb's. My understanding of the 16e queue is that it's the same siever as the "big" queue, so I thought 34LP and 99MFB would be fine. If I'm wrong about the siever, I think 32/33 would still be preferable to 33/33- I don't mind doing the test-sieve to see if I'm right? Msieve is definitely fine with 34/32LP, since it'll need about the same number of relations as 33/33 so filtering should work just fine. Edit: Posts 2-5 in this thread discuss a 261 quartic, and observe that maybe that's too big for f-small. Are you sure GNFS-199 isn't the easier solution for this job? Last fiddled with by VBCurtis on 2021-10-01 at 21:25
2021-10-01, 22:10   #52
swellman

Jun 2012

62038 Posts

Quote:
 Originally Posted by VBCurtis Sorry for transposing the lpb's. My understanding of the 16e queue is that it's the same siever as the "big" queue, so I thought 34LP and 99MFB would be fine. If I'm wrong about the siever, I think 32/33 would still be preferable to 33/33- I don't mind doing the test-sieve to see if I'm right? Msieve is definitely fine with 34/32LP, since it'll need about the same number of relations as 33/33 so filtering should work just fine. Edit: Posts 2-5 in this thread discuss a 261 quartic, and observe that maybe that's too big for f-small. Are you sure GNFS-199 isn't the easier solution for this job?
Greg is testing a version of the sievers using 34 LP but it’s not stock. I don’t think ggnfs can deal with it normally. But I haven’t tried it so…

If you could run a bit of test sieving I would be grateful. All my machines are currently tasked but there’s certainly no hurry on this job.

I was surprised how well behaved this quartic was in test sieving but of course it’s nowhere near the speed of a S261 sextic. But I wanted to run a more difficult quartic, and I’m not convinced a G199 would be any faster especially adding in the poly search time. I did bounce this job off Greg and he had no issues with it, but we didn’t directly deal with the issue of GNFS vs SNFS.

 2021-10-01, 23:41 #53 VBCurtis     "Curtis" Feb 2005 Riverside, CA 10011100000112 Posts First sieve test with 34/32 and 250/200 lim's shows 0.61 sec/rel at Q=200M... pretty decent. I think that's a bit quicker than GNFS-199 would be at 33/33, maybe equivalent to a GNFS-197, though yield is lower so more Q are needed than would be for the GNFS job. I'll do a complete test-sieve of 34/32 and 33/32 by Saturday night.
2021-10-02, 00:15   #54
frmky

Jul 2003
So Cal

22·547 Posts

Quote:
 Originally Posted by VBCurtis My understanding of the 16e queue is that it's the same siever as the "big" queue, so I thought 34LP and 99MFB would be fine.
You are right. Both of these queues use the same binaries, so it should work fine.

2021-10-02, 00:46   #55
charybdis

Apr 2020

1111100102 Posts

Quote:
 Originally Posted by frmky You are right. Both of these queues use the same binaries, so it should work fine.
Aha, good to know. Sorry if I confused anyone.

Never mind the parameter choice for the quartic, I'm surprised this isn't obviously better by GNFS. While it isn't a perfect reflection of difficulty, the Q range of 60-570M is surely much larger than a GNFS-199 would require?

 Similar Threads Thread Thread Starter Forum Replies Last Post VBCurtis NFS@Home 201 2021-10-17 15:54 VBCurtis NFS@Home 61 2021-10-17 09:16 Rodrigo Software 7 2018-05-25 13:26 debrouxl NFS@Home 10 2018-05-06 21:05 joblack Information & Answers 1 2009-01-06 08:45

All times are UTC. The time now is 22:50.

Tue Oct 19 22:50:53 UTC 2021 up 88 days, 17:19, 0 users, load averages: 1.90, 1.69, 1.44