mersenneforum.org (https://www.mersenneforum.org/index.php)
-   -   Trial Factoring for Dummies (https://www.mersenneforum.org/showthread.php?t=25493)

 chalsall 2020-04-28 03:54

[QUOTE=R.D. Silverman;544022]"border-line kit"???? Meaning?[/QUOTE]

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.

 Prime95 2020-04-28 05:31

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).

 R.D. Silverman 2020-04-28 08:24

[QUOTE=axn;544032]
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).
[/QUOTE]

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.
[/QUOTE]

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.

 R.D. Silverman 2020-04-28 08:28

[QUOTE=chalsall;544036]Kit which is no longer producing reliable, reproducible (read: sane), results. Soon (potentially) pining for the fords, etc.
[/QUOTE]

"kit"? What is a "kit"??? Is it the GPU itself? A driver? A bus? etc.
Is this word standard GPU terminology?

 retina 2020-04-28 08:37

[QUOTE=R.D. Silverman;544042]"kit"? What is a "kit"??? Is it the GPU itself? A driver? A bus? etc.
Is this word standard GPU terminology?[/QUOTE]I love it. RDS is back to form. :tu:

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

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

[QUOTE=Prime95;544038]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).[/QUOTE]

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.

 R.D. Silverman 2020-04-28 08:53

[QUOTE=retina;544043]I love it. RDS is back to form. :tu:

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

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"?

 retina 2020-04-28 08:57

[QUOTE=R.D. Silverman;544045]Enlighten me. Please give a formal definition of the word "kit" in this context. What
items are included in a GPU "kit"?[/QUOTE]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.

 kriesel 2020-04-28 10:39

[QUOTE=retina;544046]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.[/QUOTE]Proper selection of every component of the kit. Including no kittens.

 retina 2020-04-28 10:45

[QUOTE=kriesel;544053]Proper selection of every component of the kit. Including no kittens.[/QUOTE]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.

 axn 2020-04-28 10:47

[QUOTE=R.D. Silverman;544041]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]

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.

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