FWIW, V17 data, probably skewed and worthless.

:max:

[QUOTE=Xyzzy;260796]FWIW, V17 data, probably skewed and worthless.

:max:[/QUOTE]

Cheers.

Why go back to windows? I thought you went linux.

-- Craig

[QUOTE=Uncwilly;260793]PrimeNet verifies that the reported factor is correct. Chances are that happens and usually doesn't get noticed. I would not worry[/QUOTE]

[QUOTE=James Heinrich;260795]Note also that you're testing a wide bitrange. 3 factors in a row would be unusual, but certainly not impossible, testing a single bit depth for each exponent (e.g. 2^65 to 2^66). Your 3 factors are 72.6, 67.6 and 66.4 bits respectively. TF from 2^65-74 on M380M range has almost exactly a [url=http://mersenne-aries.sili.net/credit.php?worktype=TF&exponent=380006269&f_exponent=&b1=&b2=&numcurves=&factor=&frombits=65&tobits=74&submitbutton=Calculate]13% chance[/url] of finding a factor somewhere in that range. So finding 3-in-a-row should be a roughly 1:455 occurrence.[/QUOTE]

Thanks guys.

-- Craig

[QUOTE]Why go back to windows? I thought you went linux.[/QUOTE]We are on a 30 day trial, which we suppose we could repeat every 30 days.

We want to get Linux up and running but we have been busy and we have trouble with the thought of going off-line while we could be doing so much work!

:smile:

Unrelated question: We have been factoring in the 1e6 to 2e6 range. Is this suboptimal for mfaktc efficiency? Something like this was alluded to in the README. Yes, we actually read it!

What interesting factoring projects are there, other than factoring 1e9 digit work?

[QUOTE=Xyzzy;260800]What interesting factoring projects are there, other than factoring 1e9 digit work?[/QUOTE]

You could start taking 30M-40M to 2^69. It's [I]only[/I] 380THzd or some such. :big grin:

[QUOTE=Xyzzy;260800]We are on a 30 day trial, which we suppose we could repeat every 30 days.

We want to get Linux up and running but we have been busy and we have trouble with the thought of going off-line while we could be doing so much work!

:smile:

Unrelated question: We have been factoring in the 1e6 to 2e6 range. Is this suboptimal for mfaktc efficiency? Something like this was alluded to in the README. Yes, we actually read it!

What interesting factoring projects are there, other than factoring 1e9 digit work?[/QUOTE]

I noticed your load was about 40M candidates per instance. Maybe you may set up mfaktc to work on more than one bit-level at a time: as TheJudger often say, mfaktc works better (and the CPU use would be lower) if you work on (say) 500M candidates.

As for your next question, yesterday I started factoring with mfaktc in the 53M-60M range up to 72 bits, to try and avoid the p-1 factoring stage.
With my GTX275 at half load it only takes 6-7 hours to complete the 3-bit range.

Luigi

[QUOTE=ET_;260812]With my GTX275 at half load it only takes 6-7 hours to complete the 3-bit range.[/QUOTE]
Only:smile:
GPUs deserve better speeds

[QUOTE=Xyzzy;260800]Unrelated question: We have been factoring in the 1e6 to 2e6 range. Is this suboptimal for mfaktc efficiency? Something like this was alluded to in the README. Yes, we actually read it![/QUOTE]

Bigger exponents have a lower CPU usage compared to smaller exponents. The sieve (CPU part) does not depend on the size of the exponent while the verfication of each factor candidate (GPU part) depends on the size of the exponent.


[QUOTE=ET_;260812]I noticed your load was about 40M candidates per instance. Maybe you may set up mfaktc to work on more than one bit-level at a time: as TheJudger often say, mfaktc works better (and the CPU use would be lower) if you work on (say) 500M candidates.[/QUOTE]

If you replace "instance" with "per class" this is correct. The number of tested factor candidates is the 2nd column in the per class output. Efficiency of mfaktc increases with a higher number of candidates per class. 40M candidates per class is not much for mfaktc but it is not really worth. You might gain perhaps 5% more throughput for (much) bigger cases.

Xyzzy: if you're running exponents and bit ranges of similar size you might try to manually set SievePrimes to an "optimal" value.

Oliver

Hello George,

[QUOTE=Prime95;260646]If you put any code under GPL v3 it will never be incorporated into prime95.[/QUOTE]

ignoring the license stuff: any idea how likely you'll add (parts of) mfaktc to your prime95/mprime?
Currently I'm the only copyright holder. I think I can re-release (parts of) mfaktc under other licenses.

[QUOTE=Prime95;260649]It is open source with 2 exceptions:

1) The security code that makes it a tiny bit harder to forge results is not public.
2) You cannot use the code to Mersenne primes unless you agree to abide by the GIMPS prize rules.

The first restriction will preclude you from releasing under GPL.[/QUOTE]

I understand that the GPL is not the ideal license for your code. For mfaktc the GPL was the most obvious license. GPL is widely known.
I don't like licenses which allow to distribute modifications without releasing the sourcecode.

[QUOTE=Christenson;260655]Oliver and George, please work out the correct legal basis. Upgraded specification attached.[/QUOTE]

Are you willing to re-release the needed functions from primenet.[ch] under GPL v3 for the integration in mfaktc?

Oliver

[QUOTE=Karl M Johnson;260813]Only:smile:
GPUs deserve better speeds[/QUOTE]

Yes, but I have 3 cores of mprime, 2 cores of LLR and one core of gmp-fermat alresdy working together on my 4-cores machine... :smile:

Luigi

[QUOTE=Prime95;260649]It is open source with 2 exceptions:

1) The security code that makes it a tiny bit harder to forge results is not public.
2) You cannot use the code to Mersenne primes unless you agree to abide by the GIMPS prize rules.

The first restriction will preclude you from releasing under GPL.[/QUOTE]

George, Oliver and Christenson et al...

Just putting out an idea which might eliminate the need for the "security code" to be released to the public, and thus allow the code in mfaktc which communicates with PrimeNet to be GPLed...

As the value generated for the "Wd1:XXXXXXXX" or "Wd2:XXXXXXXX" fields in the response message is rather predictable for TFing (I won't go into further details, but those who do a lot of TFing will likely know what I'm talking about...), might this be an opportunity to change this value to be generated by a publicly known, but impossible to fake, (and inexpensive) process?

I'm thinking (without having examined Oliver's code) of something like a cyclic sum of all the factor candidates tested between the "bit levels".

The server wouldn't be able to tell if this was faked or not, but it would allow random "double checks" to spot cheaters.

George and Oliver -- do you consider this suggestion to have any value?