2021 14d post processing reservations and results - Page 20

charybdis · 2021-09-11, 13:05

It's not just a different polynomial, it's a completely different number that was done last year. That job had the same name as this one, 417__011_3m1, hence the confusion. It seems the job last year was given that name in error: it should have been 145__031_3m1.

This also explains the yield discrepancy that RichD noticed in the 14e queue management thread.

RichD · 2021-09-11, 13:09

Back in Aoril 2020 there was a number requested here. After going through the test-sieving and backward tracing to get the sigma relationships I must have copied the wrong prime(p93) into the post. The number and poly was correct.

Now, the real p93 needs factoring. Perhaps some of the old files from 17 months ago were still hanging around and not overwritten. That’s just my guess.

richs · 2021-09-11, 13:20

I'll move on to the next number pending resolution of this issue.

swellman · 2021-09-11, 13:21

I found the cause! 417__011_3m1 was also the name of a composite factored in April 2020. The server must have reverted back to the original .poly file once it started processing(?)

Need a naming scheme which avoids this problem, or manually double check before creating a new job name.

ETA: a day late and a dollar short!

RichD · 2021-09-11, 13:30

I think the naming scheme is fine. The problem started with me posting the wrong p93 so the title could be generated. I have a feeling the two numbers in question were right next to each other (at the time) in the t800 file and I grabbed the wrong one. I am the one that needs to be double-checked...

RichD · 2021-09-11, 13:35

I guess the resolution would be to resubmit with a suffix "a".

swellman · 2021-09-11, 14:28

Quote:

Originally Posted by RichD

I guess the resolution would be to resubmit with a suffix "a".

Agreed. I will resubmit the job as 417__011_3m1a.

Greg will have to delete this problem job, I can’t do it.

frmky · 2021-09-11, 16:31

You all solved it! Yes, the polynomial from last year with the same name was found and used by BOINC. Our first name collision.

RichD · 2021-09-11, 16:44

Quote:

Originally Posted by frmky

Our first name collision.

It was by accident. The prime base in the post was incorrect for the number (and poly) being requested. Technically, there should have not been a collision.

frmky · 2021-09-12, 01:30

363__249_11m1 is done.

pinhodecarlos · 2021-09-12, 08:46

Feeding the GPU right?! Lol

2021-09-11, 13:09	#211
RichD Sep 2008 Kansas 2³×5×89 Posts	417__011_3m1 Back in Aoril 2020 there was a number requested here. After going through the test-sieving and backward tracing to get the sigma relationships I must have copied the wrong prime(p93) into the post. The number and poly was correct. Now, the real p93 needs factoring. Perhaps some of the old files from 17 months ago were still hanging around and not overwritten. That’s just my guess.

2021-09-11, 13:21	#213
swellman Jun 2012 110110101001₂ Posts	I found the cause! 417__011_3m1 was also the name of a composite factored in April 2020. The server must have reverted back to the original .poly file once it started processing(?) Need a naming scheme which avoids this problem, or manually double check before creating a new job name. ETA: a day late and a dollar short! Last fiddled with by swellman on 2021-09-11 at 13:22

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
2020 14e post processing reservations and results	swellman	NFS@Home	544	2020-12-31 15:14
2020 16e post processing reservations and results	swellman	NFS@Home	20	2020-12-31 05:22
2019 14e post processing reservations and results	swellman	NFS@Home	862	2019-12-31 10:51
2018 15e post-processing reservations and results	fivemack	NFS@Home	221	2019-01-04 13:08
2018 14e post processing reservations and results	pinhodecarlos	NFS@Home	551	2019-01-04 13:06

2021-09-11, 13:05	#210
charybdis Apr 2020 17·41 Posts	It's not just a different polynomial, it's a completely different number that was done last year. That job had the same name as this one, 417__011_3m1, hence the confusion. It seems the job last year was given that name in error: it should have been 145__031_3m1. This also explains the yield discrepancy that RichD noticed in the 14e queue management thread.

2021-09-11, 13:20	#212
richs "Rich" Aug 2002 Benicia, California 3×17×29 Posts	I'll move on to the next number pending resolution of this issue.

2021-09-11, 13:30	#214
RichD Sep 2008 Kansas 110111101000₂ Posts	I think the naming scheme is fine. The problem started with me posting the wrong p93 so the title could be generated. I have a feeling the two numbers in question were right next to each other (at the time) in the t800 file and I grabbed the wrong one. I am the one that needs to be double-checked...

2021-09-11, 13:35	#215
RichD Sep 2008 Kansas 2³·5·89 Posts	I guess the resolution would be to resubmit with a suffix "a".

2021-09-11, 16:31	#217
frmky Jul 2003 So Cal 2³×5×59 Posts	You all solved it! Yes, the polynomial from last year with the same name was found and used by BOINC. Our first name collision.

2021-09-12, 01:30	#219
frmky Jul 2003 So Cal 2360₁₀ Posts	363__249_11m1 is done.

2021-09-12, 08:46	#220
pinhodecarlos "Carlos Pinho" Oct 2011 Milton Keynes, UK 5036₁₀ Posts	Feeding the GPU right?! Lol