Fast Breeding (guru management) - Page 23

debrouxl · 2015-09-24, 19:47

Sure, having a backlog of usable numbers, without depleting the queue of a single project, is always nice

I suppose that these six numbers should all be receiving a second t50, then maybe some more if they sieve especially slowly, like C175_142_39 (still under ECM by my local, temporary cluster) ?

swellman · 2015-09-24, 21:52

Quote:

Originally Posted by debrouxl

Sure, having a backlog of usable numbers, without depleting the queue of a single project, is always nice

I suppose that these six numbers should all be receiving a second t50, then maybe some more if they sieve especially slowly, like C175_142_39 (still under ECM by my local, temporary cluster) ?

Just to be clear, are you saying to run another t50 on all six of these numbers? If so, I can do it but won't be able to start for at least a couple of weeks.

C178_147_44 is almost at t55. Should be finished on Saturday morning.

debrouxl · 2015-09-25, 06:35

Quote:

Just to be clear, are you saying to run another t50 on all six of these numbers?

Yup.

Quote:

If so, I can do it but won't be able to start for at least a couple of weeks.

I suppose I'll let my temporary local ECM cluster run for a week longer or so, and when they're available, your cores will be able to focus on the harder to sieve numbers, if any, which would warrant more ECM.

Quote:

C178_147_44 is almost at t55. Should be finished on Saturday morning.

Good.

debrouxl · 2015-09-25, 09:50

I've preprocessed and queued all six numbers to NFS@Home. Four of them sieve (much) faster with quintic polynomials. The sextic polynomial generated by snfspoly for C200_118_77 sieves especially badly.
As usual, we can queue other numbers, and start sieving in any order.

wombatman · 2015-09-26, 05:10

The C184 I mentioned a while back (from the HP2(4496) sequence) has now had 9000 curves at B1 = 110e6, which is 0.5t55. The 2/7ths rule of thumb I've seen about for GNFS numbers would suggest up to t52.5, so I think I'm right about there. Would it be possible to get this number added to the queue of the appropriate framework?

Here's the best polynomial I found after a good bit of GPU searching:

Code:

expecting poly E from 4.89e-014 to > 5.62e-014
#skew 57408092.38, size 5.686e-018, alpha -8.323, combined = 4.998e-014 rroots = 3
N 1678014235361171494412759437251156715196370502921609077981958281361841968741471032173866363738649129889242231617442033013296959996597693296465815725008475395665595316058320223952222833
SKEW 57408092.38
R0 -265543383928812678580676104494104160
R1 1130917228102153
A0 -490156967658376900870819763345110150908242359
A1 -49123231727429286516606680780314894218
A2 1084240648688196291286550714363
A3 69294780378791077636242
A4 -356480602523908
A5 1270920

If it needs more curves, I can run them, but they'll take a while.

wblipp · 2015-09-26, 05:10

The C236 residual of 2039^73-1 has had ECM to t55 by Oscar aka Lorgix, well past the 2/9th benchmark for SNFS.

swellman · 2015-09-26, 10:11

C178_147_44 survived 18000+ curves @B1=110M with no factors found.

Lionel - after next weekend I will throw some workers at ECM of my nominations for the 14e queue. Any ECM you can throw at them in the meantime would be greatly appreciated.

Is more work required on C175_142_39? It appears to have survived over 4t50 + 4000 curves at B1=110M (which is ~1.25t50). I am thinking ECM is played out but let me know if there is more work to be done. Thanks.

debrouxl · 2015-09-26, 10:32

Ben: GNFS 184 is a task for 15e, given that even GNFS 170 is already more efficient for 15e than for 14e. Drop a PM to fivemack ?

William: thanks, will attempt to pre-process and queue.

Sean:
* one of your nominations for the 14e queue is down after 369 curves at B1=43e6. C186_148_33 = 719726763463002887376866660892645155066748304865851 (p51) * p135. I've removed it from the 14e queue.
* no more work is required on C175_142_39, indeed. I've updated the queue. But from the above discussion, it's not crystal clear whether it should be sieved by GNFS or by SNFS.

swellman · 2015-09-26, 12:30

Lionel - nice ECM hit. I wish they were all so easy!

As to C175_142_39, seems that either GNFS or SNFS gets the job done in similar times. If you have a GNFS poly already, go with that. It's probably not worth days of GPU searching for a 5% gain in sieving speed. But do as you think best, I don't have any instinct either way. Nor do I have a GPU rig or I would help.

debrouxl · 2015-09-26, 13:49

Yeah, I don't have a poly or a decent GPU to look for one either.

swellman · 2015-09-29, 12:20

Lionel - I've started some supplemental ECM on C190_147_34. Running 3200 curves @B1=110M, which is approximately t50. Even has a small chance of catching a bigger factor. Please let me know if this is sufficient - I can run more curves if necessary.

Thanks.

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-09-24, 19:47	#243
debrouxl Sep 2009 977 Posts	Sure, having a backlog of usable numbers, without depleting the queue of a single project, is always nice I suppose that these six numbers should all be receiving a second t50, then maybe some more if they sieve especially slowly, like C175_142_39 (still under ECM by my local, temporary cluster) ?

2015-09-25, 09:50	#246
debrouxl Sep 2009 1721₈ Posts	I've preprocessed and queued all six numbers to NFS@Home. Four of them sieve (much) faster with quintic polynomials. The sextic polynomial generated by snfspoly for C200_118_77 sieves especially badly. As usual, we can queue other numbers, and start sieving in any order.

2015-09-26, 05:10	#248
wblipp "William" May 2003 New Haven 93E₁₆ Posts	The C236 residual of 2039^73-1 has had ECM to t55 by Oscar aka Lorgix, well past the 2/9th benchmark for SNFS.

2015-09-26, 10:11	#249
swellman Jun 2012 2²×773 Posts	C178_147_44 survived 18000+ curves @B1=110M with no factors found. Lionel - after next weekend I will throw some workers at ECM of my nominations for the 14e queue. Any ECM you can throw at them in the meantime would be greatly appreciated. Is more work required on C175_142_39? It appears to have survived over 4t50 + 4000 curves at B1=110M (which is ~1.25t50). I am thinking ECM is played out but let me know if there is more work to be done. Thanks.

2015-09-26, 10:32	#250
debrouxl Sep 2009 977₁₀ Posts	Ben: GNFS 184 is a task for 15e, given that even GNFS 170 is already more efficient for 15e than for 14e. Drop a PM to fivemack ? William: thanks, will attempt to pre-process and queue. Sean: * one of your nominations for the 14e queue is down after 369 curves at B1=43e6. C186_148_33 = 719726763463002887376866660892645155066748304865851 (p51) * p135. I've removed it from the 14e queue. * no more work is required on C175_142_39, indeed. I've updated the queue. But from the above discussion, it's not crystal clear whether it should be sieved by GNFS or by SNFS.

2015-09-26, 12:30	#251
swellman Jun 2012 2²×773 Posts	Lionel - nice ECM hit. I wish they were all so easy! As to C175_142_39, seems that either GNFS or SNFS gets the job done in similar times. If you have a GNFS poly already, go with that. It's probably not worth days of GPU searching for a 5% gain in sieving speed. But do as you think best, I don't have any instinct either way. Nor do I have a GPU rig or I would help.

2015-09-26, 13:49	#252
debrouxl Sep 2009 977 Posts	Yeah, I don't have a poly or a decent GPU to look for one either.

2015-09-29, 12:20	#253
swellman Jun 2012 C14₁₆ Posts	Lionel - I've started some supplemental ECM on C190_147_34. Running 3200 curves @B1=110M, which is approximately t50. Even has a small chance of catching a bigger factor. Please let me know if this is sufficient - I can run more curves if necessary. Thanks.