Wrong. The tickets are only valid for one jackpot, then everyone starts from zero. Beyond that I have no clue what you are
trying to say.

The pool buying tickets makes no sense. The pool manager can mine like any other user. The pool is just the accumulation
of all the hash submitted by its users.

Hashrate, or more specifically hashes are like lottery tickets.

The more tickets you have the more chances you have a winning ticket.
If you buy solo you need to have a winning ticket but you get the entire jackpot. If you pool your tickets you
gate a share of the jackpot if anyone in the pool holds the winning ticket based on the number of tickets in the pool.

Now change tickets to hashes and jackpot to block in the above.

One of the things I've always liked about yaamp/yiimp is it has the most transparent stats of any pool. When one is able
to see more of the process there is a chance one will see some things they either don't understand or don't like but
have always existed.

Ooops, missed the part about zcash, my miner can't do it. Some algos are more difficult to mine with a GPU and are often
not worth the effort or don't provide the performance, but anything is possible, I mean a GPU miner is always possible
or it may never exist.

If zcash uses a brand new algo it may not have a third party miner available and may only be mineable from the wallet.
Miner development for new algos depends on interest in the coins that use them.

You just need a regular desktop with the fastest CPU you can afford, water cooled and overclocked. Make sure the
mobo supports OC and everything else can be stock. And of course use the miner in my sig.

http://www.urbandictionary.com/define.php?term=afaik

This the first time you posted this symptom, has it always crashed this way?
If you think it's the miner try a different one.

It's getting a little complicated. Tell me if I've got this right

mine1 works except sha256 & scrypt
mine2 works sha256 & scrypt only
mine maps to mine1 except sha256 & scrypt
mine maps to mine2 sha256 & scrypt only
<algo>.mine maps to mine1 except sha256 & scrypt
<algo>.mine maps to mine2 sha256 & scrypt only

Good point. Some lanes may be reserved for other devices like Sata Express. Check the BIOS config.
Sometimes multiple devices will share lane bandwidth. If that's occurring two GPUs in one lane may be too much.

It's not a good idea to add more cards when you're troubleshooting. I would suggest isolating cards to determine
if the problem is tied to one specific card.

If it was a bug others would likely also see it, but AFAIK no one else has seen this crash. You're getting corruption in the CPU domain
(core, cache, ram), either due to a HW fault or heat induced. If there is a pattern to the fault addresses it's probably a HW fault.
If the're random, probably heat induced.

Due to the extremely high ambient temperature your sensors may not detect overheating in places where it isn't expected.

Still problems connecting. I tried a quark & lyra2v2, both worked only on mine1.
Edit: groestl worked on mine, m7m didn't.
Edit2: blake2s & lbry both connected to mine, maybe an intermittant problem.

Looks like a null pointer dereference. That's usually software but in your case it could be excess heat in the CPU or RAM.
How is the ventilation around the mobo? Maybe heat from the GPUs is destabilizing the CPU.

Edit: It could also be bad RAM. Make note if they are always the same, especially the instruction address.

They all work for lyra2v2, didn't try other algos.

I can no longer make a connection to lyra2v2 using mine.zpool.ca, mine1.zpool.ca worked.

I have further investigated the issues with the blake algos.

Decred never worked on Nicehash with cpuminer, but does work on zpool. This is a pool issue. I don't know
which pool is correct and I don't really care because I don't know how to fix it for Nicehash. Also as previously
mentioned the performance of most of the blake algos is pathetic on a CPU. I won't be spending any more
effort on this issue.

Blakecoin and vanilla both seem functional to the extent I could test them but they are also underperformers
and not deserving of any attention.

I will attempt to maintain the status quo but I don't see any potential of useful CPU mining of these algos.

This is not to disagree with pallas point about how luck work, ie any share submission at any time could solve a block.
but the "mine for long enough" notion does apply in how big a share of the block a miner receives. The share size is
determined by the average contributed hashrate over the entire block time, or more specifically the total hash contributed
to the block. If one has been mining for the entire 4 days their contribution, and payout, will be significantly larger than
someone who has been switching algos.

How that affects mining strategy I'll leave as an exercise for the readers.

This only applies to single coin pools, as is lbry, but with multicoin pools your accumulated share is consumed
by the first coin that gets solved, which may not be the same coin you contributed to. This adds another dimension
of luck to the equation, which coin gets solved first.

I mention this because it relates to my proposal for single coin pools, particularly high diff coins. Imagine if lbry also had
a shit coin in the pool. This would dramatically change the lbry block payouts under identical mining conditions. With the
shitcoin continually eating up acccumulated shares only those who have been mining just prior to the LBC block will get
a share of it, and a much bigger share.

For algos with high and low diff coins it would be good to be able to ensure the hash is contributed to the desired coin,
typically a higher diff coin.

You can use the performance comparison chart in the OP to get a rough idea of the relative algo performance but it varies on
different CPUs. It's best to use your actual hashrates at whattomine.

I've had a similar problem with any ccminer, on some cards but never others, but mostly triggered by neoscrypt. Been happening for
over a year.

It does exist on Linux but I've never tried it. It would be handy to remove the root restriction on nvidia-settings
for setting OC and fan speed, if it's persistent.

Interesting observation. I never really considered that it would be more susceptible to crash when switching algos, or that
spin down time could mitigate.  Good to see you're making progress with your "heat chamber" testing.