mersenneforum.org Trial Factoring for Dummies
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

2020-04-28, 03:54   #23
chalsall
If I May

"Chris Halsall"
Sep 2002

100100011000102 Posts

Quote:
 Originally Posted by R.D. Silverman "border-line kit"???? Meaning?
Kit which is no longer producing reliable, reproducible (read: sane), results. Soon (potentially) pining for the fords, etc.

I first got involved with GIMPS by using mprime for ongoing sanity confirmation of deployed kit. This is one of the reasons I only run DCs (on the CPUs) on certain machines. When mprime starts throwing errors, it's time to decommission the machine. Like, soon.

It would be really cool if there was a way of doing similar ongoing monitoring of GPUs. For when they're being used for things like financial modeling, 3D rendering, etc.

 2020-04-28, 05:31 #24 Prime95 P90 years forever!     Aug 2002 Yeehaw, FL 71×101 Posts One hitch: The sieve mfaktc uses produces a non-deterministic set of trial factors. To produce a deterministic set would require a big hit to sieve performance (atomic bit clear operations).
2020-04-28, 08:24   #25
R.D. Silverman

Nov 2003

22×5×373 Posts

Quote:
 Originally Posted by axn Suppose, somehow we can overcome this problem and force everyone to use only trusted binaries. Then, we don't need to do any of this. We can just send in a nonce and the client can return HASH(nonce, exponent, bit depth).
This proves nothing since it can be computed independently of whether the
divisions took place. You need to include some information generated by
the TF itself.

Quote:
 I'm trying to understand this part. Suppose the server asks client to compute has for indices {10, 20, 30}. The assumption is that the server knows (or can compute) exactly which candidate factors correspond to the given indices. But that is not deterministic on client side. Because of variable SoE sieve depth (and the inherent nondeterminism in GPU sieve), the exact sequence of candidate factors produced can vary and so the server can't validate the residue.
Another reason to dislike GPU's: They are NDTM's. Can you even prove that two
different machines will actually trial divide with the same set of candidate divisors?
Perhaps some machines fail to test one or more candidates 2kp+1 because it skipped
some k that it should not?

I was specifying a method which I assumed was running on a DTM.

2020-04-28, 08:28   #26
R.D. Silverman

Nov 2003

11101001001002 Posts

Quote:
 Originally Posted by chalsall Kit which is no longer producing reliable, reproducible (read: sane), results. Soon (potentially) pining for the fords, etc.
"kit"? What is a "kit"??? Is it the GPU itself? A driver? A bus? etc.
Is this word standard GPU terminology?

2020-04-28, 08:37   #27
retina
Undefined

"The unspeakable one"
Jun 2006
My evil lair

2×32×11×29 Posts

Quote:
 Originally Posted by R.D. Silverman "kit"? What is a "kit"??? Is it the GPU itself? A driver? A bus? etc. Is this word standard GPU terminology?
I love it. RDS is back to form.

https://en.wiktionary.org/wiki/kit#Noun number 4. But I suspect you figured that out from the context.

2020-04-28, 08:37   #28
R.D. Silverman

Nov 2003

22×5×373 Posts

Quote:
 Originally Posted by Prime95 One hitch: The sieve mfaktc uses produces a non-deterministic set of trial factors. To produce a deterministic set would require a big hit to sieve performance (atomic bit clear operations).
So if two different machines trial divide with two different sets of trial factors how
do you know whether a true factor was actually tested??? You might be missing some.

A small change in the method can resolve different-order testing anyway. Instead of saving specific
residues, just xor ALL residues into an accumulator and hash it at the end.

Last fiddled with by R.D. Silverman on 2020-04-28 at 08:43

2020-04-28, 08:53   #29
R.D. Silverman

Nov 2003

22×5×373 Posts

Quote:
 Originally Posted by retina I love it. RDS is back to form. https://en.wiktionary.org/wiki/kit#Noun number 4. But I suspect you figured that out from the context.
I love it. People who make informal use of an English word during a technical discussion
in which such words may have more than one meaning. Technical discussions require
words to have only possible meaning.

Enlighten me. Please give a formal definition of the word "kit" in this context. What
items are included in a GPU "kit"?

2020-04-28, 08:57   #30
retina
Undefined

"The unspeakable one"
Jun 2006
My evil lair

10110011011102 Posts

Quote:
 Originally Posted by R.D. Silverman Enlighten me. Please give a formal definition of the word "kit" in this context. What items are included in a GPU "kit"?
ALL of it. Everything that is required to run a test. Including the power cable, the OS, the drivers, and the ability to keep the cat off the keyboard.

2020-04-28, 10:39   #31
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

23×557 Posts

Quote:
 Originally Posted by retina ALL of it. Everything that is required to run a test. Including the power cable, the OS, the drivers, and the ability to keep the cat off the keyboard.
Proper selection of every component of the kit. Including no kittens.

2020-04-28, 10:45   #32
retina
Undefined

"The unspeakable one"
Jun 2006
My evil lair

2×32×11×29 Posts

Quote:
 Originally Posted by kriesel Proper selection of every component of the kit. Including no kittens.
Hah, yes I missed that obvious opportunity.

Revised "kit":
ALL of it. Everything that is required to run a test. Including the power cable, the OS, the drivers, and the ability to keep the kitty off the keyboard.

2020-04-28, 10:47   #33
axn

Jun 2003

22×52×47 Posts

Quote:
 Originally Posted by R.D. Silverman This proves nothing since it can be computed independently of whether the divisions took place. You need to include some information generated by the TF itself.
Perhaps we should do some threat modeling before evaluating proposed solutions.

What is the current problem? Someone can fake a "no factor" result by manually typing up the result line and submitting to the server.

A simple checksum that can only be generated by the client should prevent that. It should have the property that different exponent/bit level should give unique value. Presumably, the client should have enough safeguards that it can't be tricked into computing the checksum without doing the actual work. This would mean encrypting the checkpoint files written to the disk.

I don't think for the problem as stated, we need proof of work. Provided the server trusts the client, the checksum is basically the client vouching for the work done -- that should be good enough.

 Similar Threads Thread Thread Starter Forum Replies Last Post garo GPU Computing 100 2019-04-22 10:58 NBtarheel_33 GPU Computing 10 2011-10-13 00:04 odin Software 4 2010-08-08 20:23 S485122 PrimeNet 1 2007-09-06 00:52 jocelynl Math 8 2006-02-01 14:12

All times are UTC. The time now is 15:40.

Wed Sep 30 15:40:54 UTC 2020 up 20 days, 12:51, 0 users, load averages: 2.08, 1.87, 1.76