It has been my experience - albeit, let's keep my member level in mind - that too high of a mem clock just causes bad shares and artifacts on the screen; it's too high of a core clock or too low of a core voltage that causes actual crashes.

That said, I noticed improved stability on my RX 570 rig after upgrading to the latest AMD driver - 18.2.1 - but haven't yet upgraded the RX 560 Cryptonight special just yet and it has been running fine ever since I lowered the rawintensity in SGMiner from 416 to 408.

Now you know where my username comes from... I've been letting out the magic smoke for decades now!

But yeah, just because m.2 is compatible with PCIe from a bandwidth perspective doesn't mean you can pull the same power from it as a real PCIe slot. AMD cards, especially, tend to draw quite a bit of their power from the PCIe bus, even if they also have 6 or 8 pin connectors.

You gave 31 merit to a post praising LWF's ICO while you are a participant in the LWF signature campaign... I'd say you earned your spanking from @actmyname.

Okay, I connected to port 5555 on your pool about 15 minutes ago and difficulty seems to have topped out around 40000 and is oscillating between that and around 19000. 40k is still high for ~720 H/s, but it's a lot better than the >200000 it was soaring up to - and staying at - on ird.cashpool.us. I would say you have a workable and acceptable vardiff implementation; the best I have seen for a Cryptonote pool, actually.

Thanks for taking the time to ferret this out, so I gave you your first merit! And now I am totally out of sendable merit so I hope I don't see any more good posts today...  

I would have tried inserting a period first, except I saw that the French pool used + as a separator instead (I will refrain from making the typical joke about the French here... So... Difficult... Though...). Also, it usually takes a few hours before a pending balance starts to show up and I didn't want to waste a bunch of time by choosing the wrong separator.



Sure, I'm trying something else out right now but I'll be able to switch over to irdpool.eu within the next 30-45 minutes. My ping time to your pool is 115ms which is basically the same as to irdpool.fr and so not ideal, but still workable at a reasonably high difficulty.

No to ahashpool because the 0.01 BTC minimum payout is too high when all you got to test it is a single GTX 1080 (about 30 days to reach 0.01 BTC). Also, I am in the US and ahashpool is in Asia so probably not the best ping times (don't know because ahashpool.com is not pingable).

I already did a comparison of NemosMiner/MiningPoolHub vs. NiceHash and NH won that round by about 10%: https://bitcointalk.org/index.php?topic=1777336.msg29417942#msg29417942

Since Zpool is on the same track as MPH and BTC price isn't plummeting every day like it was when I tested MPH, I am leaning heavily towards blaming the auto-switching algo and/or how profitability is estimated. For example, during the current test of Zpool the top algo - whatever it may be - is always projected to earn at least 0.450 mBTC per day, whereas NH is holding fairly steady at around 0.300 mBTC per day.

It was because I was expecting this type of result that I wanted to mine a single algo and convert to a coin on Zpool first so I could get a good feel for any "slippage" that might be occurring, and as I already reported there wasn't any (not that my testing was exhaustive, but still, some testing is better than none at all).

I gave you some sass in my edit because you took the time to correct my description of ird.cashpool.us but didn't take the time to read the part which I bolded above for extra emphasis.

As for why I asked about it here rather than email the pool owner directly, I thought an answer to my question would be of interest to others. I know many feel the same way I do about the totally dysfunctional vardiff strategy usually implemented on Cryptonote pools and it is only by complaining about it loudly and often that anything will ever get done - after all, there was a reason you implemented fixed diff, no?

Yes, NiceHash and NemosMiner/Zpool are running concurrently on separate rigs that have been matched very closely on one particular algo (Equihash). I didn't check every algo exhaustively, but I can tell you that Neoscrypt runs at the same speed on both cards as well.

I just started mining this on the official US ird.cashpool.us pool and I see it implements the terminally broken vardiff system so common to Cryptonote pools.

I'm doing about 720 H/s on the 5555 port and diff is already at 129922 after a mere 10 minutes. I understand that higher difficulty shares are worth more, but that is only true if they get solved/submitted in a timely fashion.

Usually one specifies a fixed diff on similar pools by inserting either a "+" or a "." in between <wallet address> and <difficulty>. I read the first page and the last 3 pages of post but didn't see this mentioned for ird.cashpool.us (I did see that a pool in France offers fixed diff, but ping time isn't too good for me here in the US).

EDIT - corrected to make a pedant happy

Avoid BCN at all costs.

A Cryptonote coin that I feel has real promise is DERO.

Another that is a bit more speculative but has a good idea is Intensecoin.

For something really speculative and perhaps veering closer to questionable: eDollar.

There isn't a really good option to trade shitcoins for something more respectable outside of an exchange, and the shittiest of shitcoins are on the shittiest of exchanges (I'm looking at you, stocks.exchange).

So if you want the high spikes in profitability that only a shitcoin can deliver the best option is probably to mine the algorithm on a multi-algo, auto-switching pool like Zpool, MiningPoolHub, HashRefinery, etc., and have it automatically convert to ETH or BTC.

Most of your questions are answered in this post: https://bitcointalk.org/index.php?topic=1751272.msg30205761#msg30205761. The comparisons I am doing are rather informal and should be treated as such. Any difference of 5% or less should be considered a tie on account of the rather low hashrate of a single GTX 1080 and I tend to runs these tests for 24, 48 or 72 hours when 7 days or more would likely be necessary. But since you all aren't paying me to do these tests I get to pick the contestants, run time etc... 

I am not using NemosMiner with NiceHash's pool - that doesn't make a lot of sense to me, frankly; miner scripts like NemosMiner along with algo-switching pools like Zpool, MiningPoolHub, HashRefinery, etc., are /alternatives/ to NiceHash, after all.

The running total of BTC does not take into consideration the 2% fee that NH charges to move "theoretical BTC" from your local miner to their wallet (no BTC is actually transferred, hence "theoretical"). I have a Coinbase account so I can transfer from the NH wallet to there for free.

I have no good explanation for why Zpool/NemosMiner are so far behind NH, but prior to this comparison I tried out Zpool in "single algo, convert to a coin besides BTC" with two different coins (same algo - Lyra2v2) and got excellent results. I therefore feel like the pool is trustworthy - it's not intentionally shortchanging me, in other words - so the difference in earnings may very well point to a flaw in the algo-switching.

For example, it takes vertminer - a specialized fork of ccminer strictly for lyra2v2 - a good 20 minutes before it gets fully up to speed on my 6x GTX 1060 rig: it starts out at around 120 MH/s and climbs to 133 MH/s - that right there is 11%.

I've noticed something similar with Neoscrypt, both with HSRminer and ccminer KlausT.

But as for why this is occurring, I have no clue.

I just passed the 24 hour mark comparing NemosMiner on Zpool vs. NiceHash, since NH is the only reasonable metric I could come up with to evaluate the performance of these multi-algo mining pools.

So far NH is beating NM/Zpool by about 11%, but I am going to run the test for at least 2 more days - 72 hours total - because I am just using a single GTX 1080 in each rig.

English verbiage is still a bit wonky here and there but overall the new website is fantastic; I'm definitely getting that "world-class" feel from it now.

I couldn't detect any change in core 0 / thread 0 usage on my Ryzen 5 1600 desktop with the web page open, but this isn't some power-starved laptop CPU, either.

A quick update after the first 24 hours of running - NiceHash is currently ahead with 0.33331 mBTC earned vs. 0.29274 mBTC immature + earned at Zpool.

The two rigs I have set up for doing these kinds of tests consist of a single GTX 1080 that I have tuned to deliver the same  Sols/s (+/0 0.5) in Equihash. The algos I have selected in NemosMiner for Zpool are:

poly,hsr,keccak,xevan,skunk,tribus,phi,skein,equihash,groestl,sib,bitcore,x17,blakecoin,Nist5,MyriadGroestl,Lyra2RE2,neoscrypt,blake2s,lyra2z

Other settings in the NemosMiner bat file are to check profitability every 60 seconds (-interval 60) and switch algos at 5% difference in profitability (-ActiveMinerGainPct 5).

For NiceHash I have all of the single algos selected except for a few that I know have been ASIC'ed: keccak, nist5, neoscrypt, Lyra2rev2, DaggerHashimoto, Cryptonight, Equihash, Pascal, Blake2s. Oops, looks like I left Pascal enabled, even though it has been ASIC'ed... Oh well, can't change it now without invalidating the test.

One other update - I got credited for 1.5 more XVG in my earlier test so that brought the total up to 52.5 actual vs. 53 predicted; again, not the most scientific of tests, since one is mining multiple coins with a single algo, then converting everything mined to one of those coins, but you really can't complain if you get exactly the amount of coin your hashrate and average difficulty predict.*


* - I am well aware that this is not a terribly accurate means of evaluating the performance of a pool or miner, but there simply isn't any other way to do it when switching coins, much less switching algos.

Whoa there, weiner-dog... If people don't make a big deal out of secret, encrypted connections made every 15 minutes by a miner program then what incentive is there for the dev to explain it, much less stop doing it?

Complaints like this are not about being an asshole, rather, it's to encourage a bit more transparency and accountability from the dev.

Frankly, I won't use a miner that does this secret squirrel shit, either, even if it is slightly - and I do mean, /slightly/ - faster than the competition.

So if bminer wants my business then he needs to A) improve stability - if your miner is 3% faster than the competition but it crashes with no outward appearance of doing so it isn't faster anymore; B) stop messaging home base every 15 minutes for "licensing information and updates" - what license, and why check for updates every 15 minutes when they aren't released but every month or so?; C) lower the devfee - I know dstm and ewbf charge 2% and the dev thinks he's entitled to the same, but that's not how capitalism works - when you are a newcomer to a field with entrenched competition you can't expect to immediately charge the same as said competition and thrive.

It depends. On my 6x GTX 1060 rig and my Founder's Edition 1080 test rig I use hsrminer because it is faster and stable, but on my other 1080 (Asus ROG Strix) I use ccminer because of the mysterious drop in hashrate that inevitably occurs after 1-3 hours of operation (a drop reflected on the pool, as well).

Bah, always a show-off in the group! 



Ah, it's not just me, then. Nope, failover doesn't work for me, either. Honestly, sgminer-gm is a hot mess, but so far it performs the best so I put up with it.



Yeah, see this post of mine to the SGMiner thread: https://bitcointalk.org/index.php?topic=1612329.msg29859202#msg29859202

There is almost no logic to the optimization parameters (rawintensity, worksize, gpu-threads) and worse is that completely different rules apply to different algos. Now I understand that optimization /should/ be different for every algo, but what doesn't make sense to me is why worksize should be 192 for Ethash but 8 for Cryptonight? Or why one of the devs (OhGodAGirl) said that if 1 gpu-thread is used then worksize can be set to 8, but for 2 gpu-threads you all but have to set worksize to 4... and then I get the best results by far when I set worksize to 8 and gpu-threads to 2?! Then there is the rawintensity parameter which is supposedly estimated by multiplying the compute units by 4x the worksize, which would be 512 in my case, but sgminer immediately crashed with that setting so I did a manual binary search starting with half the calculated value, 256. SGMiner loaded but the hashrate was low so I next tried halfway between 256 and 512, or 384; that was quite a bit faster, so next was 448; that was a bit slower, so next was 416. That seemed to work really well but seemed to have stability problems, because the rig kept locking up after 8-12 hours of operation so I've since dialed back rawintensity to 408 and that only knocked 2 H/s off the speed but it seems to be much more robust (only 2 days at 408, but no crashes).

Claymore was significantly slower for me - about 340 H/s was the best I managed, though I didn't spend nearly as much time on it as I have SGMiner - and while xmr-stak works really well on my AMD CPUs, it hasn't been a top performer with any of my AMD GPUs. But that could be from not persisting with the tweaking as much.

Well, I warned you that sgminer-gm was difficult... 

Here is my entire .conf file for mining ITNS on a system with (2) RX 560 and an Intel integrated GPU (which you don't want to use, obviously):


The "gpu-platform" needs to be set to "1" if you have an integrated GPU, otherwise set it to "0".

And my .bat file:


The switch --gpu-reorder may be needed with integrated GPU present. I haven't actually tested this yet and might not since everything works fine right now so why mess with success?