mersenneforum.org 2022 Queue management of 15e
 Register FAQ Search Today's Posts Mark Forums Read

2022-11-13, 23:42   #155
RichD

Sep 2008
Kansas

25·7·17 Posts

Quote:
 Originally Posted by swellman A few suggestions: I believe the lambda should be mfb/log2(lim) + 0.05 which for the algebraic side is closer to 2.33 or 2.35 if you prefer.
It appears the lower alambda was beneficial. Some of the higher Qs showed a better improvement.
Quote:
 Originally Posted by swellman For 15e, rlim + alim is limited to 400M per Greg. alim must be changed to 266M.
I didn't realize this is a hard ceiling. I was within 1%. I understand scope creep so it was changed.
Quote:
 Originally Posted by swellman I’m not sure about your comment on skew. You’ve used the standard skew = |c0/c6|^(1/6). Cownoise recommends shifting skew to a value of 0.29722 but you should confirm this skew value with cownoise and whether if it improves things via test sieving. (I doubt it will help.)
Yes, 0.297 seemed to help slightly, so I went with it.

 2022-11-13, 23:47 #156 RichD     Sep 2008 Kansas 25×7×17 Posts QUEUED AS 7043_73m1 C278 from the MWRB file with OPN 11673. Second attempt. Code: n: 10929875925037315024994112350260780199767161975518955535270167413583164858504212664897476377692335059939499260248762932645204102682318951183447267479739483769724008717453251826937850228654862574004845245478825442381443215504635534927206893532265948445909765759873218837942895601 # 7043^73-1, difficulty: 280.89, skewness: 0.23, alpha: 0.00 # cost: 8.09051e+19, est. time: 38526.25 GHz days (not accurate yet!) skew: 0.297 c6: 7043 c0: -1 Y0: 14896775084042115440192394458997575421235964401 Y1: -1 type: snfs rlim: 134000000 alim: 266000000 lpbr: 33 lpba: 32 mfbr: 96 mfba: 64 rlambda: 3.6 alambda: 2.4 Trial sieving 2K blocks. Code:  Q Yield N-Yld 35M 4138 4537 40M 4541 4397 70M 3807 3939 100M 3815 3766 200M 2993 2900 300M 2552 2539 400M 2054 2254 485M 1957 2127 Estimated total relations is just under 650M. Not sure what the target amount should be. Last fiddled with by swellman on 2022-11-14 at 00:22
 2022-11-14, 19:52 #157 swellman     Jun 2012 3×1,283 Posts QUEUED AS 7m3_337 7-3,337 is a GNFS 195 composite from the HCN project ready for sieving on 15e. Code: n: 166829745717661922902560230226656838043111314933989400618906667688292157699715771052313703701476488623275299963147398747791394101712383495868958452330438281936964195300670323092745110609922255457 skew: 41690645.38 type: gnfs lss: 0 c0: 2314125335702180927062554641087117903742302710 c1: 1006667217049141773896142573600863375821 c2: -18174767686452749640494005783650 c3: -1351374607965173194481881 c4: 20638709685847640 c5: 220651200 Y0: -31341619302510609707549967065136386763 Y1: 15455039197152616646408807 # MurphyE (Bf=8.590e+09,Bg=4.295e+09,area=2.684e+16) = 9.900e-09 # skew 41690645.38, size 4.286e-019, alpha -8.262, combined = 1.018e-014 rroots = 5 rlim: 266000000 alim: 134000000 lpbr: 33 lpba: 33 mfbr: 66 mfba: 96 rlambda: 2.4 alambda: 3.6 Results of test sieving on the algebraic side with Q in blocks of 1000: Code: MQ Norm_yield 25 2193 50 2564 75 2539 100 2531 150 2279 200 2085 250 2365 300 1866 350 1748 400 1703 450 1592 500 1559 Suggesting a sieving range for Q of 25-480M to generate 940M raw relations. Last fiddled with by swellman on 2022-11-15 at 19:13
2022-12-04, 18:14   #158
kruoli

"Oliver"
Sep 2017
Porta Westfalica, DE

52F16 Posts

Quote:
 Originally Posted by kruoli So I am suggesting sieving Q from 35M to 205M on the algebraic side for around 460M raw relations.
Something must have gone horribly wrong here (not saying it was not my fault). It only generated ~270M relations. It looks like the .fb and .poly files are fine. So what could be wrong?

Last fiddled with by kruoli on 2022-12-04 at 18:39 Reason: Missing words.

 2022-12-04, 19:01 #159 frmky     Jul 2003 So Cal 23×52×13 Posts There's a typo in the line Code: lss : 0 Because of the extra space between lss and the colon, it wasn't recognized and sieving defaulted to the rational side. I recommend at this point to simply continue sieving on the rational side to get the additional needed relations.
 2022-12-04, 19:22 #160 VBCurtis     "Curtis" Feb 2005 Riverside, CA 23·3·5·47 Posts With only 55% or so of the job sieved,I think it's better to make a new job to sieve 200M relations or so on the -a side. Should be *much* faster than doubling the sieve range to continue with -r side.
2022-12-04, 21:02   #161
swellman

Jun 2012

3×1,283 Posts

Quote:
 Originally Posted by frmky There's a typo in the line Code: lss : 0
Indeed. With apologies to all, I’m willing to either extend the range on the -r side to continue OR scrap it and sieve it on the -a side immediately (I can temporarily sideline the other jobs).

Greg will have to delete the original job if we take the second option of course.

I ask Greg to declare a preference. He is the conductor, I just shovel coal into the firebox.

145!-1_b would be:
Code:
n: 61961544527388294841688073882914854435388027897679210391156264443557149767638767403360578514778014603475277763521601393153149828278695416036164441248566103608937469068435239190125514623
skew: 23388742
type: gnfs
lss: 0
c5: 28963296
c4: -468307738325310
c3: -49748528932542980322741
c2: 314034469329584823868962434378
c1: 10234603583895446847339037580343693197
c0: 4983288639261044534250632896338765636096980
Y1: 4473326874907429
Y0: -335939328349166369840151777825025122
rlim: 266000000
alim: 134000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 94
rlambda: 2.7
alambda: 3.9

Last fiddled with by swellman on 2022-12-04 at 21:57 Reason: Changed name of proposed new job

2022-12-04, 21:33   #162
frmky

Jul 2003
So Cal

1010001010002 Posts

Quote:
 Originally Posted by swellman Greg will have to delete the original job if we take the second option of course.
I don't have a strong preference. I'm generally in favor of spending more computer time when it means less human time involved, but if you choose to sieve on the algebraic side then just create a new job with a different name (add _2 or something).

2022-12-04, 22:15   #163
swellman

Jun 2012

3·1,283 Posts

Quote:
 Originally Posted by frmky I don't have a strong preference. I'm generally in favor of spending more computer time when it means less human time involved, but if you choose to sieve on the algebraic side then just create a new job with a different name (add _2 or something).
I have added a corrected job named 145!-1_b and sidetracked the other jobs temporarily. If you would kill the original job that would be great.

Small penance to pay for all the time, both personal and hardware, wasted due to one erroneous space in a single line added by an unnecessary edit.

 2022-12-05, 00:50 #164 VBCurtis     "Curtis" Feb 2005 Riverside, CA 564010 Posts Why kill the original? We want to use those relations! Just changing sieve side means both sets of relations can be combined.
2022-12-05, 02:52   #165
swellman

Jun 2012

1111000010012 Posts

Quote:
 Originally Posted by VBCurtis Why kill the original? We want to use those relations! Just changing sieve side means both sets of relations can be combined.
Good point. Also the new job file does not seem to be producing results. Perhaps the relations on the old file can be downloaded before any other actions are taken. I fear the old job will have to deleted before the new version can produce clean relations despite the different file and job names as well as slightly differing content(?)

Greg - if you can please hold off deleting anything until Oliver and I can download the old relations file. From there I’m not sure where to go other than killing the old job.

 Similar Threads Thread Thread Starter Forum Replies Last Post VBCurtis NFS@Home 170 2023-01-02 15:27 swellman NFS@Home 186 2022-12-29 17:58 VBCurtis NFS@Home 154 2022-12-23 21:35 VBCurtis NFS@Home 254 2022-01-02 01:59 debrouxl NFS@Home 10 2018-05-06 21:05

All times are UTC. The time now is 08:21.

Sun Feb 5 08:21:47 UTC 2023 up 171 days, 5:50, 1 user, load averages: 0.97, 0.81, 0.87