im using Claymore 15 and mining eth. reported hash is 825.9 and average 6hours is only 727,6mhs.

going to try TRM 0.6.0, curious about results.

Well, you're always a bit of a troll and probably some alias account for someone else, posting obscene posts removed by moderators in this thread, I know that, but I agree with both you and joblo, this can REALLY look that way. It's all about if I'm correct or not, isn't it?

We will shortly release a Ethash miner testing tool, it's just a simple open source node.js project. You will be able to run controlled long-running tests on all miners. The reason this is important is that the displayed hashrates of Claymore and Phoenix are just bullshit. They both add +1.5% or more of fake hashrate. I don't ask anyone to buy these claims without being able to verify it themselves though, which is why we'll release the tool (which acts as a low diff fake pool with a static epoch and controlled job update mechanism) and everyone can see for themselves if they are willing to mine air for ~24h. To verify that we're not insane, we've also reverse engineered both miners, analysed their kernels, traced their OpenCL enqueue calls, and the evidence is clear.

Plenty of people have already pointed this out just by logging all shares over time, but it's really hard to prove anything. You need controlled runs of (preferably) 1 million shares, which is more or less impossible without controlling the environment properly. Another simple way is just to find a big farm from e.g. the frontpage of ethermine.org (found blocks) and check the difference between their reported and accepted hashrate.

Here is one example: https://ethermine.org/miners/6F714AaAAF72977267601cC1cADC49fb3966Ff89/dashboard

Reported: 3.206 TH/s, Accepted: 3.111 TH/s, difference -2.97%. I'm fairly certain this is Phoenix miner. Why do we have a diff of -3%? The dev fee is 0.65%, and there are 1% stale shares, and this is a HUGE sample set that should converge nicely. Contrary to what people seem to believe, the additional -1.35% just should _not_ disappear. For comparison, here is a run using our soon-to-be-released testing tool for 247k shares on Phoenix 4.7c:


Look at that, a diff of -2.94% between the reported and accepted hashrate, what a coincidence? To be fair though, 247k shares is only good for a +-0.5% estimate at 99% confidence, so we must treat the value accordingly. The point is that neither CM nor PM can never ever produce a poolside hashrate over time that matches their displayed hashrates.

Sorry for a long rant to your simple question, the bigger point I'm trying to make is this: unless miners start accepting that CM and PM are bullshitting their displayed hashrates, "comparing" CM/PM/TRM/Ethminer is pointless, you'll just be stating that CM and PM are much better than what they really are.

Depends on the card and tuning (also the OS you're running on), but ballpark range is 0.5 to 0.6 g/s.

I have almost same problem. My rig was worked fine about 1week. Later something went wrong... I started search why my pc don't see only 6gpu of 7. Started to check cables, and found that cable which goes from psu to riser burned one contactor of six. Ok I thought maybe it's because I using cable for more then one year. I plug it to other psu place and turned on with -starp 1. Again my rig started work well but only about one hour and again it started to restart and again one gpu lost. Again checked cable and again same problem. Then I tried again to change in psu cable place and turned on rig without -strap function and currently everything is ok. I am not sure but I think something not so good with that -strap function. My rig working on two psu  which is corsair RM850X. Have someone same issue?

Thank a lot!

i found a bug in your miner ...  https://imgur.com/a/k5Nw9k3 and he still staying like this , i have to go to the rig and reset manually ...

Well, it should really only happen when we restart our servers, which isn't often at all. So, there's something else cutting the connection for you. In some cases there are home routers that cut connections, in other cases many countries/jurisdictions don't like neither SSL traffic nor mining traffic. May I ask where you're located? You can PM me if you want to. Also, I'd love to know what version of TRM you're running? We have noticed a higher degree of short-lived inbound connections lately, but can't explain why.

Dev pool connection was closed due to an error.
Mining will proceed at reduced rate while not connected to dev pool.

Dev pool connected and ready.

Phoenix linux:
Claymore linux:
Are you still sure Claymore is faster?

On my asrock h110, win10 home, 8x rx580 nitro+ 8gb I am running the following config for 14.6

cclock 1150, mclock 2200, cvddc 850 mvddc 875 rxboost 1

The above works correctly and go from 30.5mh to 31.5mh

Trying the straps 0,1...7 @2200 just crashes the rig

They are all hynix except 1 is micron

Any suggestions on what to try to stop the crashing?

I.tried just strap 1,with the same crashing

May be, just add a BIG RED WARNING at the start of the miner if any Intel is detected?

WOW JCE !

From 032q to 033b7 here is the diff in the hashrate stats :

RIG1 (6x RX580 8gb gigabyte) : 6400 to 6900 !!!
RIG2 (6x RX580 8gb sapphire) : 6700 to 7300 !!!

I use 2 thread with 880 multi hash each thread.

Thanks for info. You use high memory voltage - 890 mV... I use 825-850 mV for clocks near 2000MHz...
Can you share your hynix memory strap from doctor83?

Maybe you're right. I have 1803 Windows 10 and 18.11.2 drivers... Still playing with GPU voltages to check...

Or maybe your cards have good samsung memory... Or maybe your memory straps better than my...
What memory type and clocks/voltages you use? What memory straps?

JCE, can drivers affect that way?