Hi,

[QUOTE=aaronhaviland;367640]Well, this card is running at higher clocks: nvidia-settings reports 1346MHz (and 85W according to EVGA), and mfaktc is showing ~177GHz-days/day. Which is interesting, as the card is only supposed to boost up to 1268MHz...
[URL]http://www.evga.com/Products/Product.aspx?pn=02G-P4-3757-KR[/URL]
[/QUOTE]

1268MHz is the "average boost clock", not the max boost clock. Don't ask me how Nvidia measures the average boost (which workloads they use) but at least for mfaktc I can say the on non-CC 2.0 GPUs mfaktc keeps well below TDP thus on recent cards with GPU boost you'll see usually high boost clocks.

The reported performance looks fine to me, a step in the right direction for mfaktc. :smile:

Oliver

Also regarding the clocks... I think the boost "amount" can get changed as well. I could be wrong. It's a nightmare for overclocking and I don't know why they do it that way. Just wait for a card to overclock itself to instability by boosting up that one extra step it can't handle...

Hey James, I might have an idea how to (partially) solve the speed problem with those graphs: you don't show them :razz:

Now seriously, when we access the "lucas" page (hey, btw, when are you going to include the AMD cards on the "lucas" performance page? remark I did not say "cudalucas", now cllucas has comparative performance, at least for 37M range, and with new FFT libraries and new R*90 cards, it can still get better, but this is another discussion), so when we access the "lucas" page, there is no graph shown. Then the user click on some card, and he sees the (whatever) graph. Which, in my opinion, is quite convenient.

Letting apart the fact that those graphs were card-specific, and it could not be implemented differently, the idea is that you can also make the mfaktX graphs to be "card specific", i.e. you can implement it in the same way on the "mfaktX" page: when the user accesses the page, there is no graph. Fast, as it was before. If he wants to see some graph, he clicks on his card, then he can see the graph, exactly as it is now, but with the clicked card in a different color (like blue, instead of the red/green used now).

[QUOTE=LaurV;367669]hey, btw, when are you going to include the AMD cards on the "lucas" performance page? remark I did not say "cudalucas", now cllucas has comparative performance, at least for 37M range, and with new FFT libraries and new R*90 cards, it can still get better, but this is another discussion[/quote]When I get some performance data. I can't chart things I don't know about. If people want to send me benchmarks I will make room for AMD on the [strike]cuda[/strike]lucas page.

[QUOTE=LaurV;367669]If he wants to see some graph, he clicks on his card, then he can see the graph, exactly as it is now, but with the clicked card in a different color (like blue, instead of the red/green used now).[/QUOTE]Implemented as suggested.

[QUOTE=James Heinrich;367671]When I get some performance data. I can't chart things I don't know about. If people want to send me benchmarks I will make room for AMD on the [strike]cuda[/strike]lucas page.

Implemented as suggested.[/QUOTE]

I think (only my opinion) the CUDALucas benchmark numbers look better with FFT length(1024K, 2048K, etc) instead of rough exponent size.

@James: Thanks. Now, it looks perfect.

@kracker: they translate straight from one to the other, you just need a table (or cheat-sheet), or use an excel with a formula. IIRC, there is a link in James' page to a calculator, also. Showing FFT instead of exponents will favor AMD cards if only powers of 2 are chosen, or will favor nVidia, if not.

I like the actual format (i.e. show the exponent, most users have no idea what that "FFT" is, not all gimps participants are math hobbysts).

[QUOTE=LaurV;367677]@James: Thanks. Now, it looks perfect.

@kracker: they translate straight from one to the other, you just need a table (or cheat-sheet), or use an excel with a formula. IIRC, there is a link in James' page to a calculator, also. Showing FFT instead of exponents will favor AMD cards if only powers of 2 are chosen, or will favor nVidia, if not.

I like the actual format (i.e. show the exponent, most users have no idea what that "FFT" is, not all gimps participants are math hobbysts).[/QUOTE]

I see. Well, I just jotted down those numbers from my head just to give a example :razz:

reporting 750 ti
[code]
mfaktc v0.20 (64bit built)

Compiletime options
THREADS_PER_BLOCK 256
SIEVE_SIZE_LIMIT 32kiB
SIEVE_SIZE 193154bits
SIEVE_SPLIT 250
MORE_CLASSES enabled

Runtime options
SievePrimes 25000
SievePrimesAdjust 1
SievePrimesMin 5000
SievePrimesMax 100000
NumStreams 3
CPUStreams 3
GridSize 3
GPU Sieving enabled
GPUSievePrimes 82485
GPUSieveSize 64Mi bits
GPUSieveProcessSize 16Ki bits
WorkFile worktodo.txt
Checkpoints enabled
CheckpointDelay 30s
Stages enabled
StopAfterFactor bitlevel
PrintMode compact
V5UserID (none)
ComputerID (none)
AllowSleep no
TimeStampInResults yes

CUDA version info
binary compiled for CUDA 4.20
CUDA runtime version 4.20
CUDA driver version 6.0

CUDA device info
name GeForce GTX 750 Ti
compute capability 5.0
maximum threads per block 1024
number of mutliprocessors 5 (unknown number of shader cores)
clock rate 1110MHz

Automatic parameters
threads per grid 655360

running a simple selftest...
ERROR: cudaGetLastError() returned 8: invalid device function
[/code]
edit: just spotted [url]http://www.mersenneforum.org/showthread.php?p=369671[/url], so i'm not alone

A small bug might be present in mfaktc when finding factors.

I have made sure my ini file has stopafterfactor = 1 and in fact has always worked before. This time around the work was resumed after a ctrl+c break and upon launching mfaktc again it found a factor straight away yet decided to keep working until the end of the bit level.

picture for support...
[url]http://rapidshare.com/share/22572B26ECFF1C96608EED7AED3F28B8[/url]

[QUOTE=Flow;371465]stopafterfactor = 1 ... found a factor straight away yet decided to keep working until the end of the bit level.[/QUOTE]Sounds like it's working as intended:[code]# possible values for StopAfterFactor:
# 0: Do not stop the current assignment after a factor was found.
# 1: When a factor was found for the current assignment stop after the
# current bitlevel. This makes only sense when Stages is enabled.
# 2: When a factor was found for the current assignment stop after the
# current class.
#
# Default: StopAfterFactor=1[/code]If you want it to stop immediately on finding a factor then you should have [b]StopAfterFactor=[color=red]2[/color][/b]

[QUOTE=James Heinrich;371469]If you want it to stop immediately on finding a factor then you should have [b]StopAfterFactor=[color=red]2[/color][/b][/QUOTE]

I could've sworn I was seeing factor founds stopping right away. Anyway here goes not reading the documentation. Care to enlighten me as to what the purpose of finishing the bit level is? I can only assume another factor could be possible but is it actually beneficial to the project to know more than one?