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.

[QUOTE=Christenson;263195]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.[/QUOTE]It's a GTX460.

I agree with your cost-benefit analysis.

Paul

[QUOTE=xilman;263181]Of course, if uncwilly would rather have no contribution if favour of his desired pattern of contribution ...[/QUOTE]
By no means. I am just offering some ideas..... Your GPU is besting all of my borg boxen.

(possibly common feature for any GPU programs)
 

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
[CODE]$ ./mfaktc-win-64.exe
mfaktc v0.17-Win (64bit built)
cudaSetDevice(0) failed
cudaGetLastError() returned 38: no CUDA-capable device is detected
[/CODE]
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

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

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.

[QUOTE=Christenson;263172]
I'm running about 1 in 30 successful TFs right now,[/QUOTE]

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

[QUOTE]In what range are the exponents?
One extra bit or more?[/QUOTE]1:115 here.

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

The sample size is > 9000 tested.

:sad:

[QUOTE=Christenson;263640]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.[/QUOTE]
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.
__________

[SIZE=1][COLOR=blue]Xyzzy's fish 1 says: "Rirelbar nyjnlf oynzrf zr, jgs?!"[/COLOR][/SIZE]

[QUOTE=xilman;263160]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[/QUOTE]

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?

[QUOTE=davieddy;263646]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[/QUOTE]

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.