Fast Breeding (guru management) - Page 82

swellman · 2017-01-26, 21:48

Quote:

Originally Posted by RichD

Another one apparently missed is this post. Plus, one of the "n" numbers is wrong.

I think your link is pointing to the wrong place. Which post are you talking about? And which "n"? I think it's all been fixed but let me know.

RichD · 2017-01-26, 21:53

Quote:

Originally Posted by swellman

I think your link is pointing to the wrong place. Which post are you talking about? And which "n"? I think it's all been fixed but let me know.

The "n" in the 15e queue.

Edit: C187_141_61 to be exact. The "n" is a C237.

swellman · 2017-01-26, 23:09

Quote:

Originally Posted by RichD

The "n" in the 15e queue.

Edit: C187_141_61 to be exact. The "n" is a C237.

Indeed, the n is the old incorrect value in the poly and ini files for C187_141_61 on 15e. It should be

Code:

5084489050566775179592003313348801937179533477099429174053297255387060223505309107949313623243535576335735180641443792678300621272851343104861268721864517835102764733898119986107069118573

The matter was discussed here. The correction was never implemented when it was enqueued.

Can a gatekeeper please make the correction for C187_141_61? Thanks.

RichD · 2017-01-28, 16:18

This OPN is ready and comes from the t490 file.

63601^47-1 (C190) SNFS-231

wombatman · 2017-01-28, 20:36

If a C150 isn't too small for 14e, please consider the following for HP2(4496) Index 308:

Code:

n: 186268686335827877320004854432051878822128838126242537957264027670795037255662305248760790177888122105986774051056721859678174962268961805642675348313
c5: 4296600
c4: -2917007031510
c3: -4790076774663310507
c2: 1670064884437700063934274
c1: 554651519036985580252614263896
c0: 35031679686473547988714210631764400
Y1: 481307053823461
Y0: -33682396687270334451539720481
skew: 542112.99 
rlim: 20800000
alim: 10399999
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.6
alambda: 2.6

Everything after skew was set automatically based on the factmsieve.py choices.

Max0526 · 2017-01-29, 23:53

@wombatman
After CADO optimization:

Code:

Y0: -33682396661918448005496559228
Y1: 481307053823461
c0: 24457818467628788035786542630926349
c1: 386035412486131568983076678246
c2: 870862274534921302685050
c3: -5285460019326801427
c4: -1785432972510
c5: 4296600
skew: 484727.35042
# alpha -6.66, 5 real roots
# MurphyE=5.80851238e-12

jyb · 2017-01-31, 20:23

Quote:

Originally Posted by wombatman

If a C150 isn't too small for 14e, please consider the following for HP2(4496) Index 308:

My personal opinion is that a C150 is too small for NFS@Home. That's firmly in the realm of numbers which can be factored by individuals on personal hardware. However, I don't have any desire to assert my own will on others in this matter, so can anybody provide a compelling contrary opinion?

VBCurtis · 2017-01-31, 20:32

A C150 is in the vicinity of 60 Ghz-days, under a week for a quad-core. If I had a vote, I'd set 158 as the bottom for GNFS.

wombatman · 2017-01-31, 20:35

Quote:

Originally Posted by jyb

My personal opinion is that a C150 is too small for NFS@Home. That's firmly in the realm of numbers which can be factored by individuals on personal hardware. However, I don't have any desire to assert my own will on others in this matter, so can anybody provide a compelling contrary opinion?

No worries. I figured I would ask and see what the bottom limit was. I'll go ahead and start it on personal hardware! Thanks for the consideration

swellman · 2017-01-31, 23:18

C197_148_45 looks like a good 14e candidate and it has seen a full t55, but it's yield is not great unless 32-bit LP is used in sieving (or 31-bit and lots of patience). Otherwise it's an easy 15e/31 job. I'm not a fan of 14e/32 jobs but they are doable. I'll sign up to postprocess it regardless of siever used.

Otherwise the next unequivocal 14e candidate for the xyyx project is 2-3 weeks away.

The old "feed the grid or use it most efficiently" quandry.

(I'll have post the poly tomorrow. I don't have access to my files tonight.)

RichD · 2017-02-01, 02:02

I have a few OPNs to keep the grid going. These are not as significant as others because they all come from the t800 file. Perhaps keep these on the back shelf and when one is needed, queue it right before the grid runs dry. Feel free to add other numbers before these when applicable. These are about SNFS-235 +/-.

P40.15461_7M.C186
1546180993982253931724756630608282852337^7-1
P40.12838_7M.C181
1283810768507270931382867729773882314783^7-1
P39.83661_7M.C179
836611965227956085219418549834729037351^7-1

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
System management notes	kriesel	kriesel	7	2020-10-21 18:52
Improving the queue management.	debrouxl	NFS@Home	10	2018-05-06 21:05
Script-based Primenet assignment management	ewmayer	Software	3	2017-05-25 04:02
Do normal adults give themselves an allowance? (...to fast or not to fast - there is no question!)	jasong	jasong	35	2016-12-11 00:57
Power Management settings	PrimeCroat	Hardware	3	2004-02-17 19:11

2017-01-28, 16:18	#895
RichD Sep 2008 Kansas 110100111011₂ Posts	This OPN is ready and comes from the t490 file. 63601^47-1 (C190) SNFS-231

2017-01-31, 20:32	#899
VBCurtis "Curtis" Feb 2005 Riverside, CA 1001100000100₂ Posts	A C150 is in the vicinity of 60 Ghz-days, under a week for a quad-core. If I had a vote, I'd set 158 as the bottom for GNFS.

2017-01-31, 23:18	#901
swellman Jun 2012 3,089 Posts	C197_148_45 looks like a good 14e candidate and it has seen a full t55, but it's yield is not great unless 32-bit LP is used in sieving (or 31-bit and lots of patience). Otherwise it's an easy 15e/31 job. I'm not a fan of 14e/32 jobs but they are doable. I'll sign up to postprocess it regardless of siever used. Otherwise the next unequivocal 14e candidate for the xyyx project is 2-3 weeks away. The old "feed the grid or use it most efficiently" quandry. (I'll have post the poly tomorrow. I don't have access to my files tonight.)

2017-02-01, 02:02	#902
RichD Sep 2008 Kansas 110100111011₂ Posts	I have a few OPNs to keep the grid going. These are not as significant as others because they all come from the t800 file. Perhaps keep these on the back shelf and when one is needed, queue it right before the grid runs dry. Feel free to add other numbers before these when applicable. These are about SNFS-235 +/-. P40.15461_7M.C186 1546180993982253931724756630608282852337^7-1 P40.12838_7M.C181 1283810768507270931382867729773882314783^7-1 P39.83661_7M.C179 836611965227956085219418549834729037351^7-1