[QUOTE=S34960zz;255357]Was this tongue-in-cheek, or am I mis-understanding something? With NumStreams=3 and CPUStreams=3 (matching Brain's settings), the GPU was running at 98+ percent. What would the expected outcome be for multiple mfaktc instances in this case?

Since yesterday, as an experiment, I've been running one core LL-D, two cores LL, and one core mfaktc feeding the GPU. Seems to be working okay.[/QUOTE]
It was bad reading:blush:
I read that you used a GT540 and were getting that speed.

mfaktc_v016p1 (Win64) ignores checkpoint file
 

mfaktc_v016p1 (Win64).

In the "mfaktc.ini" file, I had been using:
Stages=0
StopAfterFactor=0

This morning I changed those settings to:
Stages=1
StopAfterFactor=1

because PrimeNet places little value on carrying the factoring exercise any further (which is completely reasonable given PrimeNet's goals) (both of the table entries below were checked from 2^65 to 2^72).

[Code]
CPU Name
Exponent Result Received age Result GHz-Days
----------------------------------------------------------------------------
Manual testing
82463449 F 2011-03-23 13:40 5.9 141138476285857942999 0.2145
----------------------------------------------------------------------------
Manual testing
82463383 NF 2011-03-22 20:40 5.2 no factor for M82463383 11.5086
from 2^65 to 2^72
[mfaktc 0.16p1-Win barrett79_mul32]
----------------------------------------------------------------------------[/Code]After changing the Stages and StopAfterFactor settings and re-starting mfaktc, it ignored the checkpoint file for the present exponent and started factoring from the beginning again (discarding several hours' work).

To test what was going on, I pulled the checkpoint file from the backup I had made just before changing settings, changed the Stages and StopAfterFactor settings back, and tried again. This time, mfaktc found and used the checkpoint file.

Is this expected behavior?

Hello!

[QUOTE=S34960zz;256443]Is this expected behavior?[/QUOTE]

Yes.
Reason: if Stages is set to 1 than mfaktc will run from e.g. 2^65 to 2^68 in the first run, from 2^68 to 2^69 in the second run, from 2^69 to 2^70 after that and so on. In the other case (Stages=0) it will process from 2^65 to 2^72 at once. The lower and upper bound of the current run is stored in the checkpoint file.

Technically it would be possible to accept an checkpoint file with an higher bound than the current run but for simplicity this is not implemented.

Oliver

Standby/Hibernate
 

For "ordinary" programs it may be common to handle standby/hibernate and the corresponding wake-up automatically (or have that handled by the OS). So this seems to be quite safe (apart from some DVD burner apps, maybe).

I just wanted to check if anyone can tell me the same for CUDA/mfactc. Will the GPU continue the last stream after a wake-up? Or would mfactc need to re-transmit the data (I did not check, maybe it is already doing this?)?

Or, to put it simple, is there a chance to miss a factor by putting the system to sleep/hibernate while running mfactc?

Thanks for any advice

Bdot,

I've no code inside mfaktc which handles standby/hibernate and I think the OS is unable to save/restore GPU memory and register state. I've no clue what happens if you hibernate while running mfaktc, best case it will crash because the "GPU setup" (allocated memory, ...) is missing.

Oliver

Is there a workaround to start it via RDP on a windows platform? When I start the executable via RDP, I get this error:

[code]
cudaSetDevice(0) failed
cudaGetLastError() returned 38: no CUDA-capable device is detected
[/code]

Even though it works fine when logged in via console.

-- Craig

[QUOTE=TheJudger;256639]best case it will crash because the "GPU setup" (allocated memory, ...) is missing.
[/QUOTE]

Well, it does not crash. It just looks like this:

[QUOTE]
1220/4620 | 2.35G | 213.40s | 11.03M/s | 100000 | 1d17h | 35111us
1224/4620 | 2.35G | 29457s | 0.08M/s | 100000 | 240d08h | 9820408us
1229/4620 | 2.35G | 212.67s | 11.06M/s | 100000 | 1d17h | 34007us
1232/4620 | 2.35G | 6620.2s | 0.36M/s | 100000 | 53d20h | 2178381us
1233/4620 | 2.35G | 218.98s | 10.75M/s | 100000 | 1d18h | 35948us
[/QUOTE]

It appears the stream is finished in some determined way so that the program continues. It just measures a very long delay.

I do have mfaktc running on a low-end machine. Are there any modifications I can make to try and get a little better performance out of it? This is what I'm getting on a 76M number on an i5 540M 2.5 Mhz with a 3100M GPU -

class | candidates | time | avg. rate | SievePrimes | ETA | avg. wait
1353/4620 | 321.91M | 62.348s | 5.16M/s | 100000 | 11h45m | 176596us
1356/4620 | 321.91M | 62.351s | 5.16M/s | 100000 | 11h44m | 176788us
1360/4620 | 321.91M | 62.350s | 5.16M/s | 100000 | 11h43m | 177036us

Thanks,
Doug

[QUOTE=drh;257103]I do have mfaktc running on a low-end machine. Are there any modifications I can make to try and get a little better performance out of it? This is what I'm getting on a 76M number on an i5 540M 2.5 Mhz with a 3100M GPU -

class | candidates | time | avg. rate | SievePrimes | ETA | avg. wait
1353/4620 | 321.91M | 62.348s | 5.16M/s | 100000 | 11h45m | 176596us
1356/4620 | 321.91M | 62.351s | 5.16M/s | 100000 | 11h44m | 176788us
1360/4620 | 321.91M | 62.350s | 5.16M/s | 100000 | 11h43m | 177036us

Thanks,
Doug[/QUOTE]

Me too, Galaxy GEForce 210 (CUDA 1.2) on Pentium 4 under Windows XP, running mfaktc. Really slows down the video response (have dual screens/dual view on) when running, even with both stream parameters at 1.

I don't care at night, when I'm not using the machine, but daytime I have to stop mfaktc to do the "real" work.

Warning, don't upload huge result files with the manual result form. I've just tried to upload 1920 results from one file... seems to be too much for one request. :sad:

Oliver

[QUOTE=TheJudger;257311]Warning, don't upload huge result files with the manual result form. I've just tried to upload 1920 results from one file... seems to be too much for one request. :sad:

Oliver[/QUOTE]

Was this via cut-and-paste or by browsing to your results.txt file and allowing that file to upload?

The cut-and-paste form specifically suggests no more than 4k = 4096 bytes, more-or-less, at a time.