Fast Breeding (guru management) - Page 6

pinhodecarlos · 2015-03-14, 21:26

Quote:

Originally Posted by xilman

20 projects now added, all in the "QUEUED for SIEVING" state. Someone please check that I've not screwed up too badly.

Dinner was sirloin steak, chips (fries for our North American readers), fried onions and a green salad. And freshly made English mustard, something which appears to be largely unavailable outside the UK. I thought you might to know all that, though it's barely relevant to the project in question.

Paul

From outside seems Ok.
The only healthy food I see in there is the green salad. You British don't know how to eat....oh well...

EDIT: Not sure if we have enough 15e wu's....just trying to read teams strategies...

debrouxl · 2015-03-15, 12:28

I've noticed that a "GC_8_264b" entry appeared, but 264*8^264+1 was already sieved by NFS@Home, post-processed by Ben Meekins, and it's already in FactorDB.

frmky · 2015-03-15, 18:16

Quote:

Originally Posted by debrouxl

I've noticed that a "GC_8_264b" entry appeared, but 264*8^264+1 was already sieved by NFS@Home, post-processed by Ben Meekins, and it's already in FactorDB.

Good catch! Now gone.

wblipp · 2015-03-15, 19:39

The 14e queue now has plenty of numbers in the "queued" category, but it is ALMOST EMPTY in the "Now Sieving" category. If I understand correctly, somebody needs to take manual action within the next hour or two to promote some of these from "queued" to "now sieving."

frmky · 2015-03-15, 20:20

Another issue... 5297_67_minus1 actually has the poly for 5347_67_minus1, so I'm canceling those as well. We don't want to factor 5347_67_minus1 twice.

Edit: Whoever relists it, please add a b on the end of the name. Otherwise, the code will pull the old polynomial.

xilman · 2015-03-15, 20:24

Quote:

Originally Posted by wblipp

The 14e queue now has plenty of numbers in the "queued" category, but it is ALMOST EMPTY in the "Now Sieving" category. If I understand correctly, somebody needs to take manual action within the next hour or two to promote some of these from "queued" to "now sieving."

Just added a few more. Looks like plenty to me but what do I know?

pinhodecarlos · 2015-03-15, 20:28

Quote:

Originally Posted by xilman

Just added a few more. Looks like plenty to me but what do I know?

Don't panic....more cores to come...

frmky · 2015-03-15, 20:31

Also, what's up with W_811? It's showing 0% pushed but 5000 pending. What's the history there?

jyb · 2015-03-26, 22:32

Forgive me if this is not the appropriate way to go about this (in which case I would appreciate if someone could acquaint me with the proper protocol). I have five composites to propose for the 14e queue. These are all Homogeneous Cunningham Numbers (HCN), with an SNFS difficulty of approximately 249. They have all had about 10000 ECM curves with B1 = 110e6.

The numbers are 7^293-2^293, 7^293-3^293, 7^293-6^293, 7^293+2^293 and 7^293+4^293. SNFS polynomials are given here:

Code:

# 7^293-2^293
n: 230794479162374911687302426873820257732779444487576515134909693519341884488802484164788614233092736526644942326338845815313844026183214970808465053738686753637441995635614126555710139922867
skew: 1.232
c6: 2
c0: -7
Y1: -562949953421312
Y0: 256923577521058878088611477224235621321607



# 7^293-3^293
n: 17499580246118405874993172957411695279591166940037925712203477758854043580088036110459568010211040628766179691677104521101517020733336889431616766615294801446600593877558003253022255193871443471671368800364743471307111208191637302126634956597383
skew: 1.152
c6: 3
c0: -7
Y1: -239299329230617529590083
Y0: 256923577521058878088611477224235621321607



# 7^293-6^293
n: 11181916252973694378702587676957099344694241133064986763164582617460656925566371354102957133074436476641849917193888433318609673772327546259620783239703290182835875201186351190018004437
skew: 1.026
c6: 6
c0: -7
Y1: -134713546244127343440523266742756048896
Y0: 256923577521058878088611477224235621321607



# 7^293+2^293
n: 3037655597342145978693848383968702238029362433616790685423261087483365835487201678838065275089770928014751357465933388095402515340306355162806189391396131986686617675978548793427127152610078048943228565057122555233
# 7^293+2^293, difficulty: 248.76, skewness: 1.23, alpha: 0.00
# cost: 7.5527e+18, est. time: 3596.53 GHz days (not accurate yet!)
skew: 1.232
c6: 2
c0: 7
Y1: -562949953421312
Y0: 256923577521058878088611477224235621321607



# 7^293+4^293
n: 601093917276153811914098939276468094649006283190930551360274537612751749735322482173532584625324709159366517784933234531000069456442104185783512942257910069496918374716840734950624570191847592405857123534193329747236559639324139
# 7^293+4^293, difficulty: 249.06, skewness: 1.10, alpha: 0.00
# cost: 7.7288e+18, est. time: 3680.38 GHz days (not accurate yet!)
skew: 1.098
c6: 4
c0: 7
Y1: -316912650057057350374175801344
Y0: 256923577521058878088611477224235621321607

fivemack · 2015-03-29, 09:15

This is the right place to ask; however, there is something of a policy question here.

I thought the homogeneous Cunningham numbers were intended to be problems of a size that individuals could reasonably run, at which point it makes sense to leave the bigger ones until Moore's Law gets bigger computers into individuals' hands rather than to convert the high-hanging fruit of the HCN project into low-hanging fruit for the cloud.

Also the queue is now long enough that, if your resources amount to one quad-core, you'd still get the first answer quicker if you started sieving now rather than adding it to the queue now. I sieved 11^239-5^239 locally eighteen months ago, it took 18000 thread-hours on a fairly slow machine.

debrouxl · 2015-03-30, 13:44

I had pretty much reserved these numbers for NFS@Home's 14e before the March challenge on NFS@Home, in case clients depleted our queue very quickly.
In the end, clients didn't make such a big dent into the queue, but the numbers kept being reserved, and a decent amount of ECM work was run on them, especially by jyb. Therefore, I think that the least I can now do is to queue most of them to NFS@Home's 14e (though I'm currently swamped by a combination of day job and free time work related to what made me factor large integers in the first place, namely TI graphing calculators)

But you're of course right that the first WUs for the first Homogeneous Cunningham number are still a significant ways off reaching clients, unless the numbers are queued out of order.

2015-03-15, 19:39	#59
wblipp "William" May 2003 New Haven 2×7×13² Posts	14e Almost Empty The 14e queue now has plenty of numbers in the "queued" category, but it is ALMOST EMPTY in the "Now Sieving" category. If I understand correctly, somebody needs to take manual action within the next hour or two to promote some of these from "queued" to "now sieving."

2015-03-15, 20:20	#60
frmky Jul 2003 So Cal 2⁴×7×19 Posts	Another issue... 5297_67_minus1 actually has the poly for 5347_67_minus1, so I'm canceling those as well. We don't want to factor 5347_67_minus1 twice. Edit: Whoever relists it, please add a b on the end of the name. Otherwise, the code will pull the old polynomial. Last fiddled with by frmky on 2015-03-15 at 20:22

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

2015-03-15, 12:28	#57
debrouxl Sep 2009 1111010001₂ Posts	I've noticed that a "GC_8_264b" entry appeared, but 264*8^264+1 was already sieved by NFS@Home, post-processed by Ben Meekins, and it's already in FactorDB.

2015-03-15, 20:31	#63
frmky Jul 2003 So Cal 2⁴×7×19 Posts	Also, what's up with W_811? It's showing 0% pushed but 5000 pending. What's the history there?

2015-03-29, 09:15	#65
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 2³×11×73 Posts	This is the right place to ask; however, there is something of a policy question here. I thought the homogeneous Cunningham numbers were intended to be problems of a size that individuals could reasonably run, at which point it makes sense to leave the bigger ones until Moore's Law gets bigger computers into individuals' hands rather than to convert the high-hanging fruit of the HCN project into low-hanging fruit for the cloud. Also the queue is now long enough that, if your resources amount to one quad-core, you'd still get the first answer quicker if you started sieving now rather than adding it to the queue now. I sieved 11^239-5^239 locally eighteen months ago, it took 18000 thread-hours on a fairly slow machine.

2015-03-30, 13:44	#66
debrouxl Sep 2009 977 Posts	I had pretty much reserved these numbers for NFS@Home's 14e before the March challenge on NFS@Home, in case clients depleted our queue very quickly. In the end, clients didn't make such a big dent into the queue, but the numbers kept being reserved, and a decent amount of ECM work was run on them, especially by jyb. Therefore, I think that the least I can now do is to queue most of them to NFS@Home's 14e (though I'm currently swamped by a combination of day job and free time work related to what made me factor large integers in the first place, namely TI graphing calculators) But you're of course right that the first WUs for the first Homogeneous Cunningham number are still a significant ways off reaching clients, unless the numbers are queued out of order.