 Show Posts
|
|
Pages: [1]
|
7*R9 390
With claymore 221 Mh
With this miner 218 Mh
Interesting, is that a measured hash rate, or the reported hash rate? There are two possibilities for this difference 1. I messed up the launch params on hawaii archs, in which case you may be able to fix it with where k is some value > 0, and is 8 by default. 2. There's too much variance in the reported hashrate, and it needs to be averaged by the miner over a longer period of time (which I'll probably add in the next release, because my reported rates are all over the place sometimes too.) I try -eint from 0 to 8 <8 drops hashrate. This miner reported hash, pool average hash `same as claymore. (Sorry for bad english) Try higher than 8. Maybe 9. Looks like my reporting is slightly off, will try to fix in next release. It's thirty seconds for every hour which is 0.84% fees.
Yes, which can be turned off completely (see the releases page). It's also not present if you build from source code. |
|
|
|
7*R9 390
With claymore 221 Mh
With this miner 218 Mh
Interesting, is that a measured hash rate, or the reported hash rate? There are two possibilities for this difference 1. I messed up the launch params on hawaii archs, in which case you may be able to fix it with where k is some value > 0, and is 8 by default. 2. There's too much variance in the reported hashrate, and it needs to be averaged by the miner over a longer period of time (which I'll probably add in the next release, because my reported rates are all over the place sometimes too.) |
|
|
|
Tested on XFX RX 570 4GB.
27.1 mh/s with this miner
27.0 with Claymore
Nice work!!!
Thanks
Thanks, Although you should be wary of the reported hash rate -- I really should average it over a longer period of time. Check your pool's stats and see if you're getting a benefit (I believe you should be getting approx +1% in the measured rate, but you shouldn't take my word for it, you should definitely verify for yourself.) |
|
|
|
Requires too many .dlls to run on out of date win 8.1
If you need, you can recompile to run on windows 8.1. |
|
|
|
it doesnt submit reported hashrate on ethermine.  Unfortunately, this wasn't a feature of ethminer, and I didn't add it into this version. I may add it in future releases though. |
|
|
|
Tried this miner on GCN1.0 cards. Speed of ether mining is the same as in Claymore's Dual Miner solo mode. Maybe some 1-2% difference...
Good job!
Thanks man : ) Do you mind telling me which cards in specific? |
|
|
|
So for reasons I can't fully disclose, I've ported the kernels from Claymore's miner into Genoil's miner. For us, this is a boon because it allows us to verify and rebuild the miner source (it makes its way into projects around here, so this is super useful) and validate its speed. I'm not allowed to talk about what it is I'm doing, but I do have permission to release the code (it's based off of an open source project), so I've created a new repo with this code: https://github.com/goobur/ethminer-cmRead the release notes for details. Generally, for all of our RX 580's we get performance increases on par with Claymore's miner. Although we don't have a whole array of other cards to test on, so your mileage may vary on other AMD cards, right now it seems that Ellesmere, Baffin, Pitcarin and Tahiti cards are working for sure. Also, we don't have any NVIDIA cards, (well, not enough to target them) so the CUDA kernels in this release are the same as vanilla Genoil's kernels. Also, I'm now onto a different task at work (we don't really care much about dual mining). But I'm pretty fond of this project and I'd like to keep working on it -- specifically I'd like to add dual mining (which I know how to do, but would take some time). I'm just unsure which dual coin I should add first. So in order to decide, I'll let people vote via donations : ) To vote for SIA in the next release Address: 0x54F290f884e561953478Cc6220655DD5591bD87a For DECRED Address: 0xc839E9BcE73408786bEC9b460451C1d6795F8e3F For PASCAL Address: 0xb9236bE9320127590d335C633d540e75ba8d1547 For LBRY Address: 0x52d1e9FB9908b14911FD8bE03E078a3fac0DF2a8 I do want to keep working on this, but it's hard to without any incentive. If you don't want to donate, I definitely understand and I still want you to use this software (and any further releases) for free. : ) Cheers! |
|
|
|
I checked my logs and everything and "nofee 1" actually produces less shares than devmining enabled. So its actually is hashing slower.
This was for ZEC 12.5
Cool, thanks for letting me know. What card(s) are you using? I've only looked at the 9.8 Dual Eth miner so I have no reason to believe that the ZEC miner has the same behaviour. I'll probably tear into the ZEC miner binary at some point too. ZEC 12.5 with old GPUs like 7970/280x Thanks, that'll be useful information to have when I disassemble the ZEC miner. |
|
|
|
I checked my logs and everything and "nofee 1" actually produces less shares than devmining enabled. So its actually is hashing slower.
This was for ZEC 12.5
Cool, thanks for letting me know. What card(s) are you using? I've only looked at the 9.8 Dual Eth miner so I have no reason to believe that the ZEC miner has the same behaviour. I'll probably tear into the ZEC miner binary at some point too. |
|
|
|
I'm stubborn and don't really want to switch pools rn, but I will after my next payout. However my daily earning has increased on Dwarfpool since I switched the developer fee off (funny enough by about 2-3%) which, to me, is almost enough evidence to support my claim. I'd need a longer run of time to be more confident about those results tho. |
|
|
|
So recently I've been pretty skeptical of Claymore's miner so I started pulling it apart a little. From what I see, it looks like -nofee 1 actually doesn't disable anything, but rather just cuts down on the reported hash rate. i.e, the hash rate reported to the user is: reported_hashrate = calculated_hashrate;
if(nofee) {
reported_hashrate = (calculated_hashrate *97)/100;
}
Has anyone else noticed or measured this? Also, considering the hash rate calculation doesnt factor in the devfee time to its calculation, that means devfee mining is over-reporting its hash rate. In summary nofee 1 mode under reports the hash rate, and and nofee more 0 over reports it, which is pretty manipulative imo. At least thats what the code suggests like, has anyone measured the effect of nofee mode? I would guess that you'd probably get an increase in calculated hash rate on your pool stats with nofee 1. Is this ZEC or ETH miner? How did you get a piece of his source code? The weird thing about the "no fee 1" is that my temps are identical pretty much with or without the fee. So I don't know whether he actually disables some optimizations or he is just displaying a slightly slower speed so people don't run "no fee 1". Its difficult to calculate this due to variance and that his speed decrease is very negligible. My bad, I mean the Dual ETH miner, suspect the same for the ZEC miner tho, but don't have any evidence to back it. I don't have his source code, but I did unpack and "decrypt" his binaries which allowed me to disassemble them in IDA and reconstruct some C psuedo code. I've also been looking at the OpenCl kernels, which is a bit more tricky because there's a version for when asm mode is turned on. I've mostly been looking at the generic asm mode 0 binary, which is pretty much Genoils code verbatim + another miner (often taken from a fork of sg-miner). I'm not so sure about the asm 1 versions, I'll look into those later at some point tho. Honestly, from the past 24 hours, my number of accepted shares seems to be slightly higher than with nofee 0. I'm using dwarfpool tho, so the stats view is notably pretty shitty. |
|
|
|
So recently I've been pretty skeptical of Claymore's Dual ETH miner so I started pulling it apart a little. From what I see, it looks like -nofee 1 actually doesn't disable anything, but rather just cuts down on the reported hash rate. i.e, the hash rate reported to the user is: reported_hashrate = calculated_hashrate;
if(nofee) {
reported_hashrate = (calculated_hashrate *97)/100;
}
Has anyone else noticed or measured this? Also, considering the hash rate calculation doesnt factor in the devfee time to its calculation, that means devfee mining is over-reporting its hash rate. In summary nofee 1 mode under reports the hash rate, and and nofee more 0 over reports it, which is pretty manipulative imo. At least thats what the code suggests like, has anyone measured the effect of nofee mode? I would guess that you'd probably get an increase in calculated hash rate on your pool stats with nofee 1. |
|
|
|
|
