[QUOTE=kriesel;547594]It's been a good run. So now it's up to the engineers to create faster hardware again and more of it.

I've hit a bad spot in a 9M fft LL DC run. This had repeated for hours, so I reran it with -use STATS. I don't see anything in the stats indicating trouble, but there it is in Jacobi=1 instead of -1. Bits/word looks ok to me at <17.
[/QUOTE]

Maybe the savefile is bad (i.e. has a wrong Jacobi somehow) which gets preserved? did you try exiting in the middle, thus forcing an earlier Jacobi check, to see if that also returns fails?

If you have any earlier savefile make a copy before it's gone.

[QUOTE=preda;547595]Maybe the savefile is bad (i.e. has a wrong Jacobi somehow) which gets preserved? did you try exiting in the middle, thus forcing an earlier Jacobi check, to see if that also returns fails?

If you have any earlier savefile make a copy before it's gone.[/QUOTE]Gpuowl seems to be doing a good job of preserving the last Jacobi-ok save files for that exponent. They're now nearly a day old and have survived dozens of cycles of bad-Jacobi results.
The log file indicates correct Jacobi for the 98500000 iteration save. That's what it starts from, over and over, whether I allow it to go past 99M (the 500k Jacobi check interval) or interrupt it.
The 98600000 to 99100000 iteration res64s are reproducible from one cycle to the next, including runs with different fft choices.
Will try to reproduce from the -old file.

There's something else going on also. Sometimes a gpuowl process will hang. I haven't kept notes, but my recollection is that occurs only on a subset of the gpus. This has bad effects on other processes that access gpus on the same system.
Other gpuowl processes after Ctrl-C to terminate say Bye, but do not exit cleanly to the command prompt. The AMD Radeon Software hangs after a stuck gpu is selected. GPU-Z if it's running also hangs regardless of which Radeon VII is being displayed. Even Task Manager hangs rather than exiting. This is in Windows 10 1909. Once that situation develops, it seems anything that accesses any Radeon VII gpu hangs rather than exiting. Once I left the system be for hours after it developed. Gpu applications recorded log entries of about an hour longer iterating time than normal between updates, then returned to normal rates (~2.5 minute update interval). Occasionally there is a Windows stop 116, which some search results say is a video driver timeout related crash.

I have a subjective impression that the system is less stable when using remote desktop, which I use a LOT.

I'm contemplating moving to Windows 10 2004 or driver 20.5.1 in response. I'm currently running the recommended 20.4.2. [URL]https://www.amd.com/en/support/graphics/amd-radeon-2nd-generation-vega/amd-radeon-2nd-generation-vega/amd-radeon-vii[/URL]
Longer term plan is to install Ubuntu on a different HD on this hardware for a head to head comparison.

Ken:

Having read this thread from start to finish recently, it is very apparent that your dogged dependence on Windows is causing you a lot of trouble and work.

This thread feels dominated by these issues which makes it incredibly difficult to find useful information for the 99% of us that use Linux.

We think that you should create a separate thread for Windows+gpuowl problems.

To be blunt, your refusal to learn something new (Linux) is irrational. Linux costs no money to deploy. Linux is simpler to manage. Linux drivers for AMD cards are dramatically better. Remote administration via the command line is ridiculously simple. The developer of gpuowl chose to use the Linux toolchain and environment for a very good reason!

You have countless extremely-verbose posts complaining about blizzard-like compile-time errors, obscure compiler incompatibilities, driver failures, remote viewer problems, GPU-Z not displaying right, hung processes and all sorts of bizarre things.

In fact, we think your approach is rude and it reeks of entitlement.

The developer has a finite amount of time to work on this project, from which he earns no money. This thread is the primary communication medium for his project. You expect him to read through your posts and possibly suggest ideas to help, knowing that his time is extremely limited and that your usage is highly unconventional. Rather than changing your workflow to accommodate him, you expect him to change his workflow to accommodate you.

You are obviously a smart man and certainly much smarter than we are. If we can run Linux successfully it will be trivial for you to figure out.

In the end, you will be more productive. And a lot happier!

Please note that we are not attacking you as a person. We are questioning your behavior. We can only hope that if we step out of line in any area of our life that you all would be kind enough to point that out to us. What makes us strong in the end is working together for the common good.

:mike:

[QUOTE=kriesel;547613]Once I left the system be for hours after it developed. Gpu applications recorded log entries of about an hour longer iterating time than normal between updates, then returned to normal rates (~2.5 minute update interval).[/QUOTE]
A restart from the -old.ll file got it through. That file was the save before the hour-long stall.
[CODE]2020-06-09 11:15:48 asr2/radeonvii2 159805579 OK 97500000 (jacobi == -1)
2020-06-09 11:18:10 asr2/radeonvii2 159805579 LL 97800000 61.20%; 1424 us/it; ETA 1d 00:31; fe20ad63fcfd3b9d
2020-06-09 11:20:32 asr2/radeonvii2 159805579 LL 97900000 61.26%; 1422 us/it; ETA 1d 00:27; cc49d2676782a244
2020-06-09 11:22:54 asr2/radeonvii2 159805579 LL 98000000 61.32%; 1422 us/it; ETA 1d 00:25; b9fd54ac7a269b6b
2020-06-09 11:25:17 asr2/radeonvii2 159805579 LL 98100000 61.39%; 1421 us/it; ETA 1d 00:21; b02b5beb8b4333cb
2020-06-09 12:27:57 asr2/radeonvii2 159805579 LL 98200000 61.45%; [COLOR=Red][B]37603[/B][/COLOR] us/it; ETA 26d 19:29; 9717c57f52232474
2020-06-09 12:27:57 asr2/radeonvii2 159805579 OK 98000000 (jacobi == -1)
2020-06-09 12:30:20 asr2/radeonvii2 159805579 LL 98300000 61.51%; 1428 us/it; ETA 1d 00:23; 9443427265a9205d
2020-06-09 12:32:42 asr2/radeonvii2 159805579 LL 98400000 61.57%; 1423 us/it; ETA 1d 00:16; f9d0aed9378ab348
2020-06-09 12:35:04 asr2/radeonvii2 159805579 LL 98500000 61.64%; 1422 us/it; ETA 1d 00:13; 70acc69859d13f28
2020-06-09 12:37:26 asr2/radeonvii2 159805579 LL 98600000 61.70%; 1422 us/it; ETA 1d 00:10; 614b0458ec0a61c5
2020-06-09 12:39:48 asr2/radeonvii2 159805579 LL 98700000 61.76%; 1422 us/it; ETA 1d 00:08; 465b5dcca306e59f
2020-06-09 12:39:48 asr2/radeonvii2 159805579 OK 98500000 (jacobi == -1)
2020-06-09 12:42:11 asr2/radeonvii2 159805579 LL 98800000 61.83%; 1423 us/it; ETA 1d 00:07; 5b900a5be77a3a4e
2020-06-09 12:44:33 asr2/radeonvii2 159805579 LL 98900000 61.89%; 1422 us/it; ETA 1d 00:03; a6a1a86307e43912
2020-06-09 12:46:55 asr2/radeonvii2 159805579 LL 99000000 61.95%; 1422 us/it; ETA 1d 00:01; 82e1ab78258c33aa
2020-06-09 12:49:17 asr2/radeonvii2 159805579 LL 99100000 62.01%; 1421 us/it; ETA 0d 23:58; 0021e9dd957648d6
2020-06-09 12:51:39 asr2/radeonvii2 159805579 LL 99200000 62.08%; 1422 us/it; ETA 0d 23:56; e8b31d3feae8b5d3
2020-06-09 12:51:39 asr2/radeonvii2 159805579 EE 99000000 (jacobi == 1)
...
restart from -old.ll
2020-06-10 09:22:57 config: -user kriesel -cpu asr2/radeonvii2 -d 2 -use NO_ASM -maxAlloc 15000
2020-06-10 09:22:57 device 2, unique id ''
2020-06-10 09:22:57 asr2/radeonvii2 159805579 FFT: 9M 1K:9:512 (16.93 bpw)
2020-06-10 09:22:57 asr2/radeonvii2 Expected maximum carry32: 2C430000
2020-06-10 10:13:47 config: -user kriesel -cpu asr2/radeonvii2 -d 2 -use NO_ASM -maxAlloc 15000
2020-06-10 10:13:47 device 2, unique id ''
2020-06-10 10:13:47 asr2/radeonvii2 159805579 FFT: 9M 1K:9:512 (16.93 bpw)
2020-06-10 10:13:47 asr2/radeonvii2 Expected maximum carry32: 2C430000
2020-06-10 10:13:50 asr2/radeonvii2 OpenCL args "-DEXP=159805579u -DWIDTH=1024u -DSMALL_HEIGHT=512u -DMIDDLE=9u -DWEIGHT_STEP=0x8.60730821aeaf8p-3 -DIWEIGHT_STEP=0xf.47c6f52dba228p-4 -DWEIGHT_BIGSTEP=0x9.837f0518db8a8p-3 -DIWEIGHT_BIGSTEP=0xd.744fccad69d68p-4 -DPM1=0 -DAMDGPU=1 -DNO_ASM=1 -cl-fast-relaxed-math -cl-std=CL2.0 "
2020-06-10 10:14:00 asr2/radeonvii2 OpenCL compilation in 9.91 s
2020-06-10 10:14:01 asr2/radeonvii2 159805579 LL 98000000 loaded: b9fd54ac7a269b6b
2020-06-10 10:16:25 asr2/radeonvii2 159805579 LL 98100000 61.39%; 1432 us/it; ETA 1d 00:33; b02b5beb8b4333cb
2020-06-10 10:18:48 asr2/radeonvii2 159805579 LL 98200000 61.45%; 1430 us/it; ETA 1d 00:28; 4445edc0fe724ead
2020-06-10 10:21:10 asr2/radeonvii2 159805579 LL 98300000 61.51%; 1428 us/it; ETA 1d 00:24; bee498ff8b570757
2020-06-10 10:23:33 asr2/radeonvii2 159805579 LL 98400000 61.57%; 1428 us/it; ETA 1d 00:21; 4c059943f2b79342
2020-06-10 10:25:56 asr2/radeonvii2 159805579 LL 98500000 61.64%; 1427 us/it; ETA 1d 00:18; d25596f6693a56b8
2020-06-10 10:28:19 asr2/radeonvii2 159805579 LL 98600000 61.70%; 1427 us/it; ETA 1d 00:15; 050b480356e38d20
2020-06-10 10:30:41 asr2/radeonvii2 159805579 LL 98700000 61.76%; 1427 us/it; ETA 1d 00:13; c14411b25adef25a
2020-06-10 10:30:41 asr2/radeonvii2 159805579 OK 98500000 (jacobi == -1)
2020-06-10 10:33:04 asr2/radeonvii2 159805579 LL 98800000 61.83%; 1429 us/it; ETA 1d 00:13; 143c9b9af02178b7
2020-06-10 10:35:27 asr2/radeonvii2 159805579 LL 98900000 61.89%; 1427 us/it; ETA 1d 00:08; 42b5d402613d85a6
2020-06-10 10:37:50 asr2/radeonvii2 159805579 LL 99000000 61.95%; 1427 us/it; ETA 1d 00:06; e94b9826e8127fcb
2020-06-10 10:40:12 asr2/radeonvii2 159805579 LL 99100000 62.01%; 1427 us/it; ETA 1d 00:03; 5959abbdfdeb1ce5
2020-06-10 10:42:35 asr2/radeonvii2 159805579 LL 99200000 62.08%; 1427 us/it; ETA 1d 00:02; cdb14c3fdfc6efb3
2020-06-10 10:42:35 asr2/radeonvii2 159805579 OK 99000000 (jacobi == -1)
2020-06-10 10:44:58 asr2/radeonvii2 159805579 LL 99300000 62.14%; 1430 us/it; ETA 1d 00:02; c4b27f268b46fbb9
2020-06-10 10:47:21 asr2/radeonvii2 159805579 LL 99400000 62.20%; 1428 us/it; ETA 0d 23:57; 3c64f72339788f86
2020-06-10 10:49:43 asr2/radeonvii2 159805579 LL 99500000 62.26%; 1428 us/it; ETA 0d 23:55; ba60a838de80ef50
2020-06-10 10:52:06 asr2/radeonvii2 159805579 LL 99600000 62.33%; 1427 us/it; ETA 0d 23:52; b867fe97fc92271e
2020-06-10 10:54:29 asr2/radeonvii2 159805579 LL 99700000 62.39%; 1428 us/it; ETA 0d 23:50; 5c82c2dec2aa9484
2020-06-10 10:54:29 asr2/radeonvii2 159805579 OK 99500000 (jacobi == -1)
...[/CODE]

[QUOTE=Xyzzy;547627]Ken:

Having read this thread from start to finish recently, it is very apparent that your dogged dependence on Windows is causing you a lot of trouble and work.

This thread feels dominated by these issues which makes it incredibly difficult to find useful information for the 99% of us that use Linux.

We think that you should create a separate thread for Windows+gpuowl problems.

To be blunt, your refusal to learn something new (Linux) is irrational.

Linux costs no money to deploy. Linux is simpler to manage. Linux drivers for AMD cards are dramatically better. Remote administration via the command line is ridiculously simple. The developer of gpuowl chose to use the Linux toolchain and environment for a very good reason!

You have countless extremely-verbose posts complaining about blizzard-like compile-time errors, obscure compiler incompatibilities, driver failures, remote viewer problems, GPU-Z not displaying right, hung processes and all sorts of bizarre things.

In fact, we think your approach is rude and it reeks of entitlement.

The developer has a finite amount of time to work on this project, from which he earns no money. This thread is the primary communication medium for his project. You expect him to read through your posts and possibly suggest ideas to help, knowing that his time is extremely limited and that your usage is highly unconventional. Rather than changing your workflow to accommodate him, you expect him to change his workflow to accommodate you.

You are obviously a smart man and certainly much smarter than we are. If we can run Linux successfully it will be trivial for you to figure out.

In the end, you will be more productive. And a lot happier!

Please note that we are not attacking you as a person. We are questioning your behavior. We can only hope that if we step out of line in any area of our life that you all would be kind enough to point that out to us. What makes us strong in the end is working together for the common good.

:mike:[/QUOTE]Your post quoted above occurs to me as intemperate and unjustified, containing unsupported assumptions and conclusions. A PM may have been more appropriate. But hey, you launched and run the forum and certainly are entitled to an opinion.

I spend several hours daily working to forward the project.
My tests, purchases, posts and blog are intended to assist, not annoy. Questions I answer free the excellent programmers to focus on code. Problem reports by various people help the program improve. Mihai with the help of others has expanded it to support NVIDIA as well as AMD, on Windows as well as Linux (and MacOS too I think has been run). Kracker and I post Windows builds periodically as a convenience to others. When I do, I post the build log as a separate attachment so they can see how it was created. If it fails to build, again, the build log is an attachment, so that if Mihai chooses to try to fix the problem, the full information is there to refer to, but it doesn't clutter the thread with lengthy inline text.

I'm skeptical of the 99% linux usage of gpuowl. Could you point me to poll results?
Linux is clearly popular with some people, and operates a lot of important systems worldwide, but some users don't have the option of switching to it, or switching fully, for various reasons, such as a business owns the hardware and they haven't administrative access or permission to alter the system, or the significant other would not accept it on a home system that's shared. I've taken many runs at learning Linux beginning with Slackware in 1996 and Red Hat in 1999, Debian multiple versions, Ubuntu 18 and 19, WSL, but it's always occurred to me as analogous to being dropped into a foreign country blindfolded with a mission but no map, dictionary, translator, or knowledge of where to find the tools. Any attempt to do anything nontrivial degenerates into lengthy recursive web search for information of what to do, with what, to what, how, etc. It is for me at least an order of magnitude slower to do almost anything in Linux, that I can do easily in Windows. No doubt for some it's the reverse, Linux is familiar and Windows is not. I'm at an age where what I call the "teflon neuron" effect holds; new learning occurs slowly, and evaporates quickly. (Hence writing so much down, and a huge blog.) The trivial cost of a Windows license (~$2/license key online) is essentially free in comparison. Nevertheless: [QUOTE=kriesel;547613]
Longer term plan is to install Ubuntu on a different HD on this hardware for a head to head comparison.[/QUOTE]
Ernst, an accomplished programmer and Linux user, is having trouble getting gpuowl to run on his NUC. Linux is not a panacea; no OS is.
George Woltman develops for and releases mprime/prime95 on many platforms, including Windows, for good reason. That's where many users and potential users are. He's also stated that gpuowl on Radeon VII has such good performance that it is no longer worthwhile to buy and feed cpus with electricity to do primality tests. I don't think it reasonable to expect all Windows GIMPS participants to switch to Linux, or all gpu owners who'd like to run gpuowl. Per Madpoo a while back, all GIMPS Mersenne prime discoveries to date have been made on Windows. There are a lot of gaming pcs out there with good gpus and a lot of them have Windows installed. Gpuowl is too good to leave as a niche program (one OS, one gpu vendor).
Windows interest in gpuowl was immediate and Mihai's early response was supportive: [url]https://www.mersenneforum.org/showpost.php?p=457059&postcount=4[/url]


Perhaps the gpuowl program has become successful and important enough to justify its own subforum, with perhaps a managed modest sized number of threads, something like:
[LIST][*]Code development (informal discussion thread)[*]Announcements (Mihai or perhaps George post here, such as for a new version or significant feature addition, locked thread suggested)[*]Windows-specific (builds get posted here; OS-specific bug reports; open for peer support solving problems) or maybe that's two threads[*]Linux-specific (maybe builds get posted here; OS-specific bug reports if any; open for peer support solving problems) or maybe that's two threads. Rarely, there are requests on the forum for linux builds to download.[*]Bug reports (that seem generic, not OS-specific; open for peer support solving problems)[*]Feature requests[*]More?[/LIST]Since gpuowl is still primarily Mihai's baby, he probably should have a say in its subforum's design if it goes that way. What he would find useful and efficient is a consideration. The preceding should not be mistaken for volunteering to run such a subforum, nor expecting Mihai to.

[QUOTE=kriesel;547642]Your post quoted above occurs to me as intemperate and unjustified, containing unsupported assumptions and conclusions. A PM may have been more appropriate. But hey, you launched and run the forum and certainly are entitled to an opinion.
.[/QUOTE]

Don't worry, Linux only had a market share of 1.71% in March 2020, while Windows had a 77.1% share. Your gpuowl builds for Windows are very helpful for me, at least I haven't had a kernel panic under Windows 10 Pro till now.

[QUOTE=preda;547515]Yes, can you please install GMP 6.1 or 6.2? It seems gcd() was added to the c++ wrapper after 6.0 (a hypothesis).[/QUOTE]GMP 6.1.2 works.

[QUOTE=moebius;547645]Don't worry, Linux only had a market share of 1.71% in March 2020, while Windows had a 77.1% share. Your gpuowl builds for Windows are very helpful for me, at least I haven't had a kernel panic under Windows 10 Pro till now.[/QUOTE]

The relative 'market shares' among gpuowl users (both current and want-to-be) is what matters.

Perhaps we need separate "gpuowl linux build issues" and "gpuowl windows build issues" threads specifically for build & run issues on those 2 OS flavors? This current thread could remain for general program development. It seems most of the recent thread content has been dominated by one specific build issue after another.

[QUOTE=preda;547310]Anyway, by default P-1 will assume it runs in single-process and attempt to allocate "all it can" for itself, but no more than 16GB. When running 2-process you're supposed to use the -maxAlloc to indicate how much memory *you* allocate to each process. (e.g.: -maxAlloc 7500 for about 7.5G limit).

BTW, the processes were not idling, they were just running extremely slowly because the buffers were on host memory instead of GPU (because that's a wise ROCm choice, oh yes).[/QUOTE]Our card has 8GB. It "hung" last night. We will now use [C]maxAlloc=4096[/C] or something like that. We think that the default memory allocation is a bit too aggressive.

"HUNG" SPEED[CODE]2020-06-11 03:09:35 gfx1012-0 108928049 P1 1442134 100.00%; 4394 us/it; ETA 0d 00:00; a570b7758edb17d9
2020-06-11 03:09:35 gfx1012-0 108928049 P2 using blocks [33 - 999] to cover 1476003 primes
2020-06-11 03:09:35 gfx1012-0 108928049 P2 using 146 buffers of 48.0 MB each
2020-06-11 03:10:10 gfx1012-0 108928049 P1 GCD: no factor
2020-06-11 03:58:02 gfx1012-0 108928049 P2 146/2880: 75657 primes; setup 33.47 s, 37.973 ms/prime
2020-06-11 04:46:00 gfx1012-0 108928049 P2 292/2880: 74852 primes; setup 33.56 s, 37.993 ms/prime
2020-06-11 05:34:02 gfx1012-0 108928049 P2 438/2880: 74939 primes; setup 33.41 s, 38.008 ms/prime
2020-06-11 06:22:01 gfx1012-0 108928049 P2 584/2880: 74616 primes; setup 33.58 s, 38.134 ms/prime
2020-06-11 07:11:03 gfx1012-0 108928049 P2 730/2880: 74939 primes; setup 33.73 s, 38.810 ms/prime
2020-06-11 07:59:17 gfx1012-0 108928049 P2 876/2880: 74852 primes; setup 33.55 s, 38.210 ms/prime
2020-06-11 08:47:13 gfx1012-0 108928049 P2 1022/2880: 74774 primes; setup 33.84 s, 38.012 ms/prime
2020-06-11 09:35:15 gfx1012-0 108928049 P2 1168/2880: 74947 primes; setup 33.49 s, 38.011 ms/prime
2020-06-11 10:23:37 gfx1012-0 108928049 P2 1314/2880: 74700 primes; setup 33.41 s, 38.398 ms/prime
2020-06-11 11:11:58 gfx1012-0 108928049 P2 1460/2880: 74931 primes; setup 33.49 s, 38.271 ms/prime[/CODE]REGULAR SPEED[CODE]2020-06-11 12:22:36 gfx1012-0 108928049 P2 using blocks [33 - 999] to cover 1476003 primes
2020-06-11 12:22:36 gfx1012-0 108928049 P2 using 67 buffers of 48.0 MB each
2020-06-11 12:25:24 gfx1012-0 108928049 P2 1527/2880: 34330 primes; setup 1.64 s, 4.812 ms/prime
2020-06-11 12:28:09 gfx1012-0 108928049 P2 1594/2880: 34382 primes; setup 1.63 s, 4.751 ms/prime
2020-06-11 12:30:53 gfx1012-0 108928049 P2 1661/2880: 34222 primes; setup 1.67 s, 4.752 ms/prime
2020-06-11 12:33:38 gfx1012-0 108928049 P2 1728/2880: 34427 primes; setup 1.68 s, 4.754 ms/prime
2020-06-11 12:36:23 gfx1012-0 108928049 P2 1795/2880: 34351 primes; setup 1.63 s, 4.752 ms/prime
2020-06-11 12:39:07 gfx1012-0 108928049 P2 1862/2880: 34346 primes; setup 1.66 s, 4.738 ms/prime
2020-06-11 12:41:52 gfx1012-0 108928049 P2 1929/2880: 34477 primes; setup 1.68 s, 4.737 ms/prime
2020-06-11 12:44:36 gfx1012-0 108928049 P2 1996/2880: 34187 primes; setup 1.59 s, 4.738 ms/prime
2020-06-11 12:47:20 gfx1012-0 108928049 P2 2063/2880: 34247 primes; setup 1.61 s, 4.738 ms/prime
2020-06-11 12:50:04 gfx1012-0 108928049 P2 2130/2880: 34186 primes; setup 1.69 s, 4.741 ms/prime
2020-06-11 12:52:48 gfx1012-0 108928049 P2 2197/2880: 34376 primes; setup 1.64 s, 4.740 ms/prime
2020-06-11 12:55:33 gfx1012-0 108928049 P2 2264/2880: 34310 primes; setup 1.66 s, 4.740 ms/prime
2020-06-11 12:58:16 gfx1012-0 108928049 P2 2331/2880: 34008 primes; setup 1.64 s, 4.742 ms/prime
2020-06-11 13:01:00 gfx1012-0 108928049 P2 2398/2880: 34314 primes; setup 1.64 s, 4.742 ms/prime
2020-06-11 13:03:43 gfx1012-0 108928049 P2 2465/2880: 34126 primes; setup 1.61 s, 4.739 ms/prime
2020-06-11 13:06:27 gfx1012-0 108928049 P2 2532/2880: 34252 primes; setup 1.68 s, 4.738 ms/prime
2020-06-11 13:09:11 gfx1012-0 108928049 P2 2599/2880: 34253 primes; setup 1.66 s, 4.741 ms/prime
2020-06-11 13:11:55 gfx1012-0 108928049 P2 2666/2880: 34316 primes; setup 1.64 s, 4.739 ms/prime
2020-06-11 13:14:40 gfx1012-0 108928049 P2 2733/2880: 34431 primes; setup 1.64 s, 4.738 ms/prime
2020-06-11 13:17:24 gfx1012-0 108928049 P2 2800/2880: 34264 primes; setup 1.66 s, 4.743 ms/prime
2020-06-11 13:20:09 gfx1012-0 108928049 P2 2867/2880: 34349 primes; setup 1.58 s, 4.738 ms/prime[/CODE]PS - We'd like to speed up the spinner. What source file should we poke around in?

@Mike: Hmm, 146*48/8192 = 0.855, the default run mode was using less than 90% of the card memory. I wonder if different cards have significantly different "system memory" usages by their respective card-management software.

You noted that you were only running 1 program instance per card, so -maxAlloc=4096 should be fine, but were you running 2 instances, looks like you'd need to cut that down to around 3000 per job.

Might be useful to find out more precisely where your card's max-mem-to-use lies - you could move the next PFactor line in your worktodo to make it the topmost line, save, kill run and restart with some high value of maxAlloc, wait 'til it hits stage 2 to see if it's slow, if so kill and restart with a slightly lower -maxAlloc value until you see the speed come back to normal non-swap level.

[QUOTE=Xyzzy;547731]PS - We'd like to speed up the spinner. What source file should we poke around in?[/QUOTE]

Gpu.cpp returns stuff for [c]grep spin[/c], but I can't see how to speed it up in that file.