2022 - queue management for 15e_small - Page 13

swellman · 2022-10-03, 15:49

5+4,379 is finishing ECM and ready for sieving on 15e_small.

Code:

n: 3227464012291430059925006429562736991742298035759577233584692341821292441570236308011326741949434905019800801415529473954432475829344916657228646963082311859555305850721203301368804259023792913517484069189403446498547
skew: 0.9635
type: snfs
size: 2654
c6: 5
c0: 4
Y1: -85070591730234615865843651857942052864
Y0: 108420217248550443400745280086994171142578125
rlim: 134000000
alim: 266000000
lpbr: 31
lpba: 31
mfbr: 91
mfba: 62
rlambda: 3.5
alambda: 2.3

Results of test sieving on the rational side with Q in blocks of 1000:

Code:

MQ       Norm_yield
35          2236
50          2038
75          1799
100         1653
150         1388
200         1273

Suggesting a sieving range for Q of 35-195M to generate 260M raw relations.

VBCurtis · 2022-10-04, 00:14

e-small should not be 134/266M lims.

Should we loosen e-small to 134/180M to make it easier to get some medium-sized jobs onto e-small? Does 134/180 still require low-enough RAM?

swellman · 2022-10-04, 00:47

Quote:

Originally Posted by VBCurtis

e-small should not be 134/266M lims.

D’oh! I’ll change it and retest. Again…

Quote:

Should we loosen e-small to 134/180M to make it easier to get some medium-sized jobs onto e-small? Does 134/180 still require low-enough RAM?

Fine with me, but don’t suggest this policy change just because of my repeated muck-ups.

In all seriousness, expanding the limit range for 15e_small will allow more now borderline jobs into the small queue but no idea how many more. How about shifting the lim values on a trial basis?

swellman · 2022-10-04, 14:24

Well it turns out this particular job is a nice edge case example. I have changed both lims to 134M and retested. Results follow:

Code:

MQ       Norm_yield
35          1987
50          1806
75          1577
100         1457
150         1206
205         1092

Which, when using the full q range (35-205M), generates 238M raw relations. A little light but it should build a feasible matrix.

If a few more rels are desired, I could run this job as a 32/31 with both lims at 134M. It’s likely to generate close to 360M relations, certainly more than enough to build a good matrix. This stays within the current 15e_small guidelines.

OR we could raise one lim to 180M as suggested by Mike.

Or keep the lims=134M in place but increase the max allowable q range to 175 or 180M.

Thoughts?

VBCurtis · 2022-10-04, 15:27

32/31 is clearly a good idea here, as it reduces the Q-range needed by 10M or so; your listed Q-range ought to build a smaller matrix on 32/31 than 31/31, or you can reduce Qmax by 5M. If you also run with 134/180 lims, you can definitely reduce Q.

I think raising lims to 134/180 is faster for these biggish jobs than just increasing Q-range. As a policy choice, I'd rather increase lim than increase Q-range by a bunch- we should encourage the most-efficient params possible. I do think allowing a bit larger Q's is okay, too, like Qmax - Qmin = 200M as a hard cap.

swellman · 2022-10-04, 19:01

Quote:

Originally Posted by VBCurtis

32/31 is clearly a good idea here, as it reduces the Q-range needed by 10M or so; your listed Q-range ought to build a smaller matrix on 32/31 than 31/31, or you can reduce Qmax by 5M. If you also run with 134/180 lims, you can definitely reduce Q.

I think raising lims to 134/180 is faster for these biggish jobs than just increasing Q-range. As a policy choice, I'd rather increase lim than increase Q-range by a bunch- we should encourage the most-efficient params possible. I do think allowing a bit larger Q's is okay, too, like Qmax - Qmin = 200M as a hard cap.

So to summarize the updated guidelines:

- Max lim is 180M, max sum 314M
- Qmax - Qmin = 200M max
- If any doubt, use 15e

VBCurtis · 2022-10-05, 06:20

QUEUED AS 5_2_799m1

5*2^799-1 is ready for e-small:

Code:

n: 79651104085496806147989601004834247853520217010018278499254324737035613207807596125911433334131437481727456670507064366237945279800818216511769193230913526816083910575352449333506721702114369964961192163
type: snfs
skew: 0.70
c6: 10
c0: -1
Y1: -1
Y0: 10889035741470030830827987437816582766592
rlim: 100000000
alim: 36000000
lpbr: 32
lpba: 31
mfbr: 61
mfba: 59
rlambda: 2.4
alambda: 2.75

Test-sieving 1kq blocks on the -a side indicate Q from 7-45M is enough for ~270M relations. I don't know if this is enough to build a matrix with these weird parameters, but that's part of the fun of trying new things!

Code:

#Q=8M	8784 (0.031 sec/rel) 74 spq
#Q=10M	7220 (0.034 sec/rel) 66 spq
#Q=20M	7852 (0.035 sec/rel) 70 spq
#Q=30M	7657 (0.039 sec/rel) 74 spq
#Q=40M	5951 (0.045 sec/rel) 66 spq

swellman · 2022-10-05, 18:24

Retested 5+4,379 using the new guidelines for 15e_small.

Code:

n: 3227464012291430059925006429562736991742298035759577233584692341821292441570236308011326741949434905019800801415529473954432475829344916657228646963082311859555305850721203301368804259023792913517484069189403446498547
skew: 0.9635
type: snfs
size: 264
c6: 5
c0: 4
Y1: -85070591730234615865843651857942052864
Y0: 108420217248550443400745280086994171142578125
rlim: 134000000
alim: 180000000
lpbr: 32
lpba: 31
mfbr: 94
mfba: 62
rlambda: 3.55
alambda: 2.3

Results of test sieving on the rational side with Q in blocks of 1000:

Code:

MQ       Norm_yield
35          2980
50          2743
75          2459
100         2288
150         1898
200         1670

Suggesting a sieving range for Q of 35-190M to generate 350M raw relations.

It’s likely heavier than necessary with 350M relations but I wanted to put this one to bed with no more fuss.

VBCurtis · 2022-10-06, 15:58

Quote:

Originally Posted by VBCurtis

QUEUED AS 5_2_799m1

5*2^799-1 is ready for e-small:

Test-sieving 1kq blocks on the -a side indicate Q from 7-45M is enough for ~270M relations. I don't know if this is enough to build a matrix with these weird parameters, but that's part of the fun of trying new things!

My lazy "who needs to normalize test-sieve counts?" paid off with actual ~233M relations rather than the 260-270M hoped for. May I have another 6MQ?

Done.

RichD · 2022-10-10, 18:51

QUEUED AS 184__317_5m1

C202 from the OPN t800 file.

Code:

n: 4818416278825822717497859692828421388802563630175271905759341256352812529492654404845202794321322290679534875569470111642299528753756998827806737170224794228509957129099577524259218437279299198369331621
# 18476667209739417836226575582820864051602717104805244317^5-1, difficulty: 221.07, skewness: 1.00, alpha: 1.45
# cost: 8.39945e+17, est. time: 399.97 GHz days (not accurate yet!)
skew: 1.000
c4: 1
c3: 1
c2: 1
c1: 1
c0: 1
Y1: -1
Y0: 18476667209739417836226575582820864051602717104805244317
type: snfs
rlim: 67000000
alim: 67000000
lpbr: 31
lpba: 31
mfbr: 90
mfba: 62
rlambda: 3.5
alambda: 2.7

Trial sieving 2K blocks.

Code:

  Q  Yield N-Yld
 20M  6686  7467
 50M  8561  9027
 80M  7484  8658
 84M  9093  8447

VBCurtis · 2022-10-11, 01:55

QUEUED AS 5_2_800m1

5*2^800-1 is ready for e-small:

Code:

n: 130077498246834412217011031357798188997761545728948997722507355083431588378275973104054810489044049128426861721513906631880558292940513942222844911571935690010245798204840818076635662297462702794562830888316589670461306523879
type: snfs
skew: 0.61
c6: 20
c0: -1
Y1: -1
Y0: 10889035741470030830827987437816582766592
rlim: 100000000
alim: 42000000
lpbr: 32
lpba: 31
mfbr: 61
mfba: 59
rlambda: 2.4
alambda: 2.65

Test-sieving 1kQ blocks on the -a side suggest Q from 7-55M is sufficient for 250-260M relations:

Code:

#Q=10M	7921 (0.039 sec/rel) 76 spq
#Q=20M	7258 (0.042 sec/rel) 72 spq
#Q=30M	4343 (0.051 sec/rel) 50 spq
#Q=40M	3576 (0.052 sec/rel) 40 spq
#Q=50M	6021 (0.056 sec/rel) 74 spq
#Q=60M	3989 (0.059 sec/rel) 52 spq

I will handle the matrix.

2022-10-04, 14:24	#136
swellman Jun 2012 3991₁₀ Posts	5+4,379 Well it turns out this particular job is a nice edge case example. I have changed both lims to 134M and retested. Results follow: Code: MQ Norm_yield 35 1987 50 1806 75 1577 100 1457 150 1206 205 1092 Which, when using the full q range (35-205M), generates 238M raw relations. A little light but it should build a feasible matrix. If a few more rels are desired, I could run this job as a 32/31 with both lims at 134M. It’s likely to generate close to 360M relations, certainly more than enough to build a good matrix. This stays within the current 15e_small guidelines. OR we could raise one lim to 180M as suggested by Mike. Or keep the lims=134M in place but increase the max allowable q range to 175 or 180M. Thoughts?

2022-10-04, 15:27	#137
VBCurtis "Curtis" Feb 2005 Riverside, CA 2·3²·17·19 Posts	32/31 is clearly a good idea here, as it reduces the Q-range needed by 10M or so; your listed Q-range ought to build a smaller matrix on 32/31 than 31/31, or you can reduce Qmax by 5M. If you also run with 134/180 lims, you can definitely reduce Q. I think raising lims to 134/180 is faster for these biggish jobs than just increasing Q-range. As a policy choice, I'd rather increase lim than increase Q-range by a bunch- we should encourage the most-efficient params possible. I do think allowing a bit larger Q's is okay, too, like Qmax - Qmin = 200M as a hard cap. Last fiddled with by VBCurtis on 2022-10-04 at 15:28

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 of 15e	swellman	NFS@Home	186	2022-12-27 12:53
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-10-04, 00:14	#134
VBCurtis "Curtis" Feb 2005 Riverside, CA 16B6₁₆ Posts	e-small should not be 134/266M lims. Should we loosen e-small to 134/180M to make it easier to get some medium-sized jobs onto e-small? Does 134/180 still require low-enough RAM?