Xmr-stak is fairly difficult to optimize (so is SGMiner-GM) and I never got Claymore to come anywhere close to even unoptimized xmr-stak.

SGMiner-GM 5.5.5 gives me the best performance, but, sadly, some tweaking is still required even if given good parameters from someone else with the exact same card. The next best performing miner for me was https://www.amdxmrminer.com/, and it doesn't require any tweaking.

Thanks for the fast reply!

My equihash mining rig does 1860 Sols/s and my current ping time is 130ms so I definitely don't want to go too low in difficulty. Your vardiff strategy sounds okay and a 4:1 difference is fine by me, I just don't want to see a 10:1 or greater range in difficulty, especially if it either pegs at the top end of the range (no longer really vardiff at that point) or it keeps oscillating between the highest and lowest values.

Otherwise, I also like fixed difficulty when comparing miners with my two GTX 1080 test rigs, as it reduces the influence of luck in share count.

But these are minor points and so far I am very happy with your ZEN pool!


UPDATE - not sure if there is an actual problem or not, but balance stats are not updating on the new site nor is my balance increasing on the old site so I have halted mining for now.

That was my thought at first, then I realized that Bitmain would be competing against the likes of several companies with market caps in the $10B - $200B range and millions - literally millions - of already deployed GPUs. Oh, and you can bet those Bitmain miners will feature their legendary quality... 

So now I'm thinking this will be the proverbial tempest in a teapot.

I just started mining ZEN here yesterday and already moved to the new server. Things were/are going well but it does look like ports 3058 and 3059 have variable difficulty, whereas port 3059 used to be fixed diff of 8192. Can the OP explain the difficulty strategy if vardiff is the new norm, because on some pools vardiff is seriously broken and ends up pegging at the max value regardless of your actual hashrate.

About 12 hours into my informal evaluation of zhash.pro and both the first payout rolled in as predicted while average hashrate reported at the pool - with difficulty fixed at 8192 - has remained steady at about 1860 Sols/s. So far, so good, then. Ping time isn't the lowest for me - 137ms average - but doesn't seem to be an issue with the difficulty vs. hashrate I am running.

The burning question I have is: do I switch over my AMD cards to mining Ethash now (not ETH, per se) to get what I can before difficulty goes to the moon... ahem... or do I keep them on Cryptonight?

Otherwise, I suspect this will hasten the transition of ETH to PoS, eh?

My experience so far with Zpool has been excellent, though I admit I'm only on day 3 of testing.

The first 24 hours I mined Lyra2v2, auto-converting to VTC, and got exactly the amount of VTC my hashrate and average difficulty predicted; yes, I understand that as an auto-convert pool there will be much more variation in payout, but it's nice to see reality match theory anyway.

The next 24 hours I mined Lyra2v2, auto-converting to XVG, and received 51 vs. 53 expected - close enough for me given the above.

Now I am running NemosMiner to test Zpool in multi-algo, auto-convert to BTC mode and will be comparing it to a similar rig running NiceHash for at least 3 days. Even if Zpool doesn't win this competition I will still use it in single algo mode because it has performed far better than similar tests done at HashRefinery, MiningPoolHub, and Zergpool.

Maybe - the downsides to PPLNS are basically the result of trying to apply a mechanical rule - payout based on the last N-shares leading up to each block - on a statistical process - the time to find a block does vary in inverse proportion to pool/network hashrate, but it is not a linear function; that is, as pool/network hashrate declines the odds of finding a block decrease much more rapidly chaotically (but asymptotically - it never quite reaches zero for a non-zero hashrate).

What many miners understand is that if pool hashrate for an algo declines while network hashrate remains the same - e.g., most miners switched away from that algo on a specific pool - then pool luck tends to decline as well. Intuitively one may think that as pool hashrate declines it will take longer to find each block, sure, but each share will be proportionally more valuable - lower hashrate, right - so overall payout should remain the same. However, what really happens is that a lower pool hashrate not only increases the time to find each block on average, it also generally results in a wider variation in the time to find as well. THAT is what gets you with PPLNS: the number of shares considered valid for each block remains the same, but it is much less predictable when each block will come, and with PPLNS you only get paid for shares leading up to a block.

Pool operators like PPLNS because they don't have to pay for some of the shares submitted if the time to find the next new block suddenly jumps up as a result of an equally sudden drop in pool/algo hashrate. Miners also eventually learn to remain on the pool/algo until a new block is found to maximize their payout - hence why PPLNS is said to reduce pool hopping, because you can't be sure you'll receive anything if you drop in on a pool/algo for a few minutes or hours without a block being found in that time.

What people wrongly assume - and which few pool operators attempt to correct - is that miners will almost certainly be persistently underpaid if the time to find is "too long" at a given PPLNS pool (where "too long" is a nebulous, hard-to-pin-down number, unfortunately). This is one of the reasons why hashrate tends to concentrate at certain pools for certain coins/algos; it's a rather perverse example of the "network effect" showing up in something that is supposed to be decentralized/democratic by nature (ie - cryptocurrencies).

NB - I am fairly new to mining so my understanding of all this may be imperfect, incomplete or even incorrect. I welcome being corrected; I do not respond well to being called names.

Not quite... If pool hashrate is fairly constant but pool luck is not - ie, the time to find each block varies quite a bit - then any given miner will submit way more than n shares for a block that took much longer than average to find; ergo, the oldest shares end up get tossed out because they were outside of the n-wide window.

Uh-huh, so what happens if the time to find each block varies wildly and routinely exceeds several hours? Doesn't that result in the oldest shares submitted by the miners getting tossed out as worthless?

Ah, good. Did you by any chance try to install the current version of .NET first, as 3.5 is an older version?

Otherwise, I was just about to PM my email address and offer to load your BIOS into my copy of PBE to see if I could apply the one-click timing patch myself.

One other thing I forgot - I recall reading somewhere that ATIWinFlash won't work if you have more than one card installed; I did all of the above BIOS modding on a bare mobo I have set up for this purpose as well as testing cards.

I didn't have any issues... once I installed .NET 3.5, anyway.

The process I used was:

1. Save original BIOS using GPU-Z 2.7.0
2. Load original BIOS into PBE; apply one-click timing patch and save BIOS with a different name.
3. Use ATIWinFlash to load new BIOS onto card.
4. Use ATI Pixel Clock Patcher to convince driver the card is fine.
5. Profit.

And thank you for the reply as well. I'm not at all worried about missing out on the one and only coin I could find that uses the timetravel algo (machinecoin), but I am concerned that a connection issue doesn't get noticed by the script, at least during benchmarking. I also suspect that this affects the original NemosMiner, and not just the MrPlus fork, so still relevant to this thread.

NiceHash invaded this party a long time ago. That's why a single RX 570 can barely crank out 2-3 DERO per day despite that this is still a virtually unknown coin.

Interesting... I had more or less the same experience with vast underpayment with them, too, despite them finding blocks fairly consistently. I've learned to not trust any pool that doesn't charge a fee.

About 20 minutes ago I pointed a rig at http://zhash.pro/ to try them out. Although you have convinced me to mine some ZEC at Flypool - which has, indeed, proven to be very trustworthy - I still want to mainly mine ZEN. Hopefully Zcash.pro doesn't disappoint.

I experienced the exact same issue and reported about it a few pages back. Pretty much the worst bug imaginable for a miner, in my opinion.

Thanks for the reply. I already stopped the benchmarking and switched the card over to mining Verge for a day or two while I sort out what went wrong. Based on the copy-n-paste of the miner window output above it looks like the connection wasn't set up properly (ie - the stratum and port). Unfortunately, I didn't check the miner window at any other time so can't say if this is anomalous or not...

I just noticed that DERO is now listed on the very useful Cryptonight coin calculator at: https://www.cryptunit.com/

By most accounts, BTC is the very definition of a speculative investment, so if you are uncomfortable with speculation you probably shouldn't be in crypto at all.

That said, there is a service that is geared specifically towards those that want to mine but can't be bothered to research every (or, really, any) of the coins out there: NiceHash.