mersenneforum.org  

Go Back   mersenneforum.org > New To GIMPS? Start Here! > Information & Answers

Reply
 
Thread Tools
Old 2020-04-29, 18:51   #45
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

2·4,663 Posts
Default

Quote:
Originally Posted by kriesel View Post
I find doors work well.
Our house (designed by Linda) is a very "open plan". To a cat, there are effectively no internal doors.
chalsall is offline   Reply With Quote
Old 2020-05-01, 16:32   #46
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

100100011011102 Posts
Default

Quote:
Originally Posted by SethTro View Post
If you want to do more to verify the calculating (to prevent against overclocking / math errors) we should look at my proof-of-work proposal.
I don't have the time (nor knowledge) to drill down further on your proof-of-concept efforts (of a proof-of-work mechanism). But it sounds interesting.

There would be real value in being able to use mfakt[c|o] for ongoing sanity checking of GPU "kit"*. Even if it requires doing another TF run, some might "opt-in" doing this kind of work. It would be fine if it was run on the same users' GPU(s), since this isn't MP stuff, just (largely) no factors found of MP candidates.

It would be relatively trivial to expand the data stream from mfakt* to include the checksum. A simple parsing change on Primenet, and one additional table or field.

Has anyone with the requisite skillset had a look at this yet? Kit has empirically demonstrated it's potential to degrade over time.

* Definition of "Kit" in this context: All of it, sans kittens.
chalsall is offline   Reply With Quote
Old 2020-05-01, 20:11   #47
SethTro
 
SethTro's Avatar
 
"Seth"
Apr 2019

20210 Posts
Default

Quote:
Originally Posted by chalsall View Post
I don't have the time (nor knowledge) to drill down further on your proof-of-concept efforts (of a proof-of-work mechanism). But it sounds interesting.

There would be real value in being able to use mfakt[c|o] for ongoing sanity checking of GPU "kit"*. Even if it requires doing another TF run, some might "opt-in" doing this kind of work. It would be fine if it was run on the same users' GPU(s), since this isn't MP stuff, just (largely) no factors found of MP candidates.

It would be relatively trivial to expand the data stream from mfakt* to include the checksum. A simple parsing change on Primenet, and one additional table or field.

Has anyone with the requisite skillset had a look at this yet?
I worked on this for like a month but there wasn't interest from other people.

It's ~80% done
* I modified mfaktc to return one of the smaller residuals it found.
* I output the new proof of work line
* James may even have implemented part of verification on the server

Code:
M59068201 proof_k(8940824503190951977): 29 bits [TF:60:64:mfaktc 0.21 75bit_mul32_gs]
which can be verified by checking

let residual = pow(2, 59068201, 8940824503190951977) = 422536362
let confidence = log10(tests / P) - log10(K / residual)
in this case confidence = log10(2^63 / 59068201) - log10(8940824503190951977 / 422536362) = 0.86

I calculated the distribution of confidence somewhere. I think the outcome was mean 0.5 and 99.9% of the time confidence < 5, you can also store confidence from many submissions and make sure it averages < 1.

Last fiddled with by SethTro on 2020-05-01 at 20:13
SethTro is offline   Reply With Quote
Old 2020-05-01, 21:53   #48
SethTro
 
SethTro's Avatar
 
"Seth"
Apr 2019

2×101 Posts
Default

Quote:
Originally Posted by SethTro View Post
I worked on this for like a month but there wasn't interest from other people.

It's ~80% done
* I modified mfaktc to return one of the smaller residuals it found.
* I output the new proof of work line
* James may even have implemented part of verification on the server
I took a look at the code again.
https://github.com/sethtroisi/mfaktc/tree/proof

For the smaller kernels in mfaktc you have access to the residual, for the larger kernels the residual is not always computed and we'd need a 2nd proof functions which will be similar but won't directly minimize residual but some other intermediate product (e.g. lower 32 bits of residual)
SethTro is offline   Reply With Quote
Old 2020-05-01, 22:08   #49
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

100100011011102 Posts
Default

Quote:
Originally Posted by SethTro View Post
For the smaller kernels in mfaktc you have access to the residual, for the larger kernels the residual is not always computed and we'd need a 2nd proof functions which will be similar but won't directly minimize residual but some other intermediate product (e.g. lower 32 bits of residual)
OK... For my edification, how "deep" into the GPU compute results does your proposal go? As in, would this be useful for catching unreliable GPUs (presumably, only after doing a second run, and not seeing the same residue)?

The question many will ask is it worthwhile to do this? A missed factor doesn't really impact GIMPS much (and certainly won't result in a missed MP). But I think there may be some interest in this ability (if it isn't too computationally expensive -- the second runs could be a random distribution).
chalsall is offline   Reply With Quote
Old 2020-05-01, 23:38   #50
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

2·32·263 Posts
Default

Quote:
Originally Posted by chalsall View Post
OK... For my edification, how "deep" into the GPU compute results does your proposal go? As in, would this be useful for catching unreliable GPUs (presumably, only after doing a second run, and not seeing the same residue)?

The question many will ask is it worthwhile to do this? A missed factor doesn't really impact GIMPS much (and certainly won't result in a missed MP). But I think there may be some interest in this ability (if it isn't too computationally expensive -- the second runs could be a random distribution).
Elsewhere he mentions an overhead of under 5%, perhaps 2-3%, seen in his testing of it, compared to unmodified mfaktc. That's without any spot-check duplicate runs.

Last fiddled with by kriesel on 2020-05-01 at 23:39
kriesel is offline   Reply With Quote
Old 2020-05-02, 00:16   #51
SethTro
 
SethTro's Avatar
 
"Seth"
Apr 2019

2×101 Posts
Default

Quote:
Originally Posted by chalsall View Post
OK... For my edification, how "deep" into the GPU compute results does your proposal go? As in, would this be useful for catching unreliable GPUs (presumably, only after doing a second run, and not seeing the same residue)?

The question many will ask is it worthwhile to do this? A missed factor doesn't really impact GIMPS much (and certainly won't result in a missed MP). But I think there may be some interest in this ability (if it isn't too computationally expensive -- the second runs could be a random distribution).
my proposal sits at the very end of the GPU compute so it allows us to verify the GPU is correctly computing pow(2, P, test) and not making math errors.

Additionally residuals are randomly distributed (and residuals with many leading zeros are rare) so we are verifying that they are doing a large amount of correct work without having to run a 2nd check.

I'm not sure the amount of description that's needed. If this doesn't make sense I can add more details.
SethTro is offline   Reply With Quote
Old 2020-05-02, 13:27   #52
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

2×4,663 Posts
Default

Quote:
Originally Posted by SethTro View Post
I'm not sure the amount of description that's needed. If this doesn't make sense I can add more details.
It makes sense. However, I would very much like to hear from others who understand this kind of work to a much deeper level than I do.

What do people think? Is this worth implementing? It could be done in such a way as people "opt-in" to the (slightly more expensive) code-path. Perhaps running a percentage of jobs using this, for sanity checking?

Thoughts? Oliver, are you monitoring this thread? At the end of the day, it would be up to you to decide to pull this into your main code-base.
chalsall is offline   Reply With Quote
Old 2020-05-02, 15:28   #53
Uncwilly
6809 > 6502
 
Uncwilly's Avatar
 
"""""""""""""""""""
Aug 2003
101×103 Posts

100010101110102 Posts
Default

My 2 centavos is that any overhead that is not error checking related, should not be more than 0.5%. The loss vs. gain doesn't make sense.

What is the potential gain (speed-wise) to the project? Based upon the examination of "expected number of factors", we don't have systematic cheating. We have had a few idiots. Total loss due to them nearly nil.

Does this capture missed factors due to errors (thus speeding the project)? No.

Does this find false factors? No.

Is this an actual residual of the calculation, or is it just a manufactured calculation? It is not a natural byproduct of the calculation like the LL residual.



This is my very naive concept.
Why can't the program take the result to the mod operation at certain select k values and do a rolling operation on them like a CRC? Or certain classes. The k values to be selected could be calculated based upon the exponent. Doing the operation every 10000 k's tested should not put an undue burden on operation and would prove that the at least those items were done in sequence.
Uncwilly is offline   Reply With Quote
Old 2020-05-02, 17:14   #54
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

22·7·11·29 Posts
Default

Quote:
Originally Posted by Uncwilly View Post
My 2 centavos
+1.
LaurV is offline   Reply With Quote
Old 2020-05-02, 18:32   #55
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

111768 Posts
Default

As George has already pointed out, among others, the list of k values tried in gpu trial factoring is not reproducible from run to run of a given exponent/bit level combination, because the factor candidate sieving is not deterministic, letting some composite factors through to be tried against the mersenne number. It's done that way because it's faster than a perfect factor candidate sieving to primes only.
That means the list of k values will vary, so the n.10^c-th k value will vary, so the crc will vary, for the same inputs. To fix that issue, would require completely sieving each factor candidate, not just every 10^c.

I think Gerbicz' approach is more easily made immune to this leaky-sieve issue.
And since it is a single-word binary mod of something that's already been moded down to factor size, that part should be very quick. Only the factor candidates for the Gerbicz check values list need be further screened for primeness.

Last fiddled with by kriesel on 2020-05-02 at 18:34
kriesel is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
GPU Trial Factoring FAQ garo GPU Computing 100 2019-04-22 10:58
mfaktc for dummies NBtarheel_33 GPU Computing 10 2011-10-13 00:04
How much Trial Factoring to do? odin Software 4 2010-08-08 20:23
How far to do trial factoring S485122 PrimeNet 1 2007-09-06 00:52
trial factoring and P-1 jocelynl Math 8 2006-02-01 14:12

All times are UTC. The time now is 14:49.

Mon Nov 30 14:49:43 UTC 2020 up 81 days, 12 hrs, 3 users, load averages: 1.18, 1.39, 1.45

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.