DC mismatches

LaurV · 2011-12-01, 12:32

Or Double-Checks which won't like to kiss each other.

Just found my first GPU+CudaLucas residue mismatch. Finished 26830123 and either my GPU got crazy, or the old residue is "worn out" and good for nothing. :D

I reported it already, and that was the most stupid thing I could do. It later came to my mind that in this way we lose the exponents. In the next 25 minutes or so, chalsall's spider will find the result and unreserve the assignment. It is reserved by "GPU Factoring" for DC, until 7:35 (my time, GMT+7) when Spidy will wake up.

So, my suggestion is that in case of DC assignments, if it is not too much trouble, we should check the old residue first, on the GIMPS results (exponent status) page. If we got a different residue than the one Primenet has, then we should NOT report the result, but put the exponent and the residue we got (masked accordingly) on this very current thread. Some other guys can check it if they like, and then we report it when we are sure.

And we do not lose the exponent...

Brian-E · 2011-12-01, 13:02

Understanding why you suggest this, I would suggest that not reporting the differing result to PrimeNet until we have a match is trying to be a bit too "meddling". Unless Chalsall implements the procedure in the spider, which I imagine would be a lot of work to cover an eventuality which doesn't very often occur, we're running the risk that no-one actually takes this exponent up and it runs out of time on PrimeNet and gets reassigned to Anonymous after all. And then the (possibly good) result reported by the GPUto72 worker never gets taken up and the work was wasted.

I like the philosophy behind the extension of GPUto72 whereby preferred exponents for LL/DC get assigned to trusted workers. But I don't think we should be trying to completely replace the normal PrimeNet allocation system. For the time being we are not succeeding in taking all the "preferred" work anyway, and I'm not sure that we should be trying to.

ET_ · 2011-12-01, 13:17

I had a mismatch when I reported my GPU LL-D to Primenet some days ago.
No error appeared on the screen while the test was performed.

Then I recalled that Prime95 DCs have sometimes the result code shuffled. May this help?

Luigi

Christenson · 2011-12-01, 13:48

Well, if CPUs experience a 1-2% error rate on LLs, then, inevitably, if you report enough LLs, you will report mismatches, even if your error rate is 0. It may or may not be your bad result....that's why we have the CPUs doing the scrambled LL tests....it's very hard to get the same residue out twice unless it's the right one!

At some point, CUDALucas will need to adopt the same scrambled-data technique as P95, but I think that's a ways off (and again, I invite contradiction!

)

KyleAskine · 2011-12-01, 14:40

Quote:

Originally Posted by Brian-E

Understanding why you suggest this, I would suggest that not reporting the differing result to PrimeNet until we have a match is trying to be a bit too "meddling". Unless Chalsall implements the procedure in the spider, which I imagine would be a lot of work to cover an eventuality which doesn't very often occur, we're running the risk that no-one actually takes this exponent up and it runs out of time on PrimeNet and gets reassigned to Anonymous after all. And then the (possibly good) result reported by the GPUto72 worker never gets taken up and the work was wasted.

I like the philosophy behind the extension of GPUto72 whereby preferred exponents for LL/DC get assigned to trusted workers. But I don't think we should be trying to completely replace the normal PrimeNet allocation system. For the time being we are not succeeding in taking all the "preferred" work anyway, and I'm not sure that we should be trying to.

I agree with this 100%. The VAST majority of LL/DC are released back to primenet anyway. If we 'lose' one every once in a while because of a residue mismatch that doesn't matter at all. It doesn't go against the spirit of what GPU to 72 is trying to achieve (in my opinion anyway), which is to ensure that no one gets a LL unless it has been factored 'sufficiently'.

chalsall · 2011-12-01, 16:31

Quote:

Originally Posted by Brian-E

Understanding why you suggest this, I would suggest that not reporting the differing result to PrimeNet until we have a match is trying to be a bit too "meddling". Unless Chalsall implements the procedure in the spider, which I imagine would be a lot of work to cover an eventuality which doesn't very often occur, we're running the risk that no-one actually takes this exponent up and it runs out of time on PrimeNet and gets reassigned to Anonymous after all. And then the (possibly good) result reported by the GPUto72 worker never gets taken up and the work was wasted.

It would be a lot of work for a rare situation. Not so much on Spidy's side, but on the Web GUI and DB back-end.

Plus, as you both pointed out, it might have been the original LL which was in error. So in addition to the work on the G72 system, there would also have to be manual cooperation between the two G72 workers. The starting point of the system was to eliminate the need for such human interaction.

Also, the vast majority of those taking true DC/LL work are using Prime95, so the system doesn't have any control of the candidates anyway.

Quote:

Originally Posted by Brian-E

I like the philosophy behind the extension of GPUto72 whereby preferred exponents for LL/DC get assigned to trusted workers. But I don't think we should be trying to completely replace the normal PrimeNet allocation system. For the time being we are not succeeding in taking all the "preferred" work anyway, and I'm not sure that we should be trying to.

The fundamental purpose of G72 is to ensure the candidates are TF'ed to the (newly) appropriate depths. The true LL/DC work was an after thought, and we're currently returning to the "wild" many more candidates than we are transferring to "reliable" workers.

kjaget · 2011-12-01, 18:32

Quote:

Originally Posted by Christenson

Well, if CPUs experience a 1-2% error rate on LLs, then, inevitably, if you report enough LLs, you will report mismatches, even if your error rate is 0.

In my experience, it's a 1-2% error rate in the database results, which turns into 100% every time you're testing changes to CudaLucas. My first few full runs when building the code for Windows were mismatches, which eventually turned out to be correct (i.e. a subsequent triple-check verified the GPU results). Caused me a bit of concern until I started getting strings of good results so I can understand they cause worry. And no, I'm not bitter :)

Anyway, I agree with the consensus that we're losing absolutely nothing by checking them in. Until we have more throughput than can handle all of the preferred exponents, lots are going to be "lost" back to the normal primenet process anyway. Doesn't matter if they're unverified after 1,2,3 ... N tests a single bit - they'll need another test and until we have to firepower to handle all of them, being particular about which ones we test doesn't change the big picture view.

moebius · 2011-12-01, 20:25

Probably only the First-time test is faulty.

LaurV · 2011-12-02, 03:33

Ok, now after reading you all, I am still not giving up totally.
I understand your points of view, and I think that I overreacted again. Maybe because I was a bit disappointed by my first GPU DC mismatch... So, you are all right about not needing to keep the exponent in the list and do multiple checks. I don;t know what I was thinking...

But...

My expo was already de-assigned by GPU272, and it is already re-asigned to some anonymous, and I really hope he is not using CudaLucas, otherwise he will work in vain (assuming my result is right. If the original result is right, then the anonymous cruncher will still get a residue match with the original, and get his credit, and clear the exponent).

That is why we still need to post the mismatches here (or anywhere else), if we run them with CudaLucas and get a mismatch. Only for CudaLucas (and generally third parties code, different of P95). So the guys running DC on GPU should know to avoid them.

Like a "Reference list of the exponents that got mismatched residues on CudaLucas DC tests. Avoid them if you DC with CudaLucas"

So I start the list:

exponent: 26830123

Dubslow · 2011-12-02, 05:36

Or just 'Don't DC with CUDALucas' thread. Much shorter title.

LaurV · 2011-12-02, 06:26

Whatever. Current thread is ok too, and a mod can (eventually) change the title.
(I wasn't thinking to a "title" with that long phrase, I was trying to show the "utility" of the list, why and what is useful for).

2011-12-01, 12:32	#1
LaurV Romulan Interpreter Jun 2011 Thailand 258C₁₆ Posts	DC mismatches Or Double-Checks which won't like to kiss each other. Just found my first GPU+CudaLucas residue mismatch. Finished 26830123 and either my GPU got crazy, or the old residue is "worn out" and good for nothing. :D I reported it already, and that was the most stupid thing I could do. It later came to my mind that in this way we lose the exponents. In the next 25 minutes or so, chalsall's spider will find the result and unreserve the assignment. It is reserved by "GPU Factoring" for DC, until 7:35 (my time, GMT+7) when Spidy will wake up. So, my suggestion is that in case of DC assignments, if it is not too much trouble, we should check the old residue first, on the GIMPS results (exponent status) page. If we got a different residue than the one Primenet has, then we should NOT report the result, but put the exponent and the residue we got (masked accordingly) on this very current thread. Some other guys can check it if they like, and then we report it when we are sure. And we do not lose the exponent...

2011-12-01, 13:17	#3
ET_ Banned "Luigi" Aug 2002 Team Italia 11317₈ Posts	I had a mismatch when I reported my GPU LL-D to Primenet some days ago. No error appeared on the screen while the test was performed. Then I recalled that Prime95 DCs have sometimes the result code shuffled. May this help? Luigi Last fiddled with by ET_ on 2011-12-01 at 13:17

2011-12-02, 03:33	#9
LaurV Romulan Interpreter Jun 2011 Thailand 258C₁₆ Posts	Ok, now after reading you all, I am still not giving up totally. I understand your points of view, and I think that I overreacted again. Maybe because I was a bit disappointed by my first GPU DC mismatch... So, you are all right about not needing to keep the exponent in the list and do multiple checks. I don;t know what I was thinking... But... My expo was already de-assigned by GPU272, and it is already re-asigned to some anonymous, and I really hope he is not using CudaLucas, otherwise he will work in vain (assuming my result is right. If the original result is right, then the anonymous cruncher will still get a residue match with the original, and get his credit, and clear the exponent). That is why we still need to post the mismatches here (or anywhere else), if we run them with CudaLucas and get a mismatch. Only for CudaLucas (and generally third parties code, different of P95). So the guys running DC on GPU should know to avoid them. Like a "Reference list of the exponents that got mismatched residues on CudaLucas DC tests. Avoid them if you DC with CudaLucas" So I start the list: exponent: 26830123 Last fiddled with by LaurV on 2011-12-02 at 03:40

2011-12-02, 06:26	#11
LaurV Romulan Interpreter Jun 2011 Thailand 10010110001100₂ Posts	Whatever. Current thread is ok too, and a mod can (eventually) change the title. (I wasn't thinking to a "title" with that long phrase, I was trying to show the "utility" of the list, why and what is useful for). Last fiddled with by LaurV on 2011-12-02 at 06:27

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Many username mismatches between database and Primenet	GP2	Data	5	2003-09-24 21:15

2011-12-01, 13:02	#2
Brian-E "Brian" Jul 2007 The Netherlands 7×467 Posts	Understanding why you suggest this, I would suggest that not reporting the differing result to PrimeNet until we have a match is trying to be a bit too "meddling". Unless Chalsall implements the procedure in the spider, which I imagine would be a lot of work to cover an eventuality which doesn't very often occur, we're running the risk that no-one actually takes this exponent up and it runs out of time on PrimeNet and gets reassigned to Anonymous after all. And then the (possibly good) result reported by the GPUto72 worker never gets taken up and the work was wasted. I like the philosophy behind the extension of GPUto72 whereby preferred exponents for LL/DC get assigned to trusted workers. But I don't think we should be trying to completely replace the normal PrimeNet allocation system. For the time being we are not succeeding in taking all the "preferred" work anyway, and I'm not sure that we should be trying to.

2011-12-01, 13:48	#4
Christenson Dec 2010 Monticello 5×359 Posts	Well, if CPUs experience a 1-2% error rate on LLs, then, inevitably, if you report enough LLs, you will report mismatches, even if your error rate is 0. It may or may not be your bad result....that's why we have the CPUs doing the scrambled LL tests....it's very hard to get the same residue out twice unless it's the right one! At some point, CUDALucas will need to adopt the same scrambled-data technique as P95, but I think that's a ways off (and again, I invite contradiction! )

2011-12-01, 20:25	#8
moebius Jul 2009 Germany 606₁₀ Posts	Probably only the First-time test is faulty.

2011-12-02, 05:36	#10
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 3·29·83 Posts	Or just 'Don't DC with CUDALucas' thread. Much shorter title.