[QUOTE=Karl M Johnson;260741]It works!
GPU usage at 43%.[/QUOTE]
Only 16x as fast as my 8600GTS
The sleep works for me as well using 2% of cpu at sieveprimes=5000(at total throughput of 4/5 so I get 4/5 the max mfaktc performance for 8% of a core).:smile:

I've just noticed that both mfaktc instances are constantly using both cores of CPU(24~25% for each process). The GPU does not let the CPU sleep:smile:

[QUOTE=Karl M Johnson;260746]I've just noticed that both mfaktc instances are constantly using both cores of CPU(24~25% for each process). The GPU does not let the CPU sleep:smile:[/QUOTE]

I think that jumping between cores is a function of your OS. On Windows, use task manager to set the specific CPU core affinity. I don't think the lumpiness is on a large enough scale to actually let the machine sleep, but it does let you use the remainder of your CPU for other things, including Prime95 and running applications.

[QUOTE=Christenson;260725]I am also not sure I like what I suggested for log file handling.[/QUOTE]I understand the issues you're trying to balance, but I don't particularly want any program truncating my results file. Or at least give me the option of maxlogfilesize=0 to never-truncate, please.

[QUOTE=James Heinrich;260748]I understand the issues you're trying to balance, but I don't particularly want any program truncating my results file. Or at least give me the option of maxlogfilesize=0 to never-truncate, please.[/QUOTE]
Of course...this is why we are discussing the issues involved and how best to resolve them...I mean, it isn't exactly difficult to call up the text editor and do the job yourself....and I'm expecting anyone that *could* run out of space for log files due to the high productivity of their card to have around 10s of Gigs of free space, since it's getting hard to find disks under 120Gig these days.

P.S. Taking disks apart for my employer yesterday was remarkably easy, just a couple of Torx drivers, and, since I was destroying them, bending them a bit to get them off the hubs. Then hit the disk surfaces with the bead blaster and bent in an arbor press. The crazy one was the IBM, which split down the middle lengthwise, rather than lifting off the cover on one flat side.

"Black Screen"
 

Sometimes, when stopping mfaktc by CTRL-C, my 270.61 display drivers fails. After some seconds of "black" I get the attached error message (not very informative). I've noticed this in 0.16 and 0.17. I start mfaktc via a batch file: [CODE]start "mfaktc-win-64.exe_autostart" /D"C:\Program Files\mfaktc\mfaktc_0.17_autostart" /LOW "C:\Program Files\mfaktc\mfaktc_0.17_autostart\mfaktc-win-64.exe"
[/CODE]Is it my/Nvidia's fault or is there a "stream.close()" missing?
P.S.: The dog is called "Bonny". :wink:

I don't recommend the 270.61 WHQL driver for crunching. On my box It did not restore the clocks after pausing and resuming any CUDA application (when the GPU clock for performance level 1 wasn't exactly set to the stock value). The GPU ended up in performance level 2 (405 MHz/810 MHz) and a reboot was necessary. While searching for a solution for this problem I found various problem reports describing this behaviour. I did a complete uninstall of the driver and installed 266.58 WHQL.

Cool - it's not me. Yes - I've had troubles with closing down mfaktc. I've had the screen go black and driver had to restart errors.

I've found closing down mfaktc via a remote session (RDP) was less likely to cause a problem. I'm guessing it's related to gui and cuda being run at same time on the same card.


-- Craig

How are TF results checked?

On one instance of mfaktc I've had 3x exponents in a row with a factor:
(column 1 is a date-time stamp in AEST+10)

20110507-212631 M380006269 has a factor: 7137711802080292028081
20110507-212631 found 1 factor(s) for M380006269 from 2^65 to 2^74 (partially tested) [mfaktc 0.16-Win barrett79_mul32]
20110507-224219 M380006657 has a factor: 226708240715562532609
20110507-224219 found 1 factor(s) for M380006657 from 2^65 to 2^74 (partially tested) [mfaktc 0.17-Win barrett79_mul32]
20110508-015024 M380006191 has a factor: 99680981725148840593
20110508-015025 found 1 factor(s) for M380006191 from 2^65 to 2^74 (partially tested) [mfaktc 0.17-Win barrett79_mul32]

I've seen 2x factored in close proximity before, but 3 in a row has me a little suspect.

-- Craig

[QUOTE=nucleon;260792]How are TF results checked?[/quote]PrimeNet verifies that the reported factor is correct.

[quote]I've seen 2x factored in close proximity before, but 3 in a row has me a little suspect.[/QUOTE]
Chances are that happens and usually doesn't get noticed. I would not worry

[QUOTE=nucleon;260792]found 1 factor(s) for M380xxxxxx from 2^65 to 2^74

I've seen 2x factored in close proximity before, but 3 in a row has me a little suspect.[/QUOTE]Note also that you're testing a wide bitrange. 3 factors in a row would be unusual, but certainly not impossible, testing a single bit depth for each exponent (e.g. 2^65 to 2^66). Your 3 factors are 72.6, 67.6 and 66.4 bits respectively. TF from 2^65-74 on M380M range has almost exactly a [url=http://mersenne-aries.sili.net/credit.php?worktype=TF&exponent=380006269&f_exponent=&b1=&b2=&numcurves=&factor=&frombits=65&tobits=74&submitbutton=Calculate]13% chance[/url] of finding a factor somewhere in that range. So finding 3-in-a-row should be a roughly 1:455 occurrence.