mfaktc: a CUDA program for Mersenne prefactoring

[Christenson]

I suspect your two factors per day is a reflection of your "better" GPU -- mine's "only" a mid-range card, a GTX440. As for bumping up the bit level, it sounds nice in theory, but actual project progress is made by finding factors at least effort and eliminating exponents from LL tests. Breadth-first, rather than depth-first, does the best job of that, and most of us find faffing about more expensive than copying and pasting a bit more.

[xilman]

Originally Posted by Christenson

I suspect your two factors per day is a reflection of your "better" GPU -- mine's "only" a mid-range card, a GTX440. As for bumping up the bit level, it sounds nice in theory, but actual project progress is made by finding factors at least effort and eliminating exponents from LL tests. Breadth-first, rather than depth-first, does the best job of that, and most of us find faffing about more expensive than copying and pasting a bit more.

It's a GTX460.

I agree with your cost-benefit analysis.

Paul

[Uncwilly]

Originally Posted by xilman

Of course, if uncwilly would rather have no contribution if favour of his desired pattern of contribution ...

By no means. I am just offering some ideas..... Your GPU is besting all of my borg boxen.

[Batalov]

I have found an interesting "feature" (it is probably not a feature of mfaktc, but of CUDA and/or specific CUDA calls... maybe there exists a bypass for it).

1. mfaktc runs fine. It finishes its chunk and stops.
2. you connect to the same computer using remote desktop (in my case from a 32-bit XP console to a 64-bit Win7), replenish worktodo.txt
3. you try to run the binary and you get

$ ./mfaktc-win-64.exe
mfaktc v0.17-Win (64bit built)
cudaSetDevice(0) failed
  cudaGetLastError() returned 38: no CUDA-capable device is detected

4. you go to the computer physically, and then mfaktc again runs fine.
5. (another detail: to make matters possibly more convoluted, this particular remote connection is over VPN)

Is there a way to tell CUDA to query the local hardware, not that of the remote console's? Granted, both computers do some tricks in remote desktop mode: for example, both remote and local printers are available, etc. Same (?) goes for the graphics device(s)? So some expertise in what Windows actually does for implementing remote connection is needed (I don't have any such expertise). Knowledgeable people, please help?


P.S. "./mfaktc-win-64.exe -d 1", "-d 2" etc fail all the same

[nucleon]

I've done a bit of googling on this.

Apparently there's no work around for non-tesla cards. The tesla drivers allow this to work. This is using mstsc to remote into the box.

Vnc on the other hand works but is incredibly slow.

I find the best way is to use mstsc log on the remote box to set things up (cmd window type the command but dont press enter etc...). Then vnc in, just to press enter, make sure it loads, then re-log in with mstsc.

-- Craig

[Christenson]

possibly write a program that runs in an infinite loop, looking for "xyzzy" in the process table..when it sees it, it launches mfaktc if it's not already also in the process table. Start locally. Xyzzy is just sleep(100) or something.

[davieddy]

Originally Posted by Christenson

I'm running about 1 in 30 successful TFs right now,

In what range are the exponents?
One extra bit or more?
1/30 doesn't exactly tally with the 1/70 probability
of a factor between 2^70 and 2^71.

David

[Xyzzy]

In what range are the exponents?
One extra bit or more?

1:115 here.

53M range. 69 to 70 or 70-71.

The sample size is > 9000 tested.

[Batalov]

Originally Posted by Christenson

possibly write a program that runs in an infinite loop, looking for "xyzzy" in the process table..when it sees it, it launches mfaktc if it's not already also in the process table. Start locally. Xyzzy is just sleep(100) or something.

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

[davieddy]

Originally Posted by xilman

I take what the server gives me. The organizers of the project are much more likely to know better than I what my resources should be doing.

Paul

Thinking outside the box (smile), the original aim of the project
was to find new MPs as quickly as possible. Of course, there have
been great spinoffs from the venture, which is just as well since
a reasonable expectation from now on is one MP per 6 years.

I monitor the "Primenet summary" page carefully, and find it
a bit sad that most LL assignments get returned unfinished.*

If the primary goal is to find another MP asap, TF and P-1 needs
to be be done between 53M and 60M for the couple of years the
LL wavefront will take to sweep that range.

David

*Surely if an assignment is returned having had a significant
fraction of the work needed performed on it, it would
be worthwhile preserving the iteration number and residue, wouln't it?

[Christenson]

Originally Posted by davieddy

In what range are the exponents?
One extra bit or more?
1/30 doesn't exactly tally with the 1/70 probability
of a factor between 2^70 and 2^71.

David

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.