[QUOTE=Chuck;274111]I am using the EVGA precision utility which allows for overclocking, but also displays GPU usage statistics. You could also use MSI Afterburner, a different skin but performs the same functions.

Chuck[/QUOTE]

Or GPU-Z

[QUOTE=NBtarheel_33;274086]How much CPU should typically be allocated to each instance of mfaktc? I was working with an 8-core Nehalem Xeon system @ 2.66 GHz with 2 Fermi GPUs. At first, I had Prime95 TFing on all 8 cores, as well as 2 instances of mfaktc going on the GPUs. I noticed that three of the CPU cores were slower than the others, so I stopped their workers, and ran 5 TF CPU cores, and two instances of mfaktc. Things picked up nicely at this point. I also experimented with a third instance of mfaktc; it slowed the GPUs down into the 65-70M/sec range.

If we have X GPUs, should we run exactly X copies of mfaktc, or does it make more efficient use of the GPUs to run more?[/QUOTE]
It's not mfaktc threads per GPU, it's CPU cores per GPU, and it's just an accident that it's one mfaktc thread per CPU core.

Rephrase that: One CPU core may or may not be enough to saturate the GPU. If not, run a second core on the same GPU. In order to actually do this, you run a second mfaktc instance. So figure out how many cores are necessary to saturate the GPU, then run that number of mfaktc's.

Now, the other MAJOR piece of advice: please Please PLEASE set each mfaktc thread to run on a [I]specific core[/I]. When I ran three cores P95 with one mfaktc, the P95's got about 80% efficiency, and the fourth core got 50% efficiency, without setting mfaktc to a specific core. I figured out (with help on the forum) how to do that, and both P95 and mfaktc performance went up dramatically. The Windows or Linux scheduler isn't designed to handle such specific things. In Windows, you can set the "affinity" of each process under the Process tab on the Task Manager by right clicking on whatever process you want. Please try this before putting more than one CPU core per GPU. I'd think one Nehalem core would be pretty good for a GPU, unless it's like a 590 or something.

Note: You'll need to know which cores P95 is using to avoid setting the wrong affinity.

[QUOTE=Dubslow;274199]Or GPU-Z[/QUOTE]

Right, that's a better choice since it is a monitoring utility. I have it on the desktop and forgot about it since I haven't used it for a few months.

Chuck

[QUOTE=Dubslow;274200]It's not mfaktc threads per GPU, it's CPU cores per GPU, and it's just an accident that it's one mfaktc thread per CPU core.

Rephrase that: One CPU core may or may not be enough to saturate the GPU. If not, run a second core on the same GPU. In order to actually do this, you run a second mfaktc instance. So figure out how many cores are necessary to saturate the GPU, then run that number of mfaktc's.

Now, the other MAJOR piece of advice: please Please PLEASE set each mfaktc thread to run on a [I]specific core[/I]. When I ran three cores P95 with one mfaktc, the P95's got about 80% efficiency, and the fourth core got 50% efficiency, without setting mfaktc to a specific core. I figured out (with help on the forum) how to do that, and both P95 and mfaktc performance went up dramatically. The Windows or Linux scheduler isn't designed to handle such specific things. In Windows, you can set the "affinity" of each process under the Process tab on the Task Manager by right clicking on whatever process you want. Please try this before putting more than one CPU core per GPU. I'd think one Nehalem core would be pretty good for a GPU, unless it's like a 590 or something.

Note: You'll need to know which cores P95 is using to avoid setting the wrong affinity.[/QUOTE]

I have tried fiddling with the CPU affinities, but any changes I make have ended up slowing things down.

Hmm. My gut-reaction guess would be that without setting a cpu, the scheduler sets as much time on as many cores as mfaktc can use, but then setting the affinity limits the cpu to the amount of work that one core can do. This would mean that mfaktc uses more than one core's worth of power to keep up with the 580, and without the affinities set, the scheduler lets it have that time. Have you tried setting mfaktc to two or three cores?

Let me do that again after reviewing your hardware: You have two separate instances of mfaktc to saturate just one 580, and four simultaneous P95 threads? Okay. Do you use the "best cpu" setting in P95, or do you set that to use specific CPU's? If you set mfaktc affinities without P95 doing the same, the scheduler could still create interference between the two. If P95 is already set, then...

Try one mfaktc instance with affinity set to two cores (obviously the ones not in use by P95). If not, try the two instances you currently use, and set them each to one core. If not, then I'm not really sure. What cpu affinity settings have you already tried?

[QUOTE=Chuck;274242]I have tried fiddling with the CPU affinities, but any changes I make have ended up slowing things down.[/QUOTE]

Some things to be aware of, but you may already know:
1) P95 tries to run at lowest priority, and has some intelligence about cores and threads.
2) mfaktc, as currently written, is 1 instance, one thread. When it starts communicating automatically, it will gain a communications thread, but it still is really not aware of processes or threads except on the GPU side. So each instance is running at whatever priority it inherits from the window it starts in, unless you fool with it in task manager.
3) mfaktc is modelled as Sieve on CPU feeds factor candidates to test on GPU. That means that increasing CPU performance to feed more or better factor candidates takes CPU away from P95.

[QUOTE=Dubslow;274200]Now, the other MAJOR piece of advice: please Please PLEASE set each mfaktc thread to run on a [I]specific core[/I]. When I ran three cores P95 with one mfaktc, the P95's got about 80% efficiency, and the fourth core got 50% efficiency, without setting mfaktc to a specific core. I figured out (with help on the forum) how to do that, and both P95 and mfaktc performance went up dramatically. The Windows or Linux scheduler isn't designed to handle such specific things. In Windows, you can set the "affinity" of each process under the Process tab on the Task Manager by right clicking on whatever process you want. [/QUOTE]

This needs to be placed somewhere on the GPU FAQ. I just came upon this piece of advice; tried it, and it is indeed very important.

2^?
what is the max exponent i can use in mfaktc ?

Bigger then you need. Theoretically unlimited. As the exponent goes higher, less candidates have to be tested for each bit level, and the amount of work that need to be done for the same bit level is lower. Practically, there might be a hardware cap somewhere at 64, or 80, or 96 bits, who cares? It would not make too much sense to go over 10G.

The range below 1G is handled by Primenet, the higher ranges by OBD projects. Beside of strange experimenting, there will be totally NO NEED to go higher then 10G.

Better question would be "what is the maximum bitlevel" for a factor. That is somewhere at 92 or 96 bits, again bigger then one needs with the current available hardware (speeds).

I think, as currently designed, mfaktc has a hard limit of 32-bit exponent (2^32-1). There might be other internal limitations that reduces this even further. Try running mfaktc with 4294967291, the largest 32-bit prime, and see if it accepts it.

[QUOTE=NormanRKN;306164]2^?
what is the max exponent i can use in mfaktc ?[/QUOTE]

[QUOTE=LaurV;306166]Bigger then you need. Theoretically unlimited. As the exponent goes higher, less candidates have to be tested for each bit level, and the amount of work that need to be done for the same bit level is lower. Practically, there might be a hardware cap somewhere at 64, or 80, or 96 bits, who cares? It would not make too much sense to go over 10G.

The range below 1G is handled by Primenet, the higher ranges by OBD projects. Beside of strange experimenting, there will be totally NO NEED to go higher then 10G.

Better question would be "what is the maximum bitlevel" for a factor. That is somewhere at 92 or 96 bits, again bigger then one needs with the current available hardware (speeds).[/QUOTE]

[QUOTE=axn;306167]I think, as currently designed, mfaktc has a hard limit of 32-bit exponent (2^32-1). There might be other internal limitations that reduces this even further. Try running mfaktc with 4294967291, the largest 32-bit prime, and see if it accepts it.[/QUOTE]

I found a limit on the size of k in the valid assignment checker.

[code]int ret = 1;

if(exp < 1000000) {ret = 0; if(verbosity >= 1)printf("WARNING: exponents < 1000000 are not supported!\n");}
else if(!isprime(exp)) {ret = 0; if(verbosity >= 1)printf("WARNING: exponent is not prime!\n");}
else if(bit_min < 1 ) {ret = 0; if(verbosity >= 1)printf("WARNING: bit_min < 1 doesn't make sense!\n");}
else if(bit_min > 94) {ret = 0; if(verbosity >= 1)printf("[U]WARNING: bit_min > 94 is not supported![/U]\n");}
else if(bit_min >= bit_max) {ret = 0; if(verbosity >= 1)printf("WARNING: bit_min >= bit_max doesn't make sense!\n");}
else if(bit_max > 95) {ret = 0; if(verbosity >= 1)printf("[U]WARNING: bit_max > 95 is not supported![/U]\n");}
else if(((double)(bit_max-1) - (log((double)exp) / log(2.0F))) > 63.9F) /* this leave enough room so k_min/k_max won't overflow in tf_XX() */
{ret = 0; if(verbosity >= 1)printf("[U]WARNING: k_max > 2^63.9 is not supported![/U]\n");}[/code]

With those limits, the maximum exponent is somewhere around [URL="http://www.wolframalpha.com/input/?i=solve%202%5E95%3D2*2%5E63.9*p&t=crmtb01"]1.15081*10[sup]9[/sup][/URL], or just north of 1G, or just over a quarter of axn's limit.

[url]http://www.wolframalpha.com/input/?i=primes+near+1.15081*10%5E9[/url]

Edit: It's probably not that hard to modify the code to go higher, but I'll let axn/TheJudger/other knowledgeable persons speak to that.