Fast Breeding (guru management) - Page 149

unconnected · 2018-09-12, 11:09

C162 from 785232:i11446 for 14e queue

Code:

n:  120200802921012037919315743851322324648338387287699183328099465615901872437571638375522676889046805645100018711742445165451122601438764030595100336427729254081173
# norm 1.265296e-15 alpha -6.802752 e 1.161e-12 rroots 5
skew: 27986273.62
c0: 36891961793113385651782128115039492790875
c1: 4229635392040346226271944154082037
c2: -260433884364123901182411245
c3: -22747677353174073699
c4: 489986750080
c5: 4452
Y0: -30638702839885683853466656422426
Y1: 218304098080241773
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
type: gnfs

Suggesting sieving range 20M-80M. I'll run LA for this number.

Max0526 · 2018-09-12, 15:03

Quote:

Originally Posted by unconnected

C162 from 785232:i11446 for 14e queue

Code:

n:  120200802921012037919315743851322324648338387287699183328099465615901872437571638375522676889046805645100018711742445165451122601438764030595100336427729254081173
# norm 1.265296e-15 alpha -6.802752 e 1.161e-12 rroots 5
skew: 27986273.62
c0: 36891961793113385651782128115039492790875
c1: 4229635392040346226271944154082037
c2: -260433884364123901182411245
c3: -22747677353174073699
c4: 489986750080
c5: 4452
Y0: -30638702839885683853466656422426
Y1: 218304098080241773
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
type: gnfs

Suggesting sieving range 20M-80M. I'll run LA for this number.

A spinned-up poly with better E and surprising c5 (don't ask) for the above number:

Code:

Y0: -61277405373647460442775718918866
Y1: 218304098080241773
c0: 75543047841236298206569254372418080145020
c1: 9811299947071811429889849748908030
c2: -613642512052347317677082674
c3: -21351592179214966459
c4: 252797074370
c5: 1113
skew: 50937101.01
# size 1.144e-15, alpha -7.755, combined = 1.248e-12 rroots = 5

RichD · 2018-09-12, 15:48

C240 from the MWRB file with OPN weight of 6720 for the 15e queue.

Code:

n: 744822874420876233458923367945655307569152801862856562088507501346332816800292929072183589933446057869501960576430008108565773799257456260338665041117688020503279438090005561266763646471131309343423234949252179748225431168342729615301426721
# 4603759^37-1, difficulty: 247
skew: 0.0775
c6: 4603759
c0: -1
Y1: -1
Y0: 9520844789294346565511217928502073721441
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7

Trial sieving 5K blocks.

Code:

debrouxl · 2018-09-12, 20:30

Although it would be slightly less efficient than using 15e, a 31-bit LPs task of SNFS difficulty 247 would help filling the 14e queue.
But both queues are still broken anyway...

RichD · 2018-09-12, 20:46

This is definitely a 32-bit job if parameterized for the 14e queue. I was surprised how easy it worked as a 31-bit for 15e.

Edit: The best I could squeeze in 14e was 134/200 31/91a/3.6. The yield at 60M was 1.36. The kick in the pants is the seven digit coefficient.

RichD · 2018-09-13, 01:38

C231 from the MWRB file with an OPN weight of 4176 (for 14e).

Code:

n: 589470085638367943192974599027279943093828364938148311581636494878437898852030929478021141792049865392682126799756097273338295662495810826408804300923625102363936591501031429807074638456784409369277395132979916609500313986538937941
# 27409^53-1, difficulty: 239.65, skewness: 5.49, alpha: 0.00
# cost: 3.72874e+18, est. time: 1775.59 GHz days (not accurate yet!)
skew: 5.491
c6: 1
c0: -27409
Y1: -1
Y0: 8730491982047459268817962922083396659089
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6

Trial sieving 5K blocks.

Code:

VBCurtis · 2018-09-13, 05:42

13*2^860-1 is ready for the 14e queue:
EDIT: One should check ECM results file before posting to the queue. 13,860 has a P54 found by the last round of ECM (B1=650M).

unconnected · 2018-09-13, 09:44

Poly from Max for C162 is clearly better (at least by 10% according to test-sieve) than my, so lets use it.

Code:

n: 120200802921012037919315743851322324648338387287699183328099465615901872437571638375522676889046805645100018711742445165451122601438764030595100336427729254081173
Y0: -61277405373647460442775718918866
Y1: 218304098080241773
c0: 75543047841236298206569254372418080145020
c1: 9811299947071811429889849748908030
c2: -613642512052347317677082674
c3: -21351592179214966459
c4: 252797074370
c5: 1113
skew: 50937101.01
# size 1.144e-15, alpha -7.755, combined = 1.248e-12 rroots = 5
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
type: gnfs

Corrected sieving range is 15M-70M.

VictordeHolland · 2018-09-14, 00:11

For the OPN numbers, can we please keep the filenames on the server and the displaynames on the statuspage as recognisable as possible? (see what happened in the 14e)

My personal preference is the C200_1234567_89 names and not the Phi123/Phi45/6789 etc names.

Just my 2 cents

debrouxl · 2018-09-14, 14:17

In fact, the 14e management Web interface automatically copies the field containing the "name", used for filenames, to the field containing the "display name". In RSALS times, as well as for more than the first half of NFS@Home's 14e activity so far, the name and the display name matched.

We could ask Greg to modify several lines in crunching.php and crunching_e.php so that the "Now sieving", "Queued for post processing" and "Post processing" tables contain the (currently missing) name and the (currently displayed) display name.
How does that sound ?

EDIT:
* I have created 14e entries for the numbers since post #1623;
* Rich, could you double-check that what you meant in #1631 + #1633 was:

Code:

n: 744822874420876233458923367945655307569152801862856562088507501346332816800292929072183589933446057869501960576430008108565773799257456260338665041117688020503279438090005561266763646471131309343423234949252179748225431168342729615301426721
# 4603759^37-1, difficulty: 247
skew: 0.0775
c6: 4603759
c0: -1
Y1: -1
Y0: 9520844789294346565511217928502073721441
type: snfs
rlim: 134000000
alim: 2004000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 97
rlambda: 3.6
alambda: 3.6

* Sean, could you double-check the polys I entered ?
* tomorrow, I should be able to enter http://stdkmd.com/nrr/c.cgi?q=50009_239 into the 14e queue, unless my 16 GMP-ECM instances running curves at B1=43e6 find an unlikely factor by then.

TIA.

RichD · 2018-09-14, 22:29

Quote:

Originally Posted by RichD

The best I could squeeze in 14e was 134/200 31/91a/3.6.

What I meant by this is the following, meaning 3LP on the -a side.

Code:

rlim: 134000000
alim: 200000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 91
rlambda: 2.6
alambda: 3.6

I used most tricks to squeeze out more yield but couldn't get a decent yield. I am not too familiar with 32-bit jobs or 15e jobs unless they fall out nicely. That is why I try to avoid them. I guess this is the place to seek assistance. I was going to shelve this number (for now) because other potential 32-bit jobs were more important in the food chain. :-)

2018-09-12, 20:46	#1633
RichD Sep 2008 Kansas 2²·3²·7·13 Posts	This is definitely a 32-bit job if parameterized for the 14e queue. I was surprised how easy it worked as a 31-bit for 15e. Edit: The best I could squeeze in 14e was 134/200 31/91a/3.6. The yield at 60M was 1.36. The kick in the pants is the seven digit coefficient. Last fiddled with by RichD on 2018-09-12 at 21:03

2018-09-13, 05:42	#1635
VBCurtis "Curtis" Feb 2005 Riverside, CA 2·3·19·41 Posts	132^860-1 is ready for the 14e queue: EDIT: One should check ECM results file before posting to the queue. 13,860 has a P54 found by the last round of ECM (B1=650M). Last fiddled with by VBCurtis on 2018-09-13 at 05:50*

2018-09-14, 14:17	#1638
debrouxl Sep 2009 977 Posts	In fact, the 14e management Web interface automatically copies the field containing the "name", used for filenames, to the field containing the "display name". In RSALS times, as well as for more than the first half of NFS@Home's 14e activity so far, the name and the display name matched. We could ask Greg to modify several lines in crunching.php and crunching_e.php so that the "Now sieving", "Queued for post processing" and "Post processing" tables contain the (currently missing) name and the (currently displayed) display name. How does that sound ? EDIT: * I have created 14e entries for the numbers since post #1623; * Rich, could you double-check that what you meant in #1631 + #1633 was: Code: n: 744822874420876233458923367945655307569152801862856562088507501346332816800292929072183589933446057869501960576430008108565773799257456260338665041117688020503279438090005561266763646471131309343423234949252179748225431168342729615301426721 # 4603759^37-1, difficulty: 247 skew: 0.0775 c6: 4603759 c0: -1 Y1: -1 Y0: 9520844789294346565511217928502073721441 type: snfs rlim: 134000000 alim: 2004000000 lpbr: 31 lpba: 31 mfbr: 62 mfba: 97 rlambda: 3.6 alambda: 3.6 * Sean, could you double-check the polys I entered ? * tomorrow, I should be able to enter http://stdkmd.com/nrr/c.cgi?q=50009_239 into the 14e queue, unless my 16 GMP-ECM instances running curves at B1=43e6 find an unlikely factor by then. TIA. Last fiddled with by debrouxl on 2018-09-14 at 14:55

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

2018-09-12, 20:30	#1632
debrouxl Sep 2009 1721₈ Posts	Although it would be slightly less efficient than using 15e, a 31-bit LPs task of SNFS difficulty 247 would help filling the 14e queue. But both queues are still broken anyway...

2018-09-14, 00:11	#1637
VictordeHolland "Victor de Hollander" Aug 2011 the Netherlands 10010011000₂ Posts	For the OPN numbers, can we please keep the filenames on the server and the displaynames on the statuspage as recognisable as possible? (see what happened in the 14e) My personal preference is the C200_1234567_89 names and not the Phi123/Phi45/6789 etc names. Just my 2 cents