Pretty detailed report. The quoted text seems like the key point. It suggests the problem was triggerred by the
installation of the 2 new GPUs. It could mean it's the number of GPUs or a specific GPU. Try removing
one or the other new GPUs to try to stabilize the system. You could also try swapping risers and slots.
There should be a pattern that leads you to the cause.

Run multiple instances using the -d option to select the GPUs.

ccminer -d 0,1 ...

Cloning an altcoin is trivial and doesn't require knowledge of c/c++ because all the code is already written.
Just tweak some parameters and you have a brand new coin.

True developmnet, specifically mastering it, doesn't require knowledge of any specific language. The language
is just a tool and the job usually determines the appropriate tool to use.

Cryptography, multithreading, networking, gui, distributed processing, etc are the programming skills you need
to master altcoin development.

That's not wallet mining. With pool mining you have to wait until the block matures then the block minus fee will be sent to
the specified address in your wallet. However, there should be a record of the find in your user stats at Nicehash.

You should probably take it up with Nicehash support.

I tend to agree. Many miners report "Yay" when a block is solved and "Yes" for a share.
Considering how much is involved it might be worth trying to find out what happened.

Home edition? gpedit is not included in home edition, AFAIK. I don't know if large pages is supported on home edition
and if so, how to enable it.

Although large pages can improve performance for some apps it's still not mature enough for most users and does
have some side effects.

Mining at Nicehash has some advantages over direct mining. You know excactly how much you will get paid
with no risk of orphans, luck or exchange volatility.

Which is more profitable depends entirely on market conditions which change constantly.

My sarcasm is intentional. The reaction to it determines if a person is hopelessly clueless or simply didn't understand
the scope of the problem.

Come back when you have a CS degree with a specialization in cryptography and a few years experience designing
OpenCL or Cuda apps.

Starting with mastering c/c++ makes me laugh. Mastering the assembly language of multiple CPU and GPU architectures
would be useful but a single high level language is kindergarden stuff.

Excellent advice, worth repeating.

I would also add that you should start mining with what you have before wastinginvesting any money.
Do you have a desktop PC with a decent GPU? Use that. If not you can mine with a decent CPU. Laptops are
not recommended, they can't handle the heat of hard use 24/7.

Once you have some experience you can make an informed decision of how you want to proceed.

You complained about AES_NI when it's the same as AES.
You complained about a crash while using the AVX2 build on a CPU without AVX2.
You failed to provide the key error message (it's not a crash).
You failed to mention it worked with fewer threads (this is a FAQ with verium).
And now your're complaining that it's only using SSE2 on an algo that only supports SSE2.

Stop complaining and learn something.

You're using the wrong exe, your CPU doesn't have AVX2. Use the exe that matches your CPU's features.
AES is the same as AES-NI.

Interesting question, did this come from the Xeon Phi thread? The short answer is no.

AVX512, as its name suggests. introduces 512 bit vector processing. This means it can only be used on arrays
of multiples of 512 bits (8*64, 16*32 etc) and only if the same operation is performed on all array elements.
This limits the applicability of AVX512 depending on what kind of processing is performed to hash the algorithm.

Vectorizing improves compute performance by reducing the number of instructions but it doesn't help memory performance.
If you need to process 512 bits you srtill need to load the same amount of data from memory. If an algo is memory
hard vectorizing it just means the CPU spends more time idle while it waits for data.

Some algos have segments of code that can be vectorized, some to 128 bits, fewer to 256 and even fewer to 512.
However converting these sections adds overhead because the vector instructions use a different register set than
scalar instructions. Switching back and forth from scalar to vector instructions on the same data means extra instructions
are required to move the data from one register set to the other and back.

I haven't looked deeply into AVX512 but I don't see much opportunity to optimize any algos with it. Anything that can be
vectorized further is likely more efficient on a GPU which is essentially a vector processor. At best, vectorizing a CPU miner
simply reduces the performance deficit slightly compared to GPUs. Many "CPU" algos are designed to be difficult to vectorize.

An interesting article about AVX512:

https://www.hpcwire.com/2017/06/29/reinders-avx-512-may-hidden-gem-intel-xeon-scalable-processors/

Threadripper expands the concept of the CCXs, 4 core modules that are combined to form a 8, 12 or 16 core CPUs.
The side effect of this is each CCX has it's own piece of the L3 cache. This makes it inefficient for a CCX to access
data from the L3 cache on a different CCX. Ryzen also uses this architecture.

In many ways this is like a multi-CPU system.

Higher hashrates may be achieved by running seperate miner instances for each CCX module to prevent data accesses
that cross CCXs. This will require a different cpu-affinity mask for each instance. I don't know exactly how AMD
maps logical cores to CCXs, particularly when hyperthreading (AMD calls it SMT) is enabled. It may take some trial
and error to reverse engineer the mapping and determine the best affinity mask for each miner instance.

Ryzen CPUs and multi-CPU systems may also benefit from multiple miner instances.

Unfortunately I am just a spectator as I don't have a Ryzen or Threadripper CPU (yet) to do the work myself.

I'm not sure I understand the problem. It is normal to have fewer hash reports when solo mining because you have to solve
the entire block, not just a share.

My misunderstanding. The impact will be infrequent share submissions.

A heads up for those mining on yiimp with a CPU, you may see rejected shares for low difficulty.

https://bitcointalk.org/index.php?topic=841401.msg20854352#msg20854352

Not paying users for submitted hash is theft, plain and simple. And your attitude in this thread  says all that needs to be
said about your immaturity and lack of ethics.

No, it's not POW.

It gets confusing with all the superfluous data like hashtap. Like I said before it's better to track one block from
start to finish. There is less noise to distract the skeptics.

I did that with the Aurora blocks (Topaz is just a rounding error) and I now see clearly. At no time in the last week
has AUR dropped below .017 mBTC yet you only got .014.

It looks to me that the problem got moved. Previously everthing was correct until the block was cleared and
added to the balance. This could result in a very obvious drop in total unpaid with every balance increase.

Now the 20% is already lost when the block is first posted. This avoids the visible manifestation in the graph
when the 30% is taken away. I'd suspect an attenpt to cover up but now it's even more obvious because all one
has to do is audit the amount and value against the exchange rate and see it's 20% below market. Unless a coin
has more than 20% volatility it should be obvious.

That was excellent work but it took me a while to understand it.