2022 Queue management of 15e - Page 15

RichD · 2022-11-13, 23:42

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.

RichD · 2022-11-13, 23:47

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.

swellman · 2022-11-14, 19:52

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.

kruoli · 2022-12-04, 18:14

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?

frmky · 2022-12-04, 19:01

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.

VBCurtis · 2022-12-04, 19:22

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.

swellman · 2022-12-04, 21:02

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

frmky · 2022-12-04, 21:33

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).

swellman · 2022-12-04, 22:15

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.

VBCurtis · 2022-12-05, 00:50

Why kill the original? We want to use those relations! Just changing sieve side means both sets of relations can be combined.

swellman · 2022-12-05, 02:52

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.

2022-12-04, 19:01	#159
frmky Jul 2003 So Cal 2,621 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.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Queue management for 14e queue	VBCurtis	NFS@Home	170	2023-01-02 15:27
2022 - queue management for 15e_small	swellman	NFS@Home	186	2022-12-29 17:58
Queue management for 16e queue	VBCurtis	NFS@Home	154	2022-12-23 21:35
Queue management for e_small and 15e queues	VBCurtis	NFS@Home	254	2022-01-02 01:59
Improving the queue management.	debrouxl	NFS@Home	10	2018-05-06 21:05

2022-12-04, 19:22	#160
VBCurtis "Curtis" Feb 2005 Riverside, CA 165D₁₆ 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-05, 00:50	#164
VBCurtis "Curtis" Feb 2005 Riverside, CA 5²×229 Posts	Why kill the original? We want to use those relations! Just changing sieve side means both sets of relations can be combined.