I don't know what numbers you're running, what you guys are stating makes no sense to me.
Do anyone of you even touched a solar panel IRL? Seen one? Bought one?

Anyway, going back to the point. I consider MYR (or multi-algo) to be a step forward compared to VTC. The implications of an accessible mining scheme are very interesting by a social standpoint.

However, in the real world, both have demonstrated that as much as your idea can be good, little hashrate is little hashrate and once you go below a certain threshold you can have as many security as you want. It is incredible how few were mining MYR last month!

I suggest you clarify in your post (or put it in signature directly) IF and HOW you are related to the Myriad cryptocurrency.
Everybody looking at your username will just take for granted you are some sort of admin for myriadcoin, as it is the case for some other alts.
In retrospect, it is incredibly dumb the MYR community didn't take that username and I cannot really blame you for using it BUT it is clear you have already taken a decision WRT this matter. Please be careful.
Nope! Hashrate is a nonlinear property. The fact that GPUs are competitive on 3/5 algorithms does not imply 60% hash rate.
I think I follow your line of thinking but you are evaluating the implementations of the algorithms, not the algorithms themselves. All MYR algos are SHA-3 candidates or derived from SHA3 candidates so they are similarly complex. GPU farms as you imagine can just burn $$$$ and get access to an optimized kernel. Most SHA3 candidates are dead simple compared to some crazy shit going on AAA videogames.

Mine? Supposed to be hassle-free, it also bumped up performance quite a bit on release... I suggest to set it to low intensity and play some game!

Holy ███████ ████.
Did you really register yourself as 'myriadcoin' without being the administrator or something?
████.
I think people will assume this thread is not really serious. I don't. Maybe you're really asking for other's opinions but that's not the best way to start isn't it?

It makes you wonder? Definitely the latter, you guys seems to have garages full of vidcards and cheap electricity. There is seriously no question.

With most hashes producing at least kilos per second I understand you hit an extra button out of habit.
I read a message some time ago from an user considering GPUs "immensely" more efficient... I was very surprised!
Good to see it has been fixed. Too bad nobody seemed to make this question.

Anyway, a couple of days ago I managed to reproduce yescrypt on GPU myself starting from the original code from Password Hashing Competition... so far it's very painful at roughly 1/3 of the hashrate. OUCH!

Habit, I guess!

I would suggest to check those values.
Suchpool currently reports network hashrate at 367 kH/s, which would imply it's one third of a single 750 ti? Not realistic at all.
P2pool nodes report estimated network hashrate ~185khs, which would imply it's one fifth of a single midrange card. Hard to believe no 750s are on p2pool.
In may 2015, crypto-mining blog reports
– Intel Core i7 5820K CPU: 5.22 KHS
– AMD Radeon R9 280X GPU: 0.793 KHS
– Nvidia GeForce GTX 980 GPU: 1.124 KHS

Hard to believe a 750ti can produce 973khs, being equivalent to 186 i7-5820k processors which are... twice as expensive?

Odd, I was pretty sure I sent you a message. Maybe I clicked on the wrong button and sent it to the trashcan instead!
The original message was here.

What it means: first of all, I use rawIntensity instead of normal intensity or the widespread xintensity. Reason: it's just easier to understand what's going on. In theory, 2^intensity == rawIntensity.
Back when that message was written there was an old kernel (v1). You can ignore it now, it was just for reference.
The (v2) column is what you care. I don't know if this is the current AMD kernel. I could retry everything if you want.

Let's see if I can make something clearer (without using btctalk broken table features)

┌-------------------------------------------------------┐
| --rawIntensity | Equivalent  | h/s | Watts  | Temp    |
|                | --intensity |     |        | Celsius |
├----------------+-------------+-----+--------+---------┤
|  16            |      4      | 30  | 58-106 |   44    |
|  32            |      5      | 56  | 56-105 |   48    |
|  64            |      6      | 91  | 60-105 |   50    |
| 128            |      7      | 152 | 62-109 |   50    |
| 144            |     n/a     | 105 | 61-107 |   49    |
└-------------------------------------------------------┘

So, my card mines at best at rawIntensity 128 (should be equivalent to intensity 7), it produces 152 hashes per second burning between 62 and 109 watts (full system load) and topping at 53C.

I reported various settings so you can see it in perspective somehow. I honestly expected some more scaling as computing 128 hashes "only" takes 256MiB of VRAM.

Hello WigitGetIt and BSTY fans!
I was looking at the performance spreadsheet expecting to find something interesting at this point but I see very little data. There's no trace even of the numbers I provided some months ago!
How are the things going? It seems to me the quotations are decent, have you all moved to multipooling this?

Re-read your previous question. I'll try to make it easier.
If you work at diff 32 and send a result to the pool, it will have value '32'. If you work at diff 128, each result has value '128'.
At the end of the round, those values make up your share of the reward proportionally.

Only if you have enough hash. At the extreme, you can mine at network diff and at that point you'll be subject to normal variance.
If your diff is so high you miss to send result across a whole round you'll most likely be screwed somehow. Pools don't reward share value exactly and the time distribution is important. Producing less than 2-3 results per minute might incur in quite some loss, especially if your pool has high rej% such as the case for p2pool.

No such thing as a 'protocol' for SHA3.
SHA3 is not a 'protocol'.
It is an algorithm, a standard maybe, not a 'protocol'. Usually 'protocols' involve the language used by two peers to communicate.

SHA2 is very mildly parallel as far as I remember. SHA3 possibly even less so (I looked at it for about 2 minutes).

You're confusing properties of the hash with properties of the PoW 'scanhash' function. The latter is embarrassingly parallel by definition, the former is not.

All PoW scanhash functions are embarrassingly parallel, whatever this parallelism can be exploited is another business. For SHA3, there's basically no problem in SHA3 itself. So yes, you can compute multiple hashes in parallel. That makes scanhash faster, Keccak is just as fast as previously.

None of those questions are really related to the market but rather on mining.

The solution of a block is called 'nonce'. When you mine in a pool you mine 'fake' pool blocks having lower difficulty than network. Those 'fake' blocks have 'nonces' like the network block but they're called 'shares'.
Why is this the case?
When the pool makes you mine at diff 2, every solution you send will have 'value' 2. At diff 4, every solution will have value 4 and so on.
However, the real 'value' of a magic number you send is not truly related to the difficulty the pool requested: it is a function of the number you found.
So, the pool might request you to mine at diff 16, you find a solution to be sent back, it might have difficulty 16.123 or 143k.
All the shares better than requested difficulty are accounted (at pool diff) but if a share also have a higher value than a real block then you found a network solution (found a block).

You're taking it a bit on the extreme: it is hard to believe the two pools can have comparable hashrate.
The number you have to look for is the "average round". Pools with more or less the same average round time will give more or less the same payout. Caveats apply.

The percentage is a function of difficulty, the whole idea of difficulty is it counts how many attempts you must try before you find a block solution.
Note: difficulty is a pooled mining concept and convenient for human beings but it does not exist at network level. Network level works on 'targetbits' instead.
The properties of the hash functions involved guarantee the solution(s) are randomly scattered. Everyone can therefore find a solution but of course an user twice as powerful as you have twice the chance to find one in the allotted time as he throws twice the amount of dices.

LTC hashes Scrypt. Scrypt is ASIC game now. You have no chance to compete with GPUs. They've been out of the game by a year easily.
Note: difficulty for alts is not comparable. For the purpose of explanation let's say some alts measure diff in inches and some other in yards.

The network wants a block every X seconds. Every once in a while, it will count the amount of blocks and figure out they have been more frequent than predicted. If so, the network decides to rise the targetbits requirement. Difficulty therefore goes UP.
Maybe the network expected 120 blocks in a time frame and it got 100 instead. Then difficulty will go down.
It is therefore possible to predict it by running the computations in advance. Due to decentralization there are some extra complications predicting it accurately is much harder. Predicting it over long time frames is pretty much impossible.

Most of the algorithms you have cited are SHA3 candidates. They can be better investigated at the SHA3 zoo or WP:EN.

Most of them have no ASIC resistance while some are explicitly ASIC friendly.

The 256 bit variation is not very relevant. The structure is basically the same for most of them and they are stronger or weaker as you would expect.

My impression about some I have taken a look at:

• Blake is possibly one of the best, mostly because its cipher function essentially set a new gold standard
• Groestl is relatively simple to understand but the simplicity does not map to implementation. It is heavily S-box based using AES round. In practice it isn't much of a big deal, albeit it's probably one of the strongest security competitors
• Keccak is SHA3 winner because of its extreme ASIC friendliness
• A friend of mine has a thing for Skein. Apparently it performs very nicely on all kinds of hardware (ASICs are faster, but not considerably faster) which means everyone can have access to a reasonably efficient implementation (OR: nobody can have an immensely faster one). I have to admit I agree with him.
• Luffa is pretty ugly. It's most likely optimized to produce extremely little ASICs for use in embedded systems.
• Pretty much the same for ShaVite3.
• CubeHash is awesome. It was not designed by a 'pure' cryptographer but rather a security expert fluent in cryptography. It has an unique construction and plenty of parameters which allows it to adapt on a wide range of hardware. Cryptographic bandwidth is also high and it's most likely the easier to implement (for some parameter set). I honestly have a thing for this, even though it isn't a finalist.
• Something is seriously wrong with SIMD. Apparently under some circumstances the output is considerably different from a random oracle (I cannot hit the right keywords now). SIMD is complicated in both theory and implementation using some constructs which are not purely cryptographic in nature. The complexity produces a low cryptographic bandwidth and the benefits are not even well proven.
• ECHO is somehow nice, relatively simple and parallelizable.

The idea of scrypt is to accumulate various hashes (except they are not hashes: they are block ciphers, but that's not considerably different for the purpose of discussion) and use their effectively random bits to force memory usage. Because memory is slower than computation, they speculate this increases security as a brute force attack cannot access any faster architecture (memory is memory, and commercial RAM is rather efficient).
If you ask a 'pure' cryptographer they'll tell you that this kind of approach is pretty weak compared to higher complexity functions or tuning parameters, or new designs. I even read a paper by Intel (I think) stating this. That's probably true in theory.
In practice, high memory usage is the only thing that keeps ASICs at bay but due to some debatable decisions, ASICs for scrypt-1024 are viable.

Scrypt-jane uses the structure of scrypt using different block ciphers (such as Blake). It is not considerably different. Scrypt-jane is really a framework to produce "variation" of scrypt as far as I've understood.

Another few things you might have heard of...

• Neoscrypt: I don't even remember what was the point with this. It was introduced to avoid scrypt ASICs... they could have used any ready-to-go function but instead they decided to go with this. It does mix-and-match with various building blocks to (apparently) increase complexity of chip design, which I find debatable. The extreme arithmetic intensity implies an eventual ASIC for this will have a huge advantage.
• yescrypt: it is super complicated. You'll need a few beers to see the similarity with basic scrypt. The bottom line with yescrypt is that it needs a 64bit ADD and fast, low-latency memory. There's basically no arithmetic intensity at all so there's nothing to accelerate. It is extremely effective at avoiding the issues with scrypt. Cryptographically speaking it's built on basic SHA256 so "in theory" it isn't much of a big deal. In practice the thing is effective even though I don't see any context in which it works as the extreme cache usage will make everything else running on the same system go super-slow but I'm not really that familar with hi-end server chips.
• M7: just another chained hashing scheme using old cryptographic functions. In theory, those should be considered obsolete after SHA3 competitions have been held but they're not 'utterly broken' either so somebody decided to give them a go.
• M7M(v2): M7 hashes are fetched to non-cryptographic constructs (arbitrary precision arithmetic by gmplib).
• Tromp's Cuckoo cycles based PoW: because there's more to throwing away energy to compute random numbers, we can throw away energy to walk random graphs. No idea why this is better than just hashing stuff, I'm most likely missing something. In the end it doesn't matter as nobody uses it...
• ... albeit Ethereum PoW apparently involves walking a DAG somehow, which might have some similarity or not (I haven't looked at either).

There's no need to CPU-sync for JHA/Quark use an append/consume buffer. This is especially the case if you don't pipeline work.
Have two atomics and a buffer, filling it with from head and tail depending on what path you need to follow.
Then dispatch both and have them branch-out when the count is exhausted, this will naturally produce N-1 fully coherent wavefronts with no sync required.

As a side note: DirectCompute11 even has helpers to do this in API, DispatchIndirect allowing to save the branch-out... in theory, under certain circumstances, maybe. Have you tried OpenCL pipes?

In my mind this reads a bit funny.

Wow, that's setting an high bar! You're not asking him to provide the source or anything like that, just a simple question!

Put the two things together. 

Good luck in finding it. As far as I can tell nobody around here uses this kind of cards!
I have one so I'm interested. But I never mined X11.

GlobalBoost-Y is based on YeScrypt, which will be CPU-friendly pretty much forever. BST-Y is a bit slow lately; I don't think it's profitable right now but you might want to try it.

There are GPU miners for yescrypt but my understanding is they're barely competitive.

Owch!

Seriously, just ask a mason to install a huge ventilation pipe 90deg turn on the outside. It is ridiculous you relied on pressure to keep the rain out and then pushed directly on the hardware.
As long as rain isn't being pushed up from the ground, no chance it's going to enter the building. No, an awning does not offer the same level of protection.

In particular, installing drainage is pretty much nonsense as it doesn't catch airborn water droplets unless you install a filter which will reduce fan efficiency. Plus drainage requires maintenance (albeit little, and that's probably something you're not interested in). I've never heard of such issues when the 90deg turn is used (it depends on how fast you suck in BTW).

Idea (2) is actually fairly good. Not sure 30 min is sufficient in case of catastrophic failure of the first layer of protections but I like the idea.