mfaktc: a CUDA program for Mersenne prefactoring

[Christenson]

Originally Posted by Batalov

I've already tried launching "sleep 30; mfaktc" in a Cygwin shell and then disconnect. Some time later you connect and see the same result.
My guess is that the other driver is not initiated (lazily, which is I guess usually a good thing), until I would go and login there physically.
__________

Xyzzy's fish 1 says: "Rirelbar nyjnlf oynzrf zr, jgs?!"

Not quite what I had in mind.....

when physically at the computer, launch a loop that says
sleep 30; if (xyzzy in process table && mfaktc not in process table) mfaktc

then, when away from the computer, launch xyzzy, which contains just a
"sleep 30" while TRUE (or while mfaktc not in process table)
command.

that way, the mfaktc is local and launched locally, and the presence of xyzzy in the process table divorces the remoteness from the mfaktc process.

[Prime95]

Originally Posted by Xyzzy

1:115 here.

That is concerning. What hit rates are others getting for single bit levels of TF?

[Christenson]

Originally Posted by Prime95

That is concerning. What hit rates are others getting for single bit levels of TF?

There's a confounding factor here....I've had P-1 find at least one factor in the middle of my TF range (not on the same exponent), so P-1 could be removing some candidates where xyzzy would otherwise find a factor. 1/70 is what would be expected without any pre-selection.

[nucleon]

Originally Posted by Christenson

Not quite what I had in mind.....

when physically at the computer, launch a loop that says
sleep 30; if (xyzzy in process table && mfaktc not in process table) mfaktc

then, when away from the computer, launch xyzzy, which contains just a
"sleep 30" while TRUE (or while mfaktc not in process table)
command.

that way, the mfaktc is local and launched locally, and the presence of xyzzy in the process table divorces the remoteness from the mfaktc process.

Christenson,

The method you propose fails too. (Sorry - I've tried it also)

The console remembers the last method of logging in. So if you logged remotely with mstsc, and said a sleep-then-run-when-logged-out, it's as though you are still logged in via mstsc and fails.

There's a lot of forum posts on the topic the only work around (for a win box) that's quoted is vnc-ing in. The other alternative is hacking tesla drivers. Which is a bit beyond my abilities (and besides vnc is a lot easier). :)

-- Craig

[Christenson]

Originally Posted by nucleon

Christenson,

The method you propose fails too. (Sorry - I've tried it also)

The console remembers the last method of logging in. So if you logged remotely with mstsc, and said a sleep-then-run-when-logged-out, it's as though you are still logged in via mstsc and fails.

There's a lot of forum posts on the topic the only work around (for a win box) that's quoted is vnc-ing in. The other alternative is hacking tesla drivers. Which is a bit beyond my abilities (and besides vnc is a lot easier). :)

-- Craig

I've said it before, and I'll say it again: What a broken operating system!
What if we made mfaktc more like P95 and gave it a window and all, rather than ran it from the console? Or are we still back to hacking the drivers?

[Christenson]

Originally Posted by Christenson

There's a confounding factor here....I've had P-1 find at least one factor in the middle of my TF range (not on the same exponent), so P-1 could be removing some candidates where xyzzy would otherwise find a factor. 1/70 is what would be expected without any pre-selection.

And there's another confounding/confuzzling factor: Xyzzy, are you counting successes of of your stats page, or from your "results.txt" file? They will be different, as my factors found and reported on manual results keep getting assigned by the server as P-1 results. I only know which are which by noting that all my TF is "manual testing" and looking through my results page, but that seems impractical for the volume you have!

[davieddy]

Originally Posted by Christenson

My actual numbers (ignoring 10 or 15 NFs from the last 24 hours)
247 attempts, mostly in the 50-60M range, a few from the 80M range.
5 factors.

So my original numbers are a bit optimistic, and I can expect to hit a dry spell here as my statistical experience increases.

As for unfinished LLs, the issue is probably that positive feedback from the stats page takes at least a week, maybe two or three months, which is a *very* long time in the "instant" internet age. Almost anything else (LL-D, P-1, TF, ECM) is quicker. So is contributing to NSF@home, or, perhaps more practically, folding@home.

The dedicated don't mind, but the casual don't have that much patience. I'm working on that patience part even for mfaktc, albeit slowly.

That's more like it. Expect 247/70 factors and find 5.
(Don't hold the front page!)

I hope that "dry spell" shit was taking the piss

I know you view GIMPS as "proving candidates composite
as fast as possible", but after a certain bit level (and P-1), the most
effective way of doing this is an LL test... and then who knows?!

David

[davieddy]

Originally Posted by Christenson

There's a confounding factor here....I've had P-1 find at least one factor in the middle of my TF range (not on the same exponent), so P-1 could be removing some candidates where xyzzy would otherwise find a factor. 1/70 is what would be expected without any pre-selection.

That's what I was talking about when I asked
"to what extent do TF and P-1 tread on each other's toes?"

David

[davieddy]

Originally Posted by Prime95

That is concerning. What hit rates are others getting for single bit levels of TF?

As Michael Winner (director of Death Wish 1 to n and celebrity gourmet/advertizer/self-puplicist) would say:
"Calm down dear".

Stats to follow.

David

[Christenson]

Originally Posted by davieddy

<snip>
(Don't hold the front page!) [Correct. The headline already on it is fine -- GPUs smashing through TF assignments; some manual effort still needed]

I know you view GIMPS as "proving candidates composite
as fast as possible", but after a certain bit level (and P-1), the most
effective way of doing this is an LL test... and then who knows?!

David

Even in my extremely narrow view of GIMPS, a point arrives where one *has* to do lots of LL tests...each additional bit level of TF costs twice as much time, so my one hour TF to 70 bits in the 50-60M range becomes 32 hours to 75 bits becomes about a year to 83 bits...and the LL on the range only takes a month or two, then another month or two for the eventual LL-D. I do actually run some LL and LL-D and P-1, all CPU based. The P-1 has been a little bit more effective (GHz days/candidate found composite) than the first-time LL tests.

But, anything we can do to reduce the pfaffing around needed to run mfaktc increases the available TF testing. Then we can think about P-1, and seeing if its worth doing multiple LLs in parallel on GPUs.

I read a bunch of P95 tonight, looking for how P95 does multitasking and taking notes.

The first step of untangling P-1 and TF I began tonight by asking GW how to format mfaktc output when it finds factors so the server always decides its a TF result on the manual results page.

The second step is beyond me; we will need to adjust the P-1 so it doesn't search for candidates in the TF space, or determine that it is not cost-effective to do so. I'm OK if P-1 occasionally finds something in TF space, like 69-70 bits, but, at the moment, it would have been cheaper to finish TF (an hour) rather than spend 4GHz days of CPU on it. My experience is 1 in 10, but the variance on such a small sample is notoriously high.

[davieddy]

I'll let you off this time for not [/quote]Your Comment[quote]ing
in the middle of my original.

The idea behind GIMPS is to find Mersenne primes.
(Checkout the acronym).

David

PS "Credit" for work done is not any part of my incentive.
Obviously $$$$ isn't either for any of us.
I would hope that some of my posts here have been constructive/entertaining though.

PPS I think factors found by P-1 are typically a few bits bigger than "how far TFed". Bugs excepted, they couldn't be lower of course.