[QUOTE=KaptainBlaZzed;442079]can you please tell me how to do this for windows x64.[/QUOTE]

Unfortunately I do not have a windows environment setup so I don't have build instructions, however I also misspoke - I was thinking of CUDALucas not mfaktc. The same details apply, however with CUDA 8 RC 1 there exists a bug that prevents mfaktc from working properly. We believe it will be fixed in the final CUDA 8 release but we do not know when that will be.

[QUOTE=airsquirrels;442069]Some of the older cards/CUDA versions supported multiple compute versions and architectures, but Maxwell and Pascal both seem to required specific builds.[/QUOTE]

Maybe it is a difference with windows. I am pretty certain I have run toolkit v4 stuff on my Maxwell. I have certainly used the same binaries on a 8600GTS and 750Ti

[QUOTE=KaptainBlaZzed;442079]can you please tell me how to do this for windows x64.[/QUOTE]
I have not seen him post in a little while, but user 'flashjh' aka Jerry is a master of Windows compiles for different versions.

[QUOTE=kladner;442151]I have not seen him post in a little while, but user 'flashjh' aka Jerry is a master of Windows compiles for different versions.[/QUOTE]

Until NVIDIA fix their software...

[QUOTE=Gordon;442152]Until NVIDIA fix their software...[/QUOTE]
True dat.

[QUOTE=airsquirrels;442088] We believe it will be fixed in the final CUDA 8 release but we do not know when that will be.[/QUOTE]

Latest rumor is end of September, and as we all know, EVERYTHING you read on the internet is true, eh?

[QUOTE=tServo;442682]Latest rumor is end of September, and as we all know, EVERYTHING you read on the internet is true, eh?[/QUOTE]

Cuda 8 general availability announced today, Sept 28.

Good news!
 

[CODE]mfaktc v0.21 (64bit built)
[...]
CUDA version info
binary compiled for CUDA 8.0
CUDA runtime version 8.0
CUDA driver version 8.0

CUDA device info
name GeForce GTX 1080
compute capability 6.1
[...]

Selftest statistics
number of tests 26192
successfull tests 26192

kernel | success | fail
-------------------+---------+-------
UNKNOWN kernel | 0 | 0
71bit_mul24 | 2586 | 0
75bit_mul32 | 2682 | 0
95bit_mul32 | 2867 | 0
barrett76_mul32 | 1096 | 0
barrett77_mul32 | 1114 | 0
barrett79_mul32 | 1153 | 0
barrett87_mul32 | 1066 | 0
barrett88_mul32 | 1069 | 0
barrett92_mul32 | 1084 | 0
75bit_mul32_gs | 2420 | 0
95bit_mul32_gs | 2597 | 0
barrett76_mul32_gs | 1079 | 0
barrett77_mul32_gs | 1096 | 0
barrett79_mul32_gs | 1130 | 0
barrett87_mul32_gs | 1044 | 0
barrett88_mul32_gs | 1047 | 0
barrett92_mul32_gs | 1062 | 0

selftest PASSED!
[/CODE]

Reference (aka Founders Edition) 1080:
[CODE]Starting trial factoring M66362159 from 2^73 to 2^74 (28.83 GHz-days)
k_min = 71160531149400
k_max = 142321062305090
Using GPU kernel "barrett76_mul32_gs"
Date Time | class Pct | time ETA | [B][COLOR="Red"]GHz-d/day[/COLOR][/B] Sieve Wait
Sep 29 13:31 | 0 0.1% | 2.345 37m29s | [B][COLOR="Red"]1106.37[/COLOR][/B] 82485 n.a.%
Sep 29 13:31 | 4 0.2% | 2.345 37m27s | [B][COLOR="Red"]1106.37[/COLOR][/B] 82485 n.a.%
Sep 29 13:31 | 9 0.3% | 2.340 37m19s | [B][COLOR="Red"]1108.73[/COLOR][/B] 82485 n.a.%
[/CODE]

I guess we've a new performance and performance per watt leader.

Oliver

[QUOTE=TheJudger;443782][
I guess we've a new performance and performance per watt leader.

Oliver[/QUOTE]

Also, looks like they fixed their bugs that have been there since CUDA 7.0 & 7.5, yes?

Supposedly CUDA 8 has Visual Studio 2015 support, has anyone tried compiling mfaktc under Windows yet?

[QUOTE=tServo;443789]Also, looks like they fixed their bugs that have been there since CUDA 7.0 & 7.5, yes?[/QUOTE]

Yes:

[CODE] number of tests 26192
successfull tests 26192[/CODE]

[QUOTE=TheJudger;443782][CODE]mfaktc v0.21 (64bit built)
[...]
CUDA version info
binary compiled for CUDA 8.0
CUDA runtime version 8.0
CUDA driver version 8.0

CUDA device info
name GeForce GTX 1080
compute capability 6.1
[...]

Selftest statistics
number of tests 26192
successfull tests 26192

kernel | success | fail
-------------------+---------+-------
UNKNOWN kernel | 0 | 0
71bit_mul24 | 2586 | 0
75bit_mul32 | 2682 | 0
95bit_mul32 | 2867 | 0
barrett76_mul32 | 1096 | 0
barrett77_mul32 | 1114 | 0
barrett79_mul32 | 1153 | 0
barrett87_mul32 | 1066 | 0
barrett88_mul32 | 1069 | 0
barrett92_mul32 | 1084 | 0
75bit_mul32_gs | 2420 | 0
95bit_mul32_gs | 2597 | 0
barrett76_mul32_gs | 1079 | 0
barrett77_mul32_gs | 1096 | 0
barrett79_mul32_gs | 1130 | 0
barrett87_mul32_gs | 1044 | 0
barrett88_mul32_gs | 1047 | 0
barrett92_mul32_gs | 1062 | 0

selftest PASSED!
[/CODE]

Reference (aka Founders Edition) 1080:
[CODE]Starting trial factoring M66362159 from 2^73 to 2^74 (28.83 GHz-days)
k_min = 71160531149400
k_max = 142321062305090
Using GPU kernel "barrett76_mul32_gs"
Date Time | class Pct | time ETA | [B][COLOR="Red"]GHz-d/day[/COLOR][/B] Sieve Wait
Sep 29 13:31 | 0 0.1% | 2.345 37m29s | [B][COLOR="Red"]1106.37[/COLOR][/B] 82485 n.a.%
Sep 29 13:31 | 4 0.2% | 2.345 37m27s | [B][COLOR="Red"]1106.37[/COLOR][/B] 82485 n.a.%
Sep 29 13:31 | 9 0.3% | 2.340 37m19s | [B][COLOR="Red"]1108.73[/COLOR][/B] 82485 n.a.%
[/CODE]

I guess we've a new performance and performance per watt leader.

Oliver[/QUOTE]

Just wait till we see Pascal Titan X numbers...

Some benchmarks:

CUDA 8.0, Linux, mfaktc 0.21, M66362159 from 2[SUP]73[/SUP] to 2[SUP]74[/SUP]

reference GTX 980 Ti: ~780 GHz-d/day, ~240W (~3,25GHz equivalent per watt)
reference GTX 1070: ~800 GHz-d/day, ~130W (~6,15GHz equivalent per watt)
reference GTX 1080: ~1090 GHz-d/day, ~180W (~6,05GHz equivalent per watt)
reference TITAN X (Pascal): ~1410 GHz-d/day, ~250W (~5,64GHz equivalent per watt)
[LIST][*]all GPUs are in an environment where GPU temperature is kept below the temperature target[*]GTX 1080 and TITAN X (Pascal) are limited by TDP while the other two are below their limit[*]power measurement is done with 'nvidia-smi'[*]compared to earlier post this time performance numbers are long term instead of quick benchmark.[/LIST]
Not a real surprise: Pascal is much more energy efficient than Maxwell.

[U]Your mileage my vary, take 10 cards of same spec and you measure 10 slightly different results.[/U]

Oliver

[QUOTE=airsquirrels;443795]Just wait till we see Pascal Titan X numbers...[/QUOTE]

12 minutes :razz:

[QUOTE=TheJudger;443797]12 minutes :razz:[/QUOTE]

So with that crazy high TF number vs. LL, does this mean we should be raising the TF cutoff?

[QUOTE=TheJudger;443796]reference GTX 980 Ti: ~780 GHz-d/day, ~240W (~3,25GHz equivalent per watt)
reference GTX 1070: ~800 GHz-d/day, ~130W (~6,15GHz equivalent per watt)
reference GTX 1080: ~1090 GHz-d/day, ~180W (~6,05GHz equivalent per watt)
reference TITAN X (Pascal): ~1410 GHz-d/day, ~250W (~5,64GHz equivalent per watt)[/QUOTE]Great to hear.
Now that people can run GTX 10x0 properly, I would really appreciate a bunch of new benchmark data so I can update my performance chart :smile:
[url]http://www.mersenne.ca/mfaktc.php#benchmark[/url]

The numbers quoted by Oliver above are higher than I expect on my chart, but then I don't really have any good benchmark data to work from, just a rough guess.

This is an open call for everyone with GTX 9xx or 10xx (or newer) to submit new mfaktc benchmarks, thanks!
(CUDAlucas benchmarks for the same cards are also in demand, see the top of [url]http://www.mersenne.ca/cudalucas.php[/url])

[QUOTE=TheJudger;443796]reference GTX 1070: ~800 GHz-d/day, ~130W (~6,15GHz equivalent per watt)
reference GTX 1080: ~1090 GHz-d/day, ~180W (~6,05GHz equivalent per watt)[/QUOTE]

Is the reference GTX 1060 comparable in terms of GHz per watt? Or is it less efficient?

According to the the performance figures I have (perhaps slightly off from actual but the scaling should be similar):
GTX 1080 = 5.079 GHz-days per day per watt (914GHd/d, 180W)
GTX 1070 = 4.284 GHz-days per day per watt (643GHd/d, 150W)
GTX 1060 = 3.569 GHz-days per day per watt (428GHd/d, 120W)

You can see this yourself at [url]http://www.mersenne.ca/mfaktc.php[/url] (put "GTX 1" in the filter/search box to limit to those GPUs)

I am not sure that those numbers are completely correct. My 750Ti never reaches its full TDP with mfaktc. It only reaches 70% before it is limited by operating voltage according to gpu-z. mmff only makes it reach 50% TDP.
I would imagine that other cards will have similar issues especially the Maxwells.

[QUOTE=airsquirrels;443803]So with that crazy high TF number vs. LL, does this mean we should be raising the TF cutoff?[/QUOTE]

Just in case you missed it: 12 minutes was the difference between your post "waiting for TITAN X (Pascal) numbers" and my post. :smile:

[QUOTE=henryzz;443850]I am not sure that those numbers are completely correct. My 750Ti never reaches its full TDP with mfaktc. It only reaches 70% before it is limited by operating voltage according to gpu-z. mmff only makes it reach 50% TDP.
I would imagine that other cards will have similar issues especially the Maxwells.[/QUOTE]

Exactly. But this is not limited to Maxwell cards. IIRC most cc 2.1 didn't hit their TDP while running mfaktc. As written above the reference 1070 I've used didn't reach the TDP while the 1080 did.

[QUOTE=TheJudger;443856]Just in case you missed it: 12 minutes was the difference between your post "waiting for TITAN X (Pascal) numbers" and my post. :smile:[/QUOTE]

Caught it. Glad to see we're finally factoring using a recent CUDA version

[QUOTE=airsquirrels;443858]Caught it. Glad to see we're finally factoring using a recent CUDA version[/QUOTE]

I wonder what the 1080 will do on water?

[QUOTE=Mark Rose;443865]I wonder what the 1080 will do on water?[/QUOTE]

Apparently, even on air the board can be over clocked to around 2Ghz ( and often above ) without resorting to much more than using the MSI or EVGA utilities that set the clocks and target temps. Of course, these are the high-end boards that have better cooling ( dual fans, etc. ) that are designated FTW, SC, etc. And most users report that they are not too loud.
The most telling comment I read was one user who said he felt the card jumped 2 generations rather than just one.

Lovely news, Oliver!

Now, would someone kindly compile a x64 Windows binary? :smile:

[url=https://www.dropbox.com/s/fy8o5d6jnmsgls6/cudalib.7z?dl=1]Here are the new DLLs[/url].

Hi Karl,

I've already asked Jerry if he can built Win/CUDA8 binaries.

Oliver

[QUOTE=TheJudger;444004]Hi Karl,

I've already asked Jerry if he can built Win/CUDA8 binaries.

Oliver[/QUOTE]

All updated :smile:

[QUOTE=flashjh;444025]All updated :smile:[/QUOTE]
Thanks, Jerry!

Cheers!

Here are some freshly submitted results on a GTX 1080 @ 2ish GHz:
[CODE]
got assignment: exp=137990929 bit_min=70 bit_max=72 (5.20 GHz-days)
Starting trial factoring M137990929 from 2^70 to 2^71 (1.73 GHz-days)
k_min = 4277787055080
k_max = 8555574118335
Using GPU kernel "barrett76_mul32_gs"
Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Oct 02 10:07 | 4619 100.0% | 0.137 n.a. | 1138.42 82485 n.a.%
no factor for M137990929 from 2^70 to 2^71 [mfaktc 0.21 barrett76_mul32_gs]
tf(): total time spent: 2m 12.097s

Starting trial factoring M137990929 from 2^71 to 2^72 (3.47 GHz-days)
k_min = 8555574114780
k_max = 17111148236670
Using GPU kernel "barrett76_mul32_gs"
Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Oct 02 10:11 | 4619 100.0% | 0.274 0m00s | 1138.42 82485 n.a.%
no factor for M137990929 from 2^71 to 2^72 [mfaktc 0.21 barrett76_mul32_gs]
tf(): total time spent: 4m 24.240s
[/CODE]

Judging by the GPU utilisation (~91%), this is not the limit.

That's [I]almost[/I] useful to me -- if you could tell me the actual core clock speed under load while doing mfaktc then it I could use it for my benchmark data.

Now I know there's a [url=http://www.mersenne.ca/mfaktc.php#]specialised form[/url] for this sort of data submission.
I've sent the standardised data, with comment pointing to your request, James.

My GPUSieveSize parameter was set to '128', though, which improved utilisation to 96% and resulted in ~1190 GHz-d/day value.
A quick look at other parameters didn't shed any useful insight.

Time to feed Pascal
 

Hi,

[B]Thank you, Jerry![/B]

I've uploaded the binaries [URL="http://mersenneforum.org/mfaktc/mfaktc-0.21/mfaktc-0.21.win.cuda80.zip"]here[/URL], too.

Upgrade instructions from mfaktc 0.21 (CUDA 6.5) to mfaktc 0.21 (CUDA 8.0):[LIST=1][*]stop mfaktc[*]replace executables and DLLs[*]start mfaktc again[/LIST]You can replace/restart in the middle of a run easily.

Oliver

P.S. I guess the "extra versions" (Wagstaff mode and LessClasses) will be available soon.
[B]P.P.S. How high is the demand for Wagstaff and/or LessClasses?[/B]

Found my first bug for mfaktc by getting overnight TF work.
It would seem that 128 lines in worktodo file cause some kind of overflow, and mfaktc complains about invalid format in such a case (and doesn't start).
Will report further findings later.

I've had hundreds of lines in worktodo.txt before. Interesting.

[QUOTE=Karl M Johnson;444065]Found my first bug for mfaktc by getting overnight TF work.
It would seem that 128 lines in worktodo file cause some kind of overflow, and mfaktc complains about invalid format in such a case (and doesn't start).
Will report further findings later.[/QUOTE]

I currently have 1723 lines in my worktodo and it's running sweet as a nut.

The new version puts out just over 500 days/day on my 970, previous version was about 470 days/day

[QUOTE=TheJudger;444060]P.P.S. How high is the demand for Wagstaff and/or LessClasses?[/QUOTE]I would normally request LessClasses, but my newest GPU is a 670 so I don't have any immediate need for it until a GTX 1080 magically falls out of the sky :smile:

CUDA 8.0 made little difference on my currently-running 580. No surprise, for something that old.

[QUOTE=James Heinrich;444080]I would normally request LessClasses, but my newest GPU is a 670 so I don't have any immediate need for it until a GTX 1080 magically falls out of the sky :smile:[/QUOTE]

I just compiled the 32 and 64 bit versions of lessclass, Wagstaff, and lessclass Wagstaff.

I emailed to Oliver a few minutes ago, I'm sure he'll post them soon ;)

[QUOTE=kladner;444086]CUDA 8.0 made little difference on my currently-running 580. No surprise, for something that old.[/QUOTE]

On this note, I'm sad to say that the workhorse 580s are soon obsolete based on CUDA versions -- If they're not already ;)

Current compiler warning: [CODE]nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).[/CODE]

Won't change much either way, just sad.

[QUOTE=Karl M Johnson;444065]Found my first bug for mfaktc by getting overnight TF work.
It would seem that 128 lines in worktodo file cause some kind of overflow, and mfaktc complains about invalid format in such a case (and doesn't start).
Will report further findings later.[/QUOTE]

Back in my HayDay of running mfaktc I had thousands of lines in many instances running with no problems. Have you checked for any non-text characters in the file? That might cause a problem.

[QUOTE=flashjh;444092]Back in my HayDay of running mfaktc I had thousands of lines in many instances running with no problems. Have you checked for any non-text characters in the file? That might cause a problem.[/QUOTE]

I did have a problem with line endings once, IIRC.

[QUOTE=Mark Rose;444095]I did have a problem with line endings once, IIRC.[/QUOTE]
Nailed it!
Turns out, it was not related to mfaktc, but which EOL worktodo.txt used.
I've realised this only when I've noticed a 'Macintosh' EOL being used n Notepad++ and I'm not sure how this happened.
False alarm :smile:

[QUOTE=flashjh;444090]On this note, I'm sad to say that the workhorse 580s are soon obsolete based on CUDA versions -- If they're not already ;)

Current compiler warning: [CODE]nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).[/CODE]Won't change much either way, just sad.[/QUOTE]
One point I am uncertain about: I have always run 32 bit versions of mfaktc, because they have a very slight performance edge over the 64 bit. My experiment was with the 64 bit version of CUDA 8.0. Still, any differences were within normal fluctuations in everyday running.

[QUOTE=Karl M Johnson;444096]Turns out, it was not related to mfaktc, but which EOL worktodo.txt used.[/QUOTE]Vaguely related: I discovered while writing a script to fetch new worktodo that mfaktc always rewrites all of worktodo.txt and always uses \r\n even if the file had \n line-endings (which mfaktc can read fine).

Extra versions - Wagstaff and/or LessClasses (Windows, CUDA 8.0)
 

Hi again,

[QUOTE=flashjh;444089]I just compiled the 32 and 64 bit versions of lessclass, Wagstaff, and lessclass Wagstaff.

I emailed to Oliver a few minutes ago, I'm sure he'll post them soon ;)[/QUOTE]

Thank you again!

[URL="http://mersenneforum.org/mfaktc/mfaktc-0.21/mfaktc-0.21.win.cuda80.extra-versions.zip"]Here[/URL] are the [I]extra versions[/I] ([B]Wagstaff[/B] and/or [B]LessClasses[/B]), they are an addon the to [URL="http://mersenneforum.org/mfaktc/mfaktc-0.21/mfaktc-0.21.win.cuda80.zip"]basic[/URL] version, just drop the 6 executables into the [I]basic[/I] folder.

Oliver

[QUOTE=flashjh;444090]On this note, I'm sad to say that the workhorse 580s are soon obsolete based on CUDA versions -- If they're not already ;)[/QUOTE]

"Sad" but true, in terms of performance per watt (aka energy efficiency) they are sooooooo obsolete. On the other hand we should be happy that we have more advanced hardware today.

Oliver

[QUOTE=James Heinrich;444102]Vaguely related: I discovered while writing a script to fetch new worktodo that mfaktc always rewrites all of worktodo.txt and always uses \r\n even if the file had \n line-endings (which mfaktc can read fine).[/QUOTE]

This is a result of the way \n is interpreted by the C compiler. I assume you are using Windows, for gcc/llvm certainly wouldn't use \r\n on and *nix OS.

Basically, all \r\n are translated to \n for the purposes of I/O in C, and vice versa. The mfaktc source code has no place where one may find the "\r" character sequence.

It doesn't really matter where the behaviour originates, it was just one of those gotchas I ran across. I was doing a simple assignment-count check using [i]filesize(worktodo.txt) / strlen('Factor=1234567890,64,67'."\n")[/i] and writing new assignments, and then wondering why my expected line count and actual line count didn't match.

Gentoo?
 

Will mfaktc run on Gentoo, or is this a CUDA issue?

You need CUDA, which means the Nvidia proprietary drivers. I don't know enough to know if said drivers are compatible with Gentoo, but I strongly suspect not.

[QUOTE=Dubslow;445369]You need CUDA, which means the Nvidia proprietary drivers. I don't know enough to know if said drivers are compatible with Gentoo, but I strongly suspect not.[/QUOTE]

They are. My coworker uses the binary drivers with Gentoo.

[QUOTE=Mark Rose;445371]They are. My coworker uses the binary drivers with Gentoo.[/QUOTE]

Is that from the official nvidia installation system or by cribbing the binary from some other distro's package?

[QUOTE=Dubslow;445409]Is that from the official nvidia installation system or by cribbing the binary from some other distro's package?[/QUOTE]

I'm not sure. NVidia does provide a script-based installer, so it's probably using that.

In all the pages of documents I have read, I came across something which indicated mfaktc will be revised so it can communicate with the PrimeNet server. Is this true? If so, any ideas as to when this might happen?

[QUOTE=storm5510;446080]In all the pages of documents I have read, I came across something which indicated mfaktc will be revised so it can communicate with the PrimeNet server. Is this true? If so, any ideas as to when this might happen?[/QUOTE]

Complete and utter bullshit.

Care to provide evidence to disprove this statement?

[QUOTE=storm5510;446080]In all the pages of documents I have read, I came across something which indicated mfaktc will be revised so it can communicate with the PrimeNet server. Is this true? If so, any ideas as to when this might happen?[/QUOTE]
If nothing else, MISFIT performs this function in Windows. On GPU72 there is a section on spiders chalsall wrote to fetch (and submit?) assignments under other OS's.

[QUOTE=storm5510;446080]In all the pages of documents I have read, I came across something which indicated mfaktc will be revised so it can communicate with the PrimeNet server. Is this true? If so, any ideas as to when this might happen?[/QUOTE]

I've never heard of anyone actually planning to do this.

However, in an ideal world, the mprime code that talks to PrimeNet could eventually be rewritten in Python, as well as the menu code and savefile code and all the other non-time-critical stuff. Python has a rich set of standard libraries and all of that code would become much smaller and more maintainable.

The actual number crunching code would stay in C and assembler. The gwnum code could be a module that could be called from Python, or even better, mprime could be rewritten in Cython for the best of both worlds. Cython is already widely used for scientific libraries like SciPy and pandas.

And then if the above was done, other programs like mfaktc could also be rewritten in Cython and talk directly to PrimeNet.

Certainly if mprime were being written today from scratch, that would be the logical route, rather than creating a monolithic C program. The software universe looked very different back in the mid-1990s...


PS,
If all you care about is using the [URL="http://www.mersenne.org/manual_result/"]Manual Results page[/URL] to send your results to PrimeNet, then that's utterly trivial to automate with Python or other similar languages.

[QUOTE=chalsall;446081]Complete and utter bullshit.

Care to provide evidence to disprove this statement?[/QUOTE]

Is that you Bob? Thought you were banned :surprised:

[B]This is from the "readme.txt" file in the archive, near the bottom.[/B]

[QUOTE]0.??
- automatic primenet interaction (Eric Christenson is working on this) <- specification draft exists; on hold, Eric doesn't want to continue his efforts. :(
- this will greatly increase usability of mfaktc....
[/QUOTE]In response to:

[QUOTE]Complete and utter bullshit.

Care to provide evidence to disprove this statement? [/QUOTE]Evidence provided. I asked a simple question. It is not necessary to be [B]abrasive[/B] and[B] vulgar[/B]!

[QUOTE=storm5510;446149].....Evidence provided. I asked a simple question. It is not necessary to be [B]abrasive[/B] and[B] vulgar[/B]![/QUOTE]
+1

+1.

[QUOTE=storm5510;446080]In all the pages of documents I have read, I came across something which indicated mfaktc will be revised so it can communicate with the PrimeNet server. Is this true? If so, any ideas as to when this might happen?[/QUOTE]

I have a python script to pull work from primenet and have been using the spider pl scripts to turn work in. Both run as cronjobs.

[url]https://github.com/jfamestad/gimps_getter[/url]
[url]http://www.gpu72.com/spider/[/url]

Restarting my space heater aka 580 for the winter. Is there anything to be gained from upgrading from CUDA 6.5 to CUDA 8.0? Is it even possible to upgrade this card to 8.0?

[QUOTE=garo;446622]Is there anything to be gained from upgrading from CUDA 6.5 to CUDA 8.0?[/QUOTE]No.[QUOTE=kladner;444086]CUDA 8.0 made little difference on my currently-running 580. No surprise, for something that old.[/QUOTE]

Thanks for the quick reply, James.

[QUOTE=garo;446622]Restarting my space heater aka 580 for the winter. Is there anything to be gained from upgrading from CUDA 6.5 to CUDA 8.0? Is it even possible to upgrade this card to 8.0?[/QUOTE]

I did get a 1% performance boost upgrading from 6.5 to 7.5 (in upgrading from Ubuntu 14.04 to 16.04) with my GTX 580s.

A simple question: Does mfaktc read the entire [I]worktodo[/I] file into a queue, or does it take it one line at a time?

:smile:

Pretty sure it reads line by line, skipping any invalid lines, until it finds a valid assignment.
Once it has finished the assignment it rewrites the entire worktodo, minus the assignment-line it just completed.

[SIZE="1"]Side note: disk I/O can be killer (e.g. 1-10MB/s sustained) for things like [url=http://www.mersenne.ca/tf1G.php]TF>1G[/url] where an assignment is completed every second or so and a large input buffer is maintained -- a RAM drive is essential.[/SIZE]

[QUOTE=James Heinrich;447380]Pretty sure it reads line by line, skipping any invalid lines, until it finds a valid assignment.
Once it has finished the assignment it rewrites the entire worktodo, minus the assignment-line it just completed.

[SIZE=1]Side note: disk I/O can be killer (e.g. 1-10MB/s sustained) for things like [URL="http://www.mersenne.ca/tf1G.php"]TF>1G[/URL] where an assignment is completed every second or so and a large input buffer is maintained -- a RAM drive is essential.[/SIZE][/QUOTE]

It reads it into a buffer, like I suspected. I've noticed that when it has a larger bit range, for example 2[SUP]72[/SUP] to 2[SUP]74[/SUP], it will write the intermediate stage when complete. This explains the [I]add[/I] file feature. I have been stopping it to add assignments to the [I]worktodo[/I] file.

TF>1G: I suspected there were people out there doing this but I had no idea of the magnitude of it. A very interesting page; I bookmarked it. :smile:

I think there would be a speedup for Pascal cards if the linux version were compiled with 8.0. Actually, I cannot run the current binaries unless I change the makefile and compile them for compute 6.1. But even if you can get this to run on a Pascal card in its current form, my experience suggests that there is a performance penalty for running binaries compiled for compute capability <6.0 cards on the 1080 or 1070.

We've had a (FE) GTX 1060 card for several months but never got around to running mfaktc.

:rakes:

We tried it today and it just worked, out of the box, without anything extra needed! In the past we had to install the CUDA toolkit but we didn't today.

The card is doing roughly 530 GHz-d/day and the display has no lag whatsoever. The card is at 80 C and it is nearly silent. We didn't modify the fan curve or anything.

:anonymous:

Do you have fan headroom to bring that down a bit from 80? I get nervous in the upper 70s. :max:

Are there updated linux64 binaries available for cuda 8? I don't see them in the download section or in this thread.

If not, how difficult would it be to compile them? I recently upgraded from a 970 to 1070 and am getting the 'cudaGetLastError() returned 8: invalid device function' error.

Thank you!

I took a stab at compiling the linux64 binaries myself using the cuda8 toolkit and it's running successfully. The GHz-d/day is hovering around 780 in the terminal for my GTX 1070, and nvidia-smi shows GPU utilization in the high 90's.

When compiling I added an nvcc flag for compute 6.1 capabilities. I also had to remove the existing line for compute 1.1 (Tesla?) since it wouldn't compile with that flag. Otherwise I left all settings the same as in the source file for mfaktc with cuda 6.5.

I copied the compiled mfaktc.exe and the libraries for cuda 8.0.61 on top of the existing folder structure for mfaktc with cuda 6.5. Attached is the result if anyone else is looking for or wants to test it.

Be aware I'm not an expert, so use at your own risk.

Thank you

[QUOTE=planetclown;454623]I took a stab at compiling the linux64 binaries myself using the cuda8 toolkit and it's running successfully. The GHz-d/day is hovering around 780 in the terminal for my GTX 1070, and nvidia-smi shows GPU utilization in the high 90's.

When compiling I added an nvcc flag for compute 6.1 capabilities. I also had to remove the existing line for compute 1.1 (Tesla?) since it wouldn't compile with that flag. Otherwise I left all settings the same as in the source file for mfaktc with cuda 6.5.

I copied the compiled mfaktc.exe and the libraries for cuda 8.0.61 on top of the existing folder structure for mfaktc with cuda 6.5. Attached is the result if anyone else is looking for or wants to test it.

Be aware I'm not an expert, so use at your own risk.[/QUOTE]

Hmm, I wonder whether that would run on a Mac, which I have running another GPU project on cuda 8.0.53 ...

stock 1080 Ti "Founders Edition"
 

[CODE]# ./mfaktc.exe -tf 66362159 75 76
mfaktc v0.21 (64bit built)
[...]
CUDA device info
name Graphics Device
compute capability 6.1
max threads per block 1024
max shared memory per MP 98304 byte
number of multiprocessors 28
clock rate (CUDA cores) 1582MHz
memory clock rate: 5505MHz
memory bus width: 352 bit
[...]
Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Mar 23 23:43 | 0 0.1% | 7.003 1h51m | 1481.90 82485 n.a.%
Mar 23 23:44 | 4 0.2% | 6.980 1h51m | 1486.78 82485 n.a.%
Mar 23 23:44 | 9 0.3% | 7.003 1h51m | 1481.90 82485 n.a.%
Mar 23 23:44 | 12 0.4% | 7.110 1h53m | 1459.59 82485 n.a.%
Mar 23 23:44 | 16 0.5% | 7.494 1h59m | 1384.80 82485 n.a.%
Mar 23 23:44 | 24 0.6% | 7.928 2h06m | 1309.00 82485 n.a.%
Mar 23 23:44 | 25 0.7% | 7.955 2h06m | 1304.55 82485 n.a.%
[/CODE]

First 20-25 seconds: limited by power target (250W)
After 20-25 seconds: limited by thermal target, hovers around at ~190W. Reason need more fresh air in chassis. :sad:

Oliver

Could you (and anyone else with one) please submit a benchmark for 1080Ti:
[url]http://www.mersenne.ca/mfaktc.php#benchmark[/url]

Even taking your clock speed into account I'm only expecting 1350GHd/d and you're getting 1480...

It seems like I read something here a while back that the author of [I]mfaktc[/I] is no longer working on this application. If this is true, then is anyone else going to pick it up and move forward?

[QUOTE=storm5510;456275]It seems like I read something here a while back that the author of [I]mfaktc[/I] is no longer working on this application. If this is true, then is anyone else going to pick it up and move forward?[/QUOTE]

Some minor changes in devel version but nothing serious. Seems like the current code runs fine on Pascal generation so no new code is needed.

Oliver

For what it's worth, the Linux tar is missing the necessary line to compile for the 1060/1070/1080. It's

[code]
NVCCFLAGS += --generate-code arch=compute_61,code=sm_61
[/code]

for anyone else who runs into this.

[code]
C:\Users\ethan\Desktop\mfaktc-0.21>.\mfaktc-win-64.exe -tf 66362159 75 76
mfaktc v0.21 (64bit built)
[...]
CUDA version info
binary compiled for CUDA 8.0
CUDA runtime version 8.0
CUDA driver version 8.0

CUDA device info
name GeForce GTX 1080 Ti
compute capability 6.1
max threads per block 1024
max shared memory per MP 98304 byte
number of multiprocessors 28
clock rate (CUDA cores) 1683MHz
memory clock rate: 5505MHz
memory bus width: 352 bit

[...]
Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Jun 07 16:14 | 0 0.1% | 6.088 1h37m | 1704.62 82485 n.a.%
Jun 07 16:14 | 4 0.2% | 6.014 1h36m | 1725.59 82485 n.a.%
Jun 07 16:14 | 9 0.3% | 6.001 1h35m | 1729.33 82485 n.a.%
Jun 07 16:14 | 12 0.4% | 6.006 1h35m | 1727.89 82485 n.a.%
Jun 07 16:14 | 16 0.5% | 6.003 1h35m | 1728.76 82485 n.a.%
Jun 07 16:14 | 24 0.6% | 6.005 1h35m | 1728.18 82485 n.a.%
Jun 07 16:14 | 25 0.7% | 6.004 1h35m | 1728.47 82485 n.a.%
Jun 07 16:14 | 37 0.8% | 6.006 1h35m | 1727.89 82485 n.a.%
Jun 07 16:15 | 40 0.9% | 6.008 1h35m | 1727.32 82485 n.a.%
Jun 07 16:15 | 45 1.0% | 6.008 1h35m | 1727.32 82485 n.a.%
Jun 07 16:15 | 49 1.1% | 6.015 1h35m | 1725.31 82485 n.a.%
Jun 07 16:15 | 52 1.3% | 6.017 1h35m | 1724.73 82485 n.a.%
Jun 07 16:15 | 60 1.4% | 6.010 1h34m | 1726.74 82485 n.a.%
[/code]

This is from an "ASUS ROG STRIX GeForce® GTX 1080 TI 11GB OC Edition VR Ready 5K HD Gaming HDMI DisplayPort DVI Overclocked PC Graphics Card" (P/N ROG-STRIX-GTX1080TI-O11G-GAMING).

TDP Limit is raised to 120% and Boost Frequency Offset is set to +127; the card is limited by TDP Cap but ends up running around 2050MHz indefinitely; it needs about 80% fan to keep GPU temp at 60C in 27C ambient.

Pretty impressive. :tu:

Out of curiosity, what was the power draw for the 1080 during the TF run?

[QUOTE=Rodrigo;460775]Pretty impressive. :tu:

Out of curiosity, what was the power draw for the 1080 during the TF run?[/QUOTE]

The card was reporting ~290W. That works out to 5.9GHzd/d/W (or 68kHzd/J), and over 10000(GHzd/d)^2/W. With a price of $760, this yields JVR of 1.24 and JVR2 of 2138!

I should note that this isn't a hard-core overclock - it's just lifting TDP and Boost caps and letting the chip run as it will at lowish temps. The clocking is completely dynamic according to internal temp/voltage/frequency/load tables. Since the card is being still limited by TDP caps under these conditions, lowering memory frequency and lowering voltage might produce even higher results.

Unfortunately I've got to make this card work for a living for a little while before setting it on GIMPS work :smile:

Less console output please
 

Good program. Is there a way in Mfaktc 0.20 to reduce the interim output by about a factor of ten to 200? It's generating sometimes over 30 or even 200 screen lines a minute, and accumulating about 22MB of screen output per week, redirected into a log file for later inspection. In the upper bit levels that I usually don't run, it's not too bad, but the default bit levels assigned by are quite verbose per unit time. These rates are as observed on a GTX480; a modern high end GPU would exceed them considerably.

I don't see a way in mfakto.ini (other than paring down the print format drastically to reduce file size for the same line count)

# possible values for PrintMode:
# 0: print a new line for each finished class
# 1: overwrite the current line (more compact output on screen, still large volume but lacks crlf in redirected output)
# 2: not supported, output status after every ~ 10 classes
# 3: not supported, output status after every ~ 20 classes
# 4: not supported, output status after every ~ 50 classes
# 5: not supported, output status after every ~ 100 classes
# 6: not supported, output status after every ~ 200 classes
#
# Default: PrintMode=0

PrintMode=0

Autoselection of frequency of screen output to no more often than a user-settable interval in seconds (perhaps 1, 2, 5, 10, 20, 50, 100, 200, 500) and at resumption and completion of a bit level would be great. As things stand now, the frequency is quite high and strongly dependent on the bit level being run.

Sample outputs:

Starting trial factoring M151289627 from 2^69 to 2^70 (0.79 GHz-days)
Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Jul 19 05:16 | 0 0.1% | 0.213 n.a. | 333.93 82485 n.a.%
Jul 19 05:16 | 9 0.2% | 0.213 n.a. | 333.93 82485 n.a.%
Jul 19 05:16 | 13 0.3% | 0.302 4m49s | 235.52 82485 n.a.%
Jul 19 05:16 | 24 0.4% | 0.213 n.a. | 333.93 82485 n.a.%
Jul 19 05:16 | 28 0.5% | 0.214 n.a. | 332.37 82485 n.a.%
Jul 19 05:16 | 33 0.6% | 0.213 n.a. | 333.93 82485 n.a.%
Jul 19 05:16 | 37 0.7% | 0.214 n.a. | 332.37 82485 n.a.%
Jul 19 05:16 | 40 0.8% | 0.300 4m46s | 237.09 82485 n.a.%
Jul 19 05:16 | 48 0.9% | 0.213 n.a. | 333.93 82485 n.a.%
Jul 19 05:16 | 49 1.0% | 0.213 n.a. | 333.93 82485 n.a.%
Jul 19 05:16 | 52 1.1% | 0.213 n.a. | 333.93 82485 n.a.%

(Screen output every ~0.29 seconds! Would prefer about 1/100 or 1/200 as often)


Starting trial factoring M139505099 from 2^75 to 2^76 (54.85 GHz-days)

found a valid checkpoint file!

Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Aug 05 09:03 | 780 17.0% | 14.800 3h16m | 333.56 82485 n.a.%
Aug 05 09:03 | 784 17.1% | 14.409 3h11m | 342.61 82485 n.a.%
Aug 05 09:03 | 789 17.2% | 14.261 3h08m | 346.16 82485 n.a.%
Aug 05 09:03 | 792 17.3% | 14.862 3h16m | 332.17 82485 n.a.%
Aug 05 09:04 | 796 17.4% | 14.262 3h08m | 346.14 82485 n.a.%
Aug 05 09:04 | 801 17.5% | 14.261 3h08m | 346.16 82485 n.a.%
Aug 05 09:04 | 804 17.6% | 14.261 3h08m | 346.16 82485 n.a.%
Aug 05 09:04 | 817 17.7% | 14.261 3h07m | 346.16 82485 n.a.%
Aug 05 09:05 | 820 17.8% | 14.263 3h07m | 346.12 82485 n.a.%

(Screen output every ~11 seconds; would prefer about 1/10 as often)

For short-runtime assignments you can use the less-classes version of mfatktc
[url]http://download.mersenne.ca/mfaktc/mfaktc-0.21/mfaktc-0.21.win.cuda65.extra-versions.zip[/url]

[QUOTE=kriesel;464901]...Autoselection of frequency of screen output to no more often than a user-settable interval in seconds (perhaps 1, 2, 5, 10, 20, 50, 100, 200, 500) and at resumption and completion of a bit level would be great. As things stand now, the frequency is quite high and strongly dependent on the bit level being run.

(Screen output every ~0.29 seconds! Would prefer about 1/100 or 1/200 as often)

(Screen output every ~11 seconds; would prefer about 1/10 as often)[/QUOTE]

The suggestion above of interval seconds could be in percent. No more than 1%. Actually, the best thing to do is nothing. [U]Leave it alone[/U]! :rant:

less classes for CUDA6.5?
 

[QUOTE=storm5510;464904]The suggestion above of interval seconds could be in percent. No more than 1%. Actually, the best thing to do is nothing. [U]Leave it alone[/U]! :rant:[/QUOTE]

If it were up to me, the behavior people are used to would not only still be available, it would be the default so as not to annoy or inconvenience anyone happy with & preferring the status quo.

Mfaktc relative performance, on GTX480 on Windows 7 Pro, informal benchmark follows

V0.20 CUDA6.5 64-bit & V355.60 driver package
Starting trial factoring M139505237 from 2^75 to 2^76 (54.85 GHz-days)
Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Aug 07 06:29 | 0 0.1% | 14.252 3h47m | 346.38 82485 n.a.%
Aug 07 06:29 | 3 0.2% | 14.277 3h47m | 345.78 82485 n.a.%
Aug 07 06:30 | 4 0.3% | 14.254 3h47m | 346.33 82485 n.a.%
Aug 07 06:30 | 7 0.4% | 14.329 3h48m | 344.52 82485 n.a.%
Aug 07 06:30 | 12 0.5% | 14.246 3h46m | 346.53 82485 n.a.%
Aug 07 06:30 | 15 0.6% | 14.270 3h46m | 345.95 82485 n.a.%
Aug 07 06:31 | 19 0.7% | 14.262 3h46m | 346.14 82485 n.a.%
Aug 07 06:31 | 24 0.8% | 14.271 3h46m | 345.92 82485 n.a.%
Aug 07 06:31 | 28 0.9% | 14.247 3h45m | 346.50 82485 n.a.%
Aug 07 06:31 | 39 1.0% | 14.263 3h45m | 346.12 82485 n.a.%
...
Aug 07 09:48 | 3963 85.8% | 14.282 32m22s | 345.65 82485 n.a.%

V0.20 Less Classes CUDA 4.2 & V355.60 driver package
Starting trial factoring M139505237 from 2^75 to 2^76 (54.85 GHz-days)
Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Aug 07 10:02 | 0 1.0% | 145.12 3h49m | 340.18 82485 n.a.%
Aug 07 10:05 | 3 2.1% | 144.54 3h46m | 341.55 82485 n.a.%
Aug 07 10:07 | 4 3.1% | 144.51 3h43m | 341.62 82485 n.a.%
Aug 07 10:09 | 7 4.2% | 144.80 3h42m | 340.92 82485 n.a.%

V0.21 Less Classes CUDA 8.0 & V378.92 driver package (won't run with V355.60 driver package)
Starting trial factoring M139505237 from 2^75 to 2^76 (54.85 GHz-days)
Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Aug 07 10:28 | 0 1.0% | 145.01 3h49m | 340.43 82485 n.a.%
Aug 07 10:31 | 3 2.1% | 145.42 3h47m | 339.47 82485 n.a.%
Aug 07 10:33 | 4 3.1% | 145.41 3h45m | 339.49 82485 n.a.%
Aug 07 10:36 | 7 4.2% | 145.07 3h42m | 340.29 82485 n.a.%
Aug 07 10:38 | 12 5.2% | 145.60 3h40m | 339.05 82485 n.a.%
Aug 07 10:41 | 15 6.3% | 153.94 3h50m | 320.68 82485 n.a.%
Aug 07 10:43 | 19 7.3% | 153.97 3h48m | 320.62 82485 n.a.%

simple summary:
V0.20 CUDA 6.5 346.38 GhzD/d ----fastest 100%
V0.21 Less Classes CUDA 4.2 340.18 ---98.2%
V0.21 Less Classes CUDA 8.0 340.43 ---98.3%
Running the less classes versions could cost ~0.9 week per year of throughput.

Note, v0.20 checkpoint file was ignored by either flavor of less-classes, 3 hours throughput was lost when switching version, by the Less-Classes versions of mfaktc starting the bit depth over at each version change. I was able to get it back by reverting to V0.20 CUDA6.5 64-bit version. Which I was doing anyway for that 1.8% speed advantage.

Any chance of compiling a less-classes version for CUDA6.5?

Temporary solution - filtering out output with scripts
 

Guessing around so...
I'm cluless in Powershell, but in bash filters with the [I]cut[/I] and[I] fields[/I] (because these separate based on separators, not character number) you could probably ignore those line with ...| class [B]1.5%[/B] | ... where based on class or the percentage you could filter out those with for example ??.3 or ??.4 or ??.5 percentage or classes containing certain numbers. Implying you are redirecting the console output to file, and not the program writing the output to a file.
Or a drastic solution would be removing all the lines containing "|". <- I don't have access to Cuda harware, so cannot confirm if it influences the results.

Or inserting a for loop somewhere into the sourcecode. E.g. looks like in output.c line #360 or #389 or even #323 is responsible (maybe) for the logging/console output? (Don't trust me, i don't know a thing about these.)

A probably not preferable method for you would be to not redirect the console output as the program itself would/will write results to the results.txt. Maybe make a separate "buffer" output with the console output which deletes/trims itself after x time/size.

[QUOTE=thyw;465055]Guessing around so...
I'm cluless in Powershell, but in bash filters with the [I]cut[/I] and[I] fields[/I] (because these separate based on separators, not character number) you could probably ignore those line with ...| class [B]1.5%[/B] | ... where based on class or the percentage you could filter out those with for example ??.3 or ??.4 or ??.5 percentage or classes containing certain numbers. Implying you are redirecting the console output to file, and not the program writing the output to a file.
Or a drastic solution would be removing all the lines containing "|". <- I don't have access to Cuda harware, so cannot confirm if it influences the results.

Or inserting a for loop somewhere into the sourcecode. E.g. looks like in output.c line #360 or #389 or even #323 is responsible (maybe) for the logging/console output? (Don't trust me, i don't know a thing about these.)

A probably not preferable method for you would be to not redirect the console output as the program itself would/will write results to the results.txt. Maybe make a separate "buffer" output with the console output which deletes/trims itself after x time/size.[/QUOTE]

In Windows: Command Prompt, Properties, Layout, Screen Buffer large height and width values accomplish a lot of what you suggest last. But it doesn't survive a system halt, of course, or preserve the more important content for reference weeks or months later when considering questions not thought of before the screen data rolled off the deep history buffer, even at 4000 lines deep buffer size.

has anyone checked for systems missing factors lately?
 

Saw [url]http://mersenneforum.org/showthread.php?t=21705[/url] and wondered if such a check has been made this year.

[QUOTE=thyw;465055]...I'm cluless in Powershell...[/QUOTE]

All you have to do in [I]PowerShell[/I] is enter [B]cmd[/B] at the first prompt,and then it behaves like a regular command prompt.

powershell tee caution
 

[QUOTE=storm5510;465770]All you have to do in [I]PowerShell[/I] is enter [B]cmd[/B] at the first prompt,and then it behaves like a regular command prompt.[/QUOTE]

Re powershell and tee use, I saw a warning somewhere that tee creates a destination file, even if a file by that name exists. Which would blow away the previously accumulated log every time the app halted from the nvidia driver timeout or other reason and the batch wrapper restarted the application with tee to redirect a copy of screen output to the file.. Unless the alert user incorporated the batch loop count into the tee destination file name in the batch file. That first time could be a killer, of months of logging. The -append modifier for tee is not accepted at the command line in my test moments ago on Win7.

[QUOTE=kriesel;465779]That first time could be a killer, of months of logging. The -append modifier for tee is not accepted at the command line in my test moments ago on Win7.[/QUOTE]

I don't use Winblows, but under Linux the append option for the tee command is either "-a" or "--append".

[CODE][chalsall@burrow ~]$ ping 127.0.0.1 | tee -a ping.txt[/CODE]

...sent the output of the ping to the console, and also to the file ping.txt. The file was not overwritten upon a cntl-C and then a relaunch. Rather, it was appended, as instructed.

[QUOTE=chalsall;465784]I don't use Winblows, but under Linux the append option for the tee command is either "-a" or "--append".

[CODE][chalsall@burrow ~]$ ping 127.0.0.1 | tee -a ping.txt[/CODE]...sent the output of the ping to the console, and also to the file ping.txt. The file was not overwritten upon a cntl-C and then a relaunch. Rather, it was appended, as instructed.[/QUOTE]

Win7 Pro PS (same comments except no -a or -append work)
PS C:\Users\Ken\documents> dir | tee-object -filepath tee-test.txt -append
Tee-Object : A parameter cannot be found that matches parameter name 'append'.
At line:1 char:48
+ dir | tee-object -filepath tee-test.txt -append <<<<
+ CategoryInfo : InvalidArgument: (:) [Tee-Object], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.PowerShell.Commands.TeeObjectCommand

PS C:\Users\Ken\documents> dir | tee-object -filepath tee-test.txt -a
Tee-Object : A parameter cannot be found that matches parameter name 'a'.
At line:1 char:43
+ dir | tee-object -filepath tee-test.txt -a <<<<
+ CategoryInfo : InvalidArgument: (:) [Tee-Object], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.PowerShell.Commands.TeeObjectCommand

PS C:\Users\Ken\documents>

The plot thickens; the -append option is not present in command line tee help on Win7, but is in Win10.

I think I'm well off the thread topic now so won't go into it any further.

[QUOTE=kriesel]...Which would blow away the previously accumulated log every time the app halted from the nvidia driver timeout or other reason...

[/QUOTE]This may, or may not, be of any use. Below is a batch file which [B]kladner[/B] posted in response to a driver reset issue I have with CUDALucas. It will also work CUDAPm1 and mfaktc.

I added the line in bold because, if the program does not find an assignment in its [I]worktodo.txt [/I]file, it continues to loop. Not so long ago, I got up one morning to find a loop value over 700,000.

Change the program name in the third line and put it the proper folder.

[CODE]@echo off
set count=0
set program=cudalucas
:loop
TITLE %program% current reset count = %count%
set /a count+=1
echo %count% >> log.txt
echo %count%
%program%.exe [COLOR="Red"]>> logname.txt
[/COLOR][B]if %count%==50 goto end
[/B]goto loop
:end[/CODE]

If one adds the part in [COLOR="Red"]red[/COLOR], an output file will be [U]appended[/U], not replaced. Naturally, the name can be whatever you need.

[QUOTE=storm5510;465819]This may, or may not, be of any use. Below is a batch file which [B]kladner[/B] posted in response to a driver reset issue I have with CUDALucas. It will also work CUDAPm1 and mfaktc.

I added the line in bold because, if the program does not find an assignment in its [I]worktodo.txt [/I]file, it continues to loop. Not so long ago, I got up one morning to find a loop value over 700,000.

Change the program name in the third line and put it the proper folder.

[CODE]@echo off
set count=0
set program=cudalucas
:loop
TITLE %program% current reset count = %count%
set /a count+=1
echo %count% >> log.txt
echo %count%
%program%.exe [COLOR=Red]>> logname.txt
[/COLOR][B]if %count%==50 goto end
[/B]goto loop
:end[/CODE]If one adds the part in [COLOR=Red]red[/COLOR], an output file will be [U]appended[/U], not replaced. Naturally, the name can be whatever you need.[/QUOTE]

Thanks, yes, I use something similar to that. Tee had been suggested to me as a means of having both screen output and logging.

[QUOTE=kriesel;465855]Thanks, yes, I use something similar to that. Tee had been suggested to me as a means of having both screen output and logging.[/QUOTE]

I did some web searching and found something I thought might perform screen output and logging. It was a Windows 7 command. I could not get it to perform properly on Windows 10, except for miscellaneous prompt commands like 'dir.' It did not work in my batch file or on the command line. Below is an example.

[CODE]mfaktc >> mfa.txt & type mfa.txt[/CODE]