14e batch of WU's

pinhodecarlos · 2014-10-08, 20:37

Lionel,

Please check

http://escatter11.fullerton.edu/nfs/...ead.php?id=571

Message:

"""""""
Looks like the 14e batch of WU's starting with GC_9_257 are all broken. None of my Linux systems have successfully run one of them. Is this something unique to the Linux app? Or maybe just my hosts? :)

I'm guessing it's the WU's. :)
http://escatter11.fullerton.edu/nfs/...?wuid=33795303

"""""""

debrouxl · 2014-10-09, 06:29

The set of parameters for GC_9_257 is exactly the same as the set of parameters for GC_8_266, so at least, it's not a missing parameter.

Greg ?

fivemack · 2014-10-09, 13:17

The value of c0 in the .poly file is -1, where it should be +1

Sieving works fine when I correct this.

pinhodecarlos · 2014-12-13, 18:40

More errors:

http://escatter11.fullerton.edu/nfs/...hp?id=576#1455

Check GC_2_802 wu's and its details.

Batalov · 2014-12-13, 19:55

c0 should be +1; it is a G. Cullen number.

Also if it is to be restarted anyway, a better poly would be with c6: 401, c0: 2 and double Y0, double skew

pinhodecarlos · 2014-12-14, 10:05

I already contacted Lionel about this issue but he didn't reply yet to me. If someone knows his mobile number please let me know by PM.
This is the second mistake we make, it is time to change strategy, I think once Paul Leyland said he could send us the poly for his numbers instead of using the current script.

xilman · 2014-12-14, 18:05

Quote:

Originally Posted by Batalov

Also if it is to be restarted anyway, a better poly would be with c6: 401, c0: 2 and double Y0, double skew

Have you verified that claim? Not saying you're wrong but my experiments suggest that factoring 2N is sometimes slower than factoring N, even though the algebraic coefficients are smaller.

Paul

Batalov · 2014-12-14, 19:42

Yes

xilman · 2014-12-14, 19:47

Quote:

Originally Posted by Batalov

Yes

Thanks. It should definitely be used in that case.

Batalov · 2014-12-14, 21:12

More specifically, it is a few percent better by E value... but of course that is not a definitive sign.

I've trial-sieved (not too much) -
- on the -a side, much more sieving is needed for a good answer (-a sieving yield is noisy), but basically the same; and
- on the -r side, the second poly is a couple percent better.

I don't know what side NFS @ Home is sieving on, but interestingly -a side seems to be just a tad better.
(Usually people sieve SNFS on the -r side.)

pinhodecarlos · 2014-12-27, 10:07

Server is dried. More work is needed.

2014-10-09, 06:29	#2
debrouxl Sep 2009 977 Posts	The set of parameters for GC_9_257 is exactly the same as the set of parameters for GC_8_266, so at least, it's not a missing parameter. Greg ? Last fiddled with by debrouxl on 2014-10-09 at 06:29

2014-10-09, 13:17	#3
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 18E9₁₆ Posts	The value of c0 in the .poly file is -1, where it should be +1 Sieving works fine when I correct this. Last fiddled with by fivemack on 2014-10-09 at 13:18

2014-12-13, 18:40	#4
pinhodecarlos "Carlos Pinho" Oct 2011 Milton Keynes, UK 2⁴·3·101 Posts	More errors: http://escatter11.fullerton.edu/nfs/...hp?id=576#1455 Check GC_2_802 wu's and its details. Last fiddled with by pinhodecarlos on 2014-12-13 at 18:48

2014-12-13, 19:55	#5
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3³·7³ Posts	c0 should be +1; it is a G. Cullen number. Also if it is to be restarted anyway, a better poly would be with c6: 401, c0: 2 and double Y0, double skew Last fiddled with by Batalov on 2014-12-13 at 20:08

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
15e batch of WU's NFS@Home	pinhodecarlos	NFS@Home	31	2020-01-21 21:49
Batch jobs using AWS Batch	GP2	Cloud Computing	1	2016-12-07 11:31
Got first batch of TF to 75	Chuck	GPU to 72	23	2015-05-10 20:34
Yafu batch running	ThomRuley	YAFU	11	2011-06-13 13:35
batch file	em99010pepe	No Prime Left Behind	7	2008-03-15 10:53

2014-10-08, 20:37	#1
pinhodecarlos "Carlos Pinho" Oct 2011 Milton Keynes, UK 2⁴·3·101 Posts	14e batch of WU's Lionel, Please check http://escatter11.fullerton.edu/nfs/...ead.php?id=571 Message: """"""" Looks like the 14e batch of WU's starting with GC_9_257 are all broken. None of my Linux systems have successfully run one of them. Is this something unique to the Linux app? Or maybe just my hosts? :) I'm guessing it's the WU's. :) http://escatter11.fullerton.edu/nfs/...?wuid=33795303 """""""

2014-12-14, 10:05	#6
pinhodecarlos "Carlos Pinho" Oct 2011 Milton Keynes, UK 2⁴×3×101 Posts	I already contacted Lionel about this issue but he didn't reply yet to me. If someone knows his mobile number please let me know by PM. This is the second mistake we make, it is time to change strategy, I think once Paul Leyland said he could send us the poly for his numbers instead of using the current script.

2014-12-14, 19:42	#8
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3³·7³ Posts	Yes

2014-12-14, 21:12	#10
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3³×7³ Posts	More specifically, it is a few percent better by E value... but of course that is not a definitive sign. I've trial-sieved (not too much) - - on the -a side, much more sieving is needed for a good answer (-a sieving yield is noisy), but basically the same; and - on the -r side, the second poly is a couple percent better. I don't know what side NFS @ Home is sieving on, but interestingly -a side seems to be just a tad better. (Usually people sieve SNFS on the -r side.)

2014-12-27, 10:07	#11
pinhodecarlos "Carlos Pinho" Oct 2011 Milton Keynes, UK 2⁴·3·101 Posts	Server is dried. More work is needed.