Hi! In README.txt write's:
[QUOTE]Primenet doesn't accept "no factor" results from mfaktc. Offcourse you can report new factors to the primenet via manual result reports.[/QUOTE]
But amphoria upload "no factor" to primenet. For example:
[url]http://www.mersenne.org/report_exponent/?exp_lo=332192897&exp_hi=&B1=Get+status[/url]
[url]http://www.mersenne.org/report_exponent/?exp_lo=332193233&exp_hi=&B1=Get+status[/url]

How to? :help:

[QUOTE=Lorenzo;232099]Hi! In README.txt write's:

But amphoria upload "no factor" to primenet. For example:
[url]http://www.mersenne.org/report_exponent/?exp_lo=332192897&exp_hi=&B1=Get+status[/url]
[url]http://www.mersenne.org/report_exponent/?exp_lo=332193233&exp_hi=&B1=Get+status[/url]

How to? :help:[/QUOTE]

You copy and paste the lines from results.txt into the manual results form on [url]www.mersenne.org[/url].

[QUOTE=Lorenzo;232099]Hi! In README.txt write's:

But amphoria upload "no factor" to primenet.[/QUOTE]

The Readme is apparently out of date. PrimeNet accepts both factors and no-factor lines from Mfaktc, as you can see at [url]http://www.mersenne.org/manual_result/[/url] when you click Submit (even with blank data): "Mfaktc no factor lines found: 0". AFAIK you still have to submit it in the manual results form, but it does accept them.

[B]Mini-Geek[/B], [B]amphoria[/B] Thank you!

[QUOTE=Mini-Geek;232105]The Readme is apparently out of date. PrimeNet accepts both factors and no-factor lines from Mfaktc, as you can see at [url]http://www.mersenne.org/manual_result/[/url] when you click Submit (even with blank data): "Mfaktc no factor lines found: 0". AFAIK you still have to submit it in the manual results form, but it does accept them.[/QUOTE]

At the time when mfaktc 0.11 was released the primenet manual result checking didn't accept the results. But shortly after the release George enabled them. :smile:
The README.txt from version 0.12 is updated. (removed the "known issue" but didn't explicit mention that it is possible)

Oliver

Hi,

Raw GPU benchmark on my GTX 275 (1458MHz shader clock):
[CODE]
kernel | M66362159 above 2^64 | M3321932839 above 2^64
-------+----------------------+--------------------------
71bit | 80.9M/s | 62.6M/s mfaktc 0.12
75bit | 64.6M/s 79.8% | 49.9M/s 79.7%
95bit | 52.1M/s 64.4% | 40.3M/s 64.4%
79bit* | 60.1M/s 74.3% | 46.8M/s 74.8%
92bit* | 56.0M/s 69.2% | 43.6M/s 69.6%
[/CODE]

Only 15-16% (depending on exponent size) improvement for factors in the range 2^75 to 2^79 and 7-8% for factors from 2^79 to 2^92. :sad:
But hey, it is still an improvement. :smile:

Oliver

mfaktc 0.12 Windows x64 Performance
 

Hey all,

I'm back to having a bit of time for mfaktc activity -- great to see the progress you made this summer, Oliver!

I've got an 0.12 Windows x64 build w/ CUDA 3.1 compiled with amphoria's makefile and will attach it. Haven't looked at the speed effects (+ or -) of 3.2 on Windows yet.

On my machine (Windows 7 x64 / 260.63 Driver / 3300Mhz i5 / GTX 470 @ 660 core), the long selftest finishes fine, and -tt produces:

[CODE]checking timer functions
400970967 time measurements within ten seconds
negative steps: 0
zero steps: 391028052
positive steps: 9942915
smallest (non-zero) time step: 1usec
biggest time step: 376usec[/CODE]


and with RAW_GPU_BENCH the numbers look like:

[CODE]kernel | M66362159 above 2^64 | M3321932839 above 2^64
-------+----------------------+--------------------------
71bit | 111.6M/s | 84.4M/s mfaktc 0.12
75bit | 205.2M/s 183.8% | 152.9M/s 181.2%
95bit | 169.1M/s 151.5% | 126.5M/s 149.9%
79bit* | 255.0M/s 228.5% | 193.2M/s 228.9%
92bit* | 232.4M/s 208.3% | 174.8M/s 207.1%[/CODE]

In practical terms, running with the siever and AUTOSELECT_KERNEL, -tf 66362159 64 65 hits 144M/s with one instance (51s to complete), 125M/s with 2 instances running, and around 85M/s with 3 instances running, so two instances just about fully occupy the GPU.

Cheers,

Ethan

BTW the GTX 470 scales linearly w/ clock frequency for the raw gpu tests, at least up to 860MHz; I see about 329M/s for the bar79 kernel on 66362159 @ 64bits at that speed.

I don't trust overclocked GPUs at all at this point -- we don't have enough information about the reliability of factory-clocked cards. Oliver, are you actively working on the self-test functions at all right now? If not, I may poke around and see about trying to create a rough equivalent to the prime95 torture test mode; at the very least we can just cycle through the existing self test indefinitely while displaying a running error count.

Cheers,

ethan

I once researched the area of GPU instability.Came to several conclusions:
While memory can very well be stable when tortured by Memtest-CUDA or Memtest-OpenCL, it will immediately crash if you run something which will stress everything - like FurMark.

Shaders can be app-stable and game-stable(rock stable).
App-stable shaders can run any cuda/opencl app 24/7 and it wont crash, bsod or produce errors. However, if you start playing a game, it will crash pretty soon.

That's why I dont trust stress testers that only torture shaders.
Actually, a fellow coder once wrote a shader stress-tester in OpenCL, which will hash passwords on CPU, then do the same n times on GPU, and compare results each time.I've attached that application(source code included). What's curious, I was able to OC my old GTX 285's shaders up to 1.8 Ghz, and it was stable on that application.Which is totally wrong. The upper stable frequency was 1548 Mhz(FurMark and OCCT-GPU proof).

Hi Ethan,

[QUOTE=Ethan (EO);233150]I don't trust overclocked GPUs at all at this point -- we don't have enough information about the reliability of factory-clocked cards. Oliver, are you actively working on the self-test functions at all right now? If not, I may poke around and see about trying to create a rough equivalent to the prime95 torture test mode; at the very least we can just cycle through the existing self test indefinitely while displaying a running error count.[/QUOTE]

the selftest is designed to test the code / binaries. Each selftest dataset usually means that some million factor candidates are processed while I only check if the one known factor is found. This isn't a real hardware test.
I've tested overclocking once on my GTX 275... I wasn't able to produce false results doing so... while increasing the clocks of the GPU at some point the machine crashes.

I'm current not working on the selftest functions, if you want you could try. But I'm not sure how useful this would be. In contrast to the LL test (where a single computational error usually means a false result) TF is relative robust to computational errors. A single computational error (on the GPU) usually harms only a single factor candidate. A flipped bit in the sieve code would do more damage.

I'm currently working on the stream scheduler (mostly tf_common.h and a little bit in mfaktc.c). It handles multiple instances of mfaktc on one GPU better than before. It tollerates more jitter in kernel runtimes because it allows to preprocess more than one h_ktab[]. This was initially suggest from you?

Oliver

[QUOTE=TheJudger;233208]Hi Ethan,
In contrast to the LL test (where a single computational error usually means a false result) TF is relative robust to computational errors. A single computational error (on the GPU) usually harms only a single factor candidate. A flipped bit in the sieve code would do more damage.
[/QUOTE]

I agree - and of course, even beyond that, a missed factor within the context of GIMPS just means an extra LL test. Of course, to the degree that the database of factoring test depths is used for other uses, it's good to have it accurate. So, I don't intent for a mfaktc extended self-test to be a general certification of an overclock, but just to get some sense of the odds that we miss a factor.

Actually, what made me wonder about this is that I _was_ able to make my 470 miss a factor in the selftest with a not-too-severe overclock! This occured during one of three selftests that I ran, so that means one error out of under 15000 tests. Not so terrible, I suppose, when multiplied by the fraction of exponents which will have detectable factors, but it was unsettling nonetheless.

Glad to hear you're working on the scheduler! I'm ready to give testing feedback for Windows any time :)

cheers,

Ethan