I don't have large pages enabled - will have to reboot to set that - but so far setting "-t 8" has resulted in more CPU usage - close to 80% - and *less* H/s - now averaging about 360!?! I even tried re-enabling the devfee and no difference (except it wasting 40 seconds trying to connect to one of the pools that couldn't be reached - not cool, Claymore).

So I don't know how you are getting >470 H/s out of this miner...

No problem, just making sure you and I are talking about the same thing.

So according to the readme!!!.txt file there are a couple of settings that affect CPU usage, with the most important one being "-t n" where n is apparently 1/2 the amount L3 cache in MB; the Ryzen 5 1600 has 16MB of L3 cache so the optimal setting should be "-t 8". I'll give it a shot and see how it behaves.

Meh, I don't begrudge the miner authors their cut as long as they deliver something that makes said cut worth paying and respond to issues in a timely manner. That said, bringing in >$360k US every month might sap the motivation to actually do real work... because, baller lifestyle, right?

You mean threads? It's a 6-core CPU, 12-thread CPU. According to HWInfo and task manager I am using all 12 threads but at around 60% of maximum. I'd be okay pushing that to maybe 80%, but this is the computer I actually use so I don't want it to get too sluggish.

~400 H/s is a bit low for a Ryzen 5 1600? That's better than I'm getting with mine (370-390 H/s), though I did turn the devfee off because it kept failing to connect to the devfee pool and was spending way too long on the issue.

*If* I can get 400+ H/s *and* the devfee server isn't an obstacle I'll gladly re-enable paying the devfee.

Ah, you were shodan'ed...

I didn't enable this port - or any other remote monitoring port, actually - in the first place. So for Claymore to warn that it couldn't access that port was understandably worrisome. I'm not mining an Ethash coin right now, but explicitly adding "-mport 0" to the command line and restarting seemed to take care of the problem.

Interesting; I wonder if this is what was happening to me earlier with Claymore reporting that mport 10048 wasn't available?

It's possible to mix AMD and Nvidia cards on the same mobo, but it tends to be temperamental and not really advisable for the noob miner.

I have a dual GTX 1060 3GB rig mining ZEN that delivers about 610 H/s on average and uses a total of 315W at the wall (the entire system). Cards are set for 85% power limit and modestly overclocked to 2000/4150.

If you mine a Cryptonote coin like Monero, Electroneum, etc., then a powerful CPU can easily pull its weight. The Ryzen 5 1600 I have in one desktop does 370 H/s while an older FX-8300 still delivers a respectable 190 H/s; a really ancient Phenom II 955, however, only manages 55 H/s and Windows (7) slows to a crawl.

So a possible setup would be two RX 570 or GTX 1060 plus a decent CPU so you can use a GPU miner program at the same time as a CPU Cryptonote miner (e.g. - Claymore's v3.9).

LOL... clearly I went into the wrong line of work...

542 ZEC in the last month?!?

Yes, you may come to regret inviting me to join your pool! 

The overriding theme of my complaints here is that MORE COMMUNICATION IS BETTER. If the main pool gets out of sync, explain what happened and, more importantly, what is being done to correct it. If your original account is locked for promoting DERO contrary to the site rules then you need to mention who you are and why you are posting from a new account on every single post you make (ie - just like in a sig, except I think you can't have a sig here until you reach a certain post or account age threshold).

Question: why would this miner complain about mport 10048 or the like not being available when there was no switch for the remote monitoring port in the command line? It seemed ominous so I stopped the miner and added "-mport 0" to the command line before restarting, but I haven't a clue why it was complaining about not being able to access the port in the first place.

Yeah, that's great, but why do they keep getting out of sync in the first place? Also, I don't know who you are with a username suspiciously similar to the dev, but just showing up here acting like him without any explanation is a bit shady.


LOL, I'm an expert at this procedure by now; I don't need any more help doing it.


No, I don't think so. You need to explain who and what belongs to these IP addresses before anyone should do anything. For all we know it could be an alternative blockchain. The way the network seems to keep going down every night sure points in that direction already.

Well, once again I wake up to find both DERO pools are on different blockchains and it is the official one that is far behind. It's hard to believe in a coin when the official pool keeps going down.

Ideally, the pool settles on a difficulty level for your miner's hashrate capability that results in a share every minute; in practice, the difficulty level tends to oscillate over quite a wide range. The behavior is eerily similar to an instability phenomenon in feedback loops called the Right Half Plane Zero, but that's veering off into the engineering weeds.

Suffice it to say that most (honest) pools will give you close to the expected payout if you stick with them for more than a few hours at a stretch; 24 hours or more per coin usually gets you a fair result.

EDIT - but to answer your specific question, yes, the longer you mine a particular coin at a particular pool the closer your actual payout will come to the predicted based on your miner's reported hashrate vs. the average difficulty over that time period.

Yes, this is normal - it is the pool ratcheting up the difficulty for your particular IP address. Higher difficulty shares earn more per block (you can think of them as bigger pie slices, where the block is the pie) so nothing to worry about.

Bah, let me contribute something useful to this thread, willya? 

You did order some of the 8 PCIe port Onda boards, though, so it would be interesting to see if there are any differences. Also whether or not the molex/sata connectors on the mobo are bussed together or supply each card individually (in addition to the PCIe power connectors on the cards themselves, of course).

No, only coins that use the Cryptonote/Cryptonight algorithm. BTC requires specialized hardware to mine (usually called "ASICs").


More or less. As an example, here is my command line for mining edollar:


Note that I have disabled the devfee (-nofee 1) and also disabled restarting the miner if a fault occurs (-r -1) so that I can see what caused the crash.

Obviously you'll want to change the address - after the -u parameter - unless you want to mine for me.


Yes, that is precisely the CPU in my main desktop and I am getting about 370-380 H/s out of it with the devfee disabled. I am also running this miner on an older CPU/mobo that has an AMD FX-8300 and I'm getting about 180 H/s out of that one. Ryzen really kicks ass.

EDIT - I should note I also tried this on an even older CPU/mobo with an AMD Phenom II 955 and I was getting a pathetic 55 H/s out of it...

I throw most of my hashing power at ZEN, but for wildcard/fun I throw a decent amount at DERO (http://pool.dero.live) and eDollar (EDC - https://pool.edollar.cash).

One thing to keep in mind about new coins is that they tend to have a lot of teething pains, so to speak. In the ~1 week or so I've been mining DERO the blockchain has gotten out of sync twice while the EDC pool I gave above (the official one in the US) has a really low hashrate so payouts will be sporadic.

Yes, I read the same thing which is why I thought it might be useful to find out just how much is being used by which connectors/wires. I will almost certainly be populating my Onda D1800 (this is the 6 port one with the "Untel Celery" CPU) with much less ambitious cards than our fearless OP; likely all RX 570 on one and all GTX 1060 (3GB) on the other.


EDIT - mine is the 6port Onda, not the 8 port; sorry for the typo!