Well, that's surprising.

Dude you could have told me you're discussing there. We can discuss openly, NP.

Sad to see suchpool go. I liked it.

I'm afraid I'm not understand how can you reach this conclusion.

Then you are wrong. If everyone is guaranteed to have access to more or less the same power then anyone wanting to attack the network will have to go through quite some more effort. You get the same amount of coins, but they hold greater value as they have less risk.

No, it isn't normal, but I have received several reports from multi-gpu users. Some of them don't even get it to work.
I have found a potential issue but in theory it should not be happening at all, which implies there's a larger problem. I haven't had the time to investigate it in detail so far as I've been fighting with the omega drivers.

I don't really suggest to even try because I've forgot a negation in the config switch so it just cannot be used reliably. Whoops!

There are two good reasons.

• they speculate higher performing kernels have value for elite miners wanting to hoard the coin. This is true in general but I hardly believe it's the case for FRESH. Main problem is elite kernels depreciate the coin in similar ways as ASICs, albeit not at that extreme scale;
• the higher hashrate per-miner provides more protection against potential attacks by malicious entities running optimized miners as the difference is lower; this obviously holds true only when the higher perf version is largely available.

Not sure what base hashrate you're talking about but be advised 40% up kernels have been made available for free at least one month ago; I will port them to sgminer for only 0.1btc.

Some testers would be welcome however.

I disagree. I'm more inclined to point my fingers at sellers.

Unitus has algos for CPU and GPU. In theory its parent coin Myriad should have CPU support as well but in practice all algos have been efficiently ported to GPUs.
No "algorithm" supports CPU or GPU... because "algorithm" is an abstract entity.
Better question would be: which algorithm got implementations on both CPU and GPU?
Most, if not all algorithms have been implemented to run on both CPU and GPU. Whatever they run efficiently is another matter.
Pools are not interested in this difference. All they care is you send them good work.

Speaking about driver versions... any update on omega driver (14.12) compatibility? I cannot get this to hash correctly on my system, no matter what, I only get HW errors.

Original Vehre miner runs with no problems.

That's very surprising, thank you very much for the information!

I assume you're using one of those, but which one?

There's some chance I might be getting confused with the other nonsensical "CPU only" algo going around those days.

Are you running AVX on AMD FX? Have you given a go to SSE only? Bulldozers have fairly weak AVX.

Holy crap that's really low. Are you sure you're using the correct builds?

I know a few of my contacts would say an instant NO just for this reason. Libcurl is an hell of a dependency and nobody, nobody in my sector would touch it without an insulating ten foot pole, an adequate salary bonus OR an explicit order.

As a side note: I'd like to thank github for being a total asshole not having notion of the zlib license. Some legal departments do not permit MIT code either.

Probably related to latency involved by pci-ex port (I don't think they're all on PCIex3-16). If you use raisers, those are known to cause latency issues. Assuming they are all same card.

I agree in concept but in practice grs-myr has proven to attract so little interest. I would welcome additional choices.

Only joking. Some people would get pissed and I don't like long chains much.

"oh no"
Now I'll have to make X11 LOL

Compared to what CPU?
240 is a fairly minimal card and the QRK kernel isn't very friendly AFAIK, it might happen.

He's not intending "streams" in the sense of "stream processors" he means "streams" in the sense of "command streams". Most of the time, just use -g 2.