2018 14e post processing reservations and results - Page 24

pinhodecarlos · 2018-09-25, 05:10

Quote:

Originally Posted by RichD

What did filtering finally say was the total unique relations? I've had tens of thousands of these but still manage to have enough good relations out of the remaining 200M+ to build a matrix.

I still think someone is hacking the BOINC batch files and submitting previous results for a different job to "pad" their stats. No one seems to be able to identify it.

Here is a related post to getting tons of error -11.

https://www.mersenneforum.org/showpo...61&postcount=2

richs · 2018-09-25, 13:57

Quote:

Originally Posted by richs

Reserving 11611_144 on 14e.

Code:

p72 factor: 112045998427219090871953040117667258301569847152699559565607504451497301
p86 factor: 63264787949930725243445414832953024183897855766018170835974420877209157378834269266207

Approximately 47.1 hours on 2 threads Core i3-2310M with 4 GB memory for a 5.70M matrix at TD = 70. Log attached and log at https://pastebin.com/KsDS7zDh

Factors added to FDB.

debrouxl · 2018-09-26, 06:41

In a poly, the deg: line is indeed superfluous, but I usually let it in when it's there.

unconnected · 2018-09-26, 11:19

I've downloaded .poly/.fb/.ini files from 50009_239 and run job with good old factMsieve.pl - it goes well and produces legal relations. Let's try queue slightly modified poly (deg and lss params were removed, m changed to Y0/Y1 as in others polys) for small range (say, 20M-30M) and see if it helps.

Code:

n: 500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009
skew: 1.62
c6: 1
c0: 18
Y0: -10000000000000000000000000000000000000000
Y1: 1
type: snfs
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7

debrouxl · 2018-09-26, 11:37

Well... Multiple near-repdigit numbers have used "m:" lines over time just fine on both RSALS and NFS@Home, so there's something else going on

I haven't yet managed to convince myself that it's time to resieve, but maybe I'm just dense.

In the DB, I noticed that there was another, older entry mistakenly named 50009_239 (should have been "50009_238"), which reads:

Code:

(1131,1489406743,1489407441,1489407441,
'50009_239','50009_239',4,0,0,'Near-repdigit','SNFS','','n: 500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000009\r\nm: 5000000000000000000000000000000000000000\r\ndeg: 6\r\nc6: 16\r\nc0: 45\r\nskew: 1.19\r\ntype: snfs\r\nlss: 1\r\nrl
im: 120000000\r\nalim: 120000000\r\nlpbr: 30\r\nlpba: 30\r\nmfbr: 60\r\nmfba: 60\r\nrlambda: 2.7\r\nalambda: 2.7\r\n',20000000,120000000,120000000,'239.40',30,'Dmitry Domanov: p55 * p75 * p110',0,2,6248,'',6285
215001,109771593,'HGSCp9xB')

https://pastebin.com/HGSCp9xB matches http://stdkmd.com/nrr/c.cgi?q=50009_238 .

unconnected · 2018-09-26, 11:52

Lionel, that's the point! We've sieved job for 50009_238 once again, I've checked this by running current dataset with 50009_238 poly:

Code:

Msieve v. 1.54 (SVN 1025)
Wed Sep 26 11:43:59 2018
random seeds: 2bde25a4 300ea441
factoring 50000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009 (239 digits)
no P-1/P+1/ECM available, skipping
commencing number field sieve (239-digit input)
R0: -5000000000000000000000000000000000000000
R1: 1
A0: 45
A1: 0
A2: 0
A3: 0
A4: 0
A5: 0
A6: 16
skew 1.62, size 6.797e-12, alpha 0.213, combined = 4.894e-13 rroots = 0

commencing relation filtering
estimated available RAM is 7631.3 MB
commencing duplicate removal, pass 1
error -1 reading relation 9144250
read 10M relations
error -9 reading relation 11675596
error -1 reading relation 19265553
error -5 reading relation 19400233
read 20M relations
error -9 reading relation 24810475
error -15 reading relation 24810782
error -15 reading relation 26006753
...

So, it is necessary to resieve the whole 50009_239 job.

debrouxl · 2018-09-26, 12:05

Meh. In this case, some files were not regenerated. And IIRC, it's not the first time this occurs. Too bad we need to resieve.

We probably want to somehow help detect or prevent this on the production versions, before the never-worked-on queue management improvements ( https://www.mersenneforum.org/showthread.php?t=21356 ) become available.
Looks like the production code base has changes not available in the internal, privately shared version derived from the production code base over 2 years ago: a page linked from the management interface doesn't exist in the internal version...

swellman · 2018-09-27, 15:28

Quote:

Originally Posted by unconnected

I've downloaded .poly/.fb/.ini files from 50009_239 and run job with good old factMsieve.pl - it goes well and produces legal relations. Let's try queue slightly modified poly (deg and lss params were removed, m changed to Y0/Y1 as in others polys) for small range (say, 20M-30M) and see if it helps.

Code:

n: 500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009
skew: 1.62
c6: 1
c0: 18
Y0: -10000000000000000000000000000000000000000
Y1: 1
type: snfs
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7

Well I’ve test sieved this and it seems to work correctly. On 14e, yield is > 2.7 @Q=20M.

I’d be happy to enqueue this job as you describe over a small range, and then you can test the resulting .dat file. If it works, I can then increase the upper bound of Q to give the full result.

I assume you want me to delete the current job entitled “50009_239”, correct?

unconnected · 2018-09-27, 15:38

Yes, that's right. And please give a unique name for new job to not interfere with erroneous named 50009_239 task somewhere in database mentioned by Lionel.

swellman · 2018-09-28, 00:19

Quote:

Originally Posted by unconnected

Yes, that's right. And please give a unique name for new job to not interfere with erroneous named 50009_239 task somewhere in database mentioned by Lionel.

Done.

debrouxl · 2018-09-28, 11:46

I've just expanded the upper bound for 50009_239A from 30M to 100M.

Also, Greg sent me a copy of the latest production code.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
2018 15e post-processing reservations and results	fivemack	NFS@Home	221	2019-01-04 13:08
16e Post Processing Progress	pinhodecarlos	NFS@Home	8	2018-11-28 13:45
Crash doing large post-processing job	wombatman	Msieve	22	2013-12-04 01:37
Update on 7^254+1 post processing	dleclair	NFSNET Discussion	4	2005-04-05 09:51
Post processing for 2,757-	xilman	NFSNET Discussion	3	2003-11-06 14:23

2018-09-26, 06:41	#256
debrouxl Sep 2009 977 Posts	In a poly, the deg: line is indeed superfluous, but I usually let it in when it's there.

2018-09-26, 12:05	#260
debrouxl Sep 2009 1111010001₂ Posts	Meh. In this case, some files were not regenerated. And IIRC, it's not the first time this occurs. Too bad we need to resieve. We probably want to somehow help detect or prevent this on the production versions, before the never-worked-on queue management improvements ( https://www.mersenneforum.org/showthread.php?t=21356 ) become available. Looks like the production code base has changes not available in the internal, privately shared version derived from the production code base over 2 years ago: a page linked from the management interface doesn't exist in the internal version...

2018-09-27, 15:38	#262
unconnected May 2009 Russia, Moscow 43×59 Posts	Yes, that's right. And please give a unique name for new job to not interfere with erroneous named 50009_239 task somewhere in database mentioned by Lionel.

2018-09-28, 11:46	#264
debrouxl Sep 2009 977 Posts	I've just expanded the upper bound for 50009_239A from 30M to 100M. Also, Greg sent me a copy of the latest production code.