Queue management for e_small and 15e queues - Page 8

VBCurtis · 2021-01-10, 03:18

QUEUED AS 13_2_875m1 on 15e_small

13*2^875-1 is ready for e-small:

Code:

n: 240866437725169990435961145869700978148638973131500627154459277995207161586111018965696779698382676903650395902770674542234980927906435470377593973397210397595151381518023436309800144471706314282870511294518800271
skew: 0.73
type: snfs
c6: 13
c0: -2
Y1: -1
Y0: 89202980794122492566142873090593446023921664
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 32
mfbr: 60
mfba: 93
rlambda: 2.7
alambda: 3.7

Q on the -r side from 20-160M should yield ~310M relations: (1kQ intervals tested)

Code:

#Q=20M  3208 rels, 0.251 sec/rel
#Q=50M  2650 rels, 0.255 sec/rel
#Q=80M  2100 rels, 0.352 sec/rel
#Q=110M 2295 rels, 0.384 sec/rel
#Q=140M 1995 rels, 0.428 sec/rel
#Q=170M 1537 rels, 0.343 sec/rel

I'd like to handle the matrix.

charybdis · 2021-01-10, 03:26

Quote:

Originally Posted by VBCurtis

I'm not quite sure how many relations to target- let's try for 500M first.
Q from 40-300M should get in the neighborhood: (1kQ ranges tested on -r side)

I'm very surprised if -r side is faster. Are you sure you didn't make an error when testing?

VBCurtis · 2021-01-10, 04:31

Edited (I thought initially you were talking about 13_2_875).
That may indeed be an error- I copied settings from a C185 and played with a couple lim and mfb settings, but didn't test -a.

If I get a good improvement using the other side, can the currently queued job be killed? It looks like it'll be a month before it sieves, but I dunno how the management controls work. I'll test the -a side overnight.

swellman · 2021-01-10, 12:41

The Aliquot 4788:12574 job has been queued but it can changed if necessary prior to starting sieving. I too questioned if sieving on the -r side of a GNFS job was really the intent but stranger things have happened. Meant to PM @VBCurtis to verify which side should be used but then RL interrupted.

As to 13*2^875-1, I will hold off enqueuing it until the parameters are confirmed.

VBCurtis · 2021-01-10, 19:29

Job C189_4788_12574 updated on 15e

Quote:

Originally Posted by charybdis

I'm very surprised if -r side is faster. Are you sure you didn't make an error when testing?

Testing on -a side has yield 10-15% better, and while sec/rel isn't directly comparable to my -r testing because different background tasks exist, I estimate -a is 20-25% faster than -r. That's a big whoops!

Corrected C189 aliquot 4788 settings:

Code:

n: 521522190388785541331160787195976801952432005240028067707250869703871311778809493591678394522430885815662329064194127806602359010987662524451917763292547675317210495917002745173292704484659
# norm 2.678191e-18 alpha -8.963268 e 2.857e-14 rroots 5
type: gnfs
skew: 87271318.89
c0: -6381367517597696742295702359937525488210006576
c1: 202288237039298283646164033232164328687
c2: 13346320611031566286558670660366
c3: -32289428163110989016897
c4: -1983739878858060
c5: 3603600
Y0: -3106799826410507065935794801180448266
Y1: 1970023755595084066583
rlim: 266000000
alim: 134000000
lpbr: 33
lpba: 32
mfbr: 63
mfba: 92
rlambda: 2.5
alambda: 3.5

I test-sieved 3LP on both a and r side, 32/33 reversed, and balanced lim's of 200/200. This combination yielded best.

Test-sieving on the -a side is a bit noisier for yield:
1kQ intervals tested; Let's try Q: 40M-260M to start? Estimated 500M rels needed.

Code:

#Q=40M	2672 rels, 0.299 sec/rel
#Q=70M	2236 rels, 0.318 sec/rel
#Q=100M 3200 rels, 0.395 sec/rel
#Q=130M 2282 rels, 0.446 sec/rel
#Q=160M 2152 rels, 0.482 sec/rel
#Q=190M 1971 rels, 0.472 sec/rel
#Q=220M 1743 rels, 0.476 sec/rel
#Q=250M 2765 rels, 0.378 sec/rel
#Q=280M 1784 rels, 0.393 sec/rel

charybdis · 2021-01-10, 21:53

Quote:

Originally Posted by VBCurtis

Test-sieving on the -a side is a bit noisier for yield:

This is to be expected in general. The noise in the yield comes from the number of special-q in a range deviating from the expectation. The number of special-q for a given prime is the number of roots of the polynomial (algebraic/rational as appropriate) modulo that prime. So on the -r side you just get one special-q for each prime, but on the -a side the number of roots varies from 0 to the degree of the poly though the average is still 1. This gives a fair bit more noise on the -a side.

We can use the Prime Number Theorem to get rid of this noise - this goes for the -r side too:
Calculate the yield per special-q using the number of special-q that the siever gives on the line

Code:

xxx Special q, yyy reduction iterations

Multiply this by C/log(Q) to get an estimate of yield in a range of length C around value Q.

chris2be8 · 2021-01-12, 16:49

QUEUED AS f15_214p1

(15^214+1)/22732825976092858 from the Brent tables:

Code:

# Built Mon Jan 11 17:16:42 2021
# Estimated SNFS difficulty 255, GNFS equivalent 185, GNFS difficulty 236, degree 6
n: 21226383702704470284297672536317375712518833555091354446533724171406254282667235101595281882269958782358801776580242580275543700366662745507116654826058612131880537225318956721108530915584785846944519273597131186910740973237434385947397
type: snfs
c6: 1
c0: 225
# Y0 = 15^36
Y0: 2184164409074570299708284437656402587890625
# Y1 = 1^0
Y1: 1
# msieve rating: skew 2.47, size 9.468e-13, alpha 1.979, combined = 1.149e-13 rroots = 0
skew: 2.47
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6
lss: 0

Sieve on 15e_small from 34M to 174M on the algebraic side.

Test sieving 10k ranges:

Code:

I'll do the LA.

Chris

chris2be8 · 2021-01-12, 16:53

Quote:

Originally Posted by charybdis

Multiply this by C/log(Q) to get an estimate of yield in a range of length C around value Q.

What base is that log to? I assume C/log(Q) is an estimate of how many primes there will be in that range. If so your post looks very useful.

Chris

charybdis · 2021-01-12, 17:15

Quote:

Originally Posted by chris2be8

What base is that log to? I assume C/log(Q) is an estimate of how many primes there will be in that range. If so your post looks very useful.

Chris

It's natural log. PNT says the probability that n is prime is ~1/log(n), so C/log(Q) is indeed the expected number of primes in the range.

jyb · 2021-01-13, 18:44

QUEUED AS 11m8_287 on 15e_small

SNFS-256.18 C238 HCN (11-8,287), ECM to t56+. Close call between 15e and 15e small.

Code:

n: 4193395358480086533437048773540367935071777413550194641716903549545943064931241232905118971150870758434976471524111103419133492347220200321929233540962166247437784611890289821560911694458974548805609413715451263199663891070038125246424287
# 11^287-8^287, difficulty: 256.18, skewness: 1.00, alpha: 2.24
skew: 1.000
c6: 1
c5: 1
c4: 1
c3: 1
c2: 1
c1: 1
c0: 1
Y1: -10633823966279326983230456482242756608
Y0: 4978518112499354698647829163838661251242411
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6

Trial sieving 2K blocks.

Code:

 Q		Yield
---		-----
20M		4971
50M		3981
80M		3291
110M		4012
140M		3174
170M		2773
200M		3109
230M		2622

Recommend sieving special Q on rational side, 20M - 165M.

VBCurtis · 2021-01-13, 19:55

Quote:

Originally Posted by jyb

QUEUED AS 11m8_287 on 15e_small

SNFS-256.18 C238 HCN (11-8,287), ECM to t56+. Close call between 15e and 15e small.

I think the long queue on 15e right now means this isn't a close call- we're still flying through these medium-sized jobs on e-small, while 15e is pretty backed up.

While the decision of where to send a job should remain fuzzy to try to keep any one queue from getting too long, I'd say that any job that sieves well at 134/134 lims with Q-range under 170M (say, 30-200M) is better on e-small than e from the viewpoint of keeping things moving.

One would expect in the medium term for the typical job to get tougher (since many projects work their way through smaller composites), so I doubt we'll get stricter on e-small as time goes on.

2021-01-10, 04:31	#80
VBCurtis "Curtis" Feb 2005 Riverside, CA 5²·11·17 Posts	Edited (I thought initially you were talking about 13_2_875). That may indeed be an error- I copied settings from a C185 and played with a couple lim and mfb settings, but didn't test -a. If I get a good improvement using the other side, can the currently queued job be killed? It looks like it'll be a month before it sieves, but I dunno how the management controls work. I'll test the -a side overnight. Last fiddled with by VBCurtis on 2021-01-10 at 16:04

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
System management notes	kriesel	kriesel	7	2020-10-21 18:52
Run down the queue on MPRIME without quitting GIMPS	Rodrigo	Software	7	2018-05-25 13:26
Improving the queue management.	debrouxl	NFS@Home	10	2018-05-06 21:05
split a prime95 queue & client installation	joblack	Information & Answers	1	2009-01-06 08:45
Power Management settings	PrimeCroat	Hardware	3	2004-02-17 19:11

2021-01-10, 12:41	#81
swellman Jun 2012 2961₁₀ Posts	The Aliquot 4788:12574 job has been queued but it can changed if necessary prior to starting sieving. I too questioned if sieving on the -r side of a GNFS job was really the intent but stranger things have happened. Meant to PM @VBCurtis to verify which side should be used but then RL interrupted. As to 13*2^875-1, I will hold off enqueuing it until the parameters are confirmed.