not getting this with 1.8.3
Topic: [ANN] ccminer 2.3 - opensource - GPL (tpruvot) - page 85. (Read 500193 times)
not getting this with 1.8.3
Thanks for the efforts but would be nice to stop publishing my dev (aka unfinished) work binaries, especially in SP thread... And no, it wasn't compatible with SM 3.x
That make multiple versions with the same name in my yiimp benchs and confuse everyone. Also the stratum protocol might change before the proper one
That make multiple versions with the same name in my yiimp benchs and confuse everyone. Also the stratum protocol might change before the proper one
@minerx117
Thanks for the miner... but does this work on most pool?
it doesn't seem to work on suprnova.
Thanks for the miner... but does this work on most pool?
it doesn't seem to work on suprnova.
ccminer-equihash tpruvot source code compiled by me:
Source Code: https://github.com/tpruvot/ccminer/tree/equihash
Windows Binary: https://mega.nz/#F!hi4SUIrY!hqSSsMxCgXDJ_FjlgpDYNw
X64 Release compile from tpruvot source with vs2013 cuda 8.0 for compute 3.0-5.2
tested on gtx 1060 & 1070 100% stable no crashes
Best Regards
#Nemo
Source Code: https://github.com/tpruvot/ccminer/tree/equihash
Windows Binary: https://mega.nz/#F!hi4SUIrY!hqSSsMxCgXDJ_FjlgpDYNw
X64 Release compile from tpruvot source with vs2013 cuda 8.0 for compute 3.0-5.2
tested on gtx 1060 & 1070 100% stable no crashes
Best Regards
#Nemo
btw with the last version i get illegal memory access for JHA algo, this need to be fixed when you have time, 1.8.3 work fine for this old algo
ive enough work with the "compatible" ones
Figured you'd want to expand your earnings at some point. On occasion martian soil has rarer and more sought after elements.
YiiMP is only compatible with the bitcoin RPC, so stop asking me about all the martians support
Epsylon have you considered putting up a SIA pool? There is only one really decent SIA pool currently (few alternatives, but they all suck).
I'm pretty sure I asked about Pascal before and you said it's a turd, which it is, but something else to consider.
I'm pretty sure I asked about Pascal before and you said it's a turd, which it is, but something else to consider.
BitCore block 1926 and 1927 only got 0.25 coins.
I have checked payment, another 12.25 coins send to this address 15AQndHnBmgD8ZmiQVwQRw2pbEKci5yoRs (12.25)
Why? Can someone explain this?
In my opinion, there are many people involved in creating new block, coin divided by the contribution of each person. Do you participate in any group?I have checked payment, another 12.25 coins send to this address 15AQndHnBmgD8ZmiQVwQRw2pbEKci5yoRs (12.25)
Why? Can someone explain this?
Arguably over the course of many years this has been discussed, how much small miners actually matter. When it comes down to it 'dust' hashrate does almost nothing and will almost never receive a block (borderline nill), however they eat profits off of larger miners. Mainly larger rigs with more hashing power. A pool could actually graph this and figure out if the lower 10% of the contributors are actually contributing 10% of the findings. My guess is that's a 'no'.
I know it's not a popular answer, but extremely small miners don't actually do anything useful for a pool. I've been on other pools where they 'weight' your earnings according to some made up system which gives larger rewards to larger miners. I'm still not certain if something like this is fair from a 'doing the right thing' standpoint, but it is from a economical standpoint. You actually get rewarded for work that actually yields rewards rather then your 'contributions' which never amount to anything.
There are tons of different systems, that was popular for Burst mining. Not sure if it's still done that way today. There were a few different types of pools for mining that.
i wrote the stratum (its open source) i know a few pools using yiimp now
https://github.com/tpruvot/yiimp/commit/cf9a3b75bdfc00eb892d617537d74852e3070d31
https://github.com/tpruvot/yiimp/commit/cf9a3b75bdfc00eb892d617537d74852e3070d31
BitCore block 1926 and 1927 only got 0.25 coins.
I have checked payment, another 12.25 coins send to this address 15AQndHnBmgD8ZmiQVwQRw2pbEKci5yoRs (12.25)
Why? Can someone explain this?
In my opinion, there are many people involved in creating new block, coin divided by the contribution of each person. Do you participate in any group? I have checked payment, another 12.25 coins send to this address 15AQndHnBmgD8ZmiQVwQRw2pbEKci5yoRs (12.25)
Why? Can someone explain this?
Thx for qucik responding...
its a small bonus coming from other pools 
not found on yiimp so
not found on yiimp so
BitCore block 1926 and 1927 only got 0.25 coins.
I have checked payment, another 12.25 coins send to this address 15AQndHnBmgD8ZmiQVwQRw2pbEKci5yoRs (12.25)
Why? Can someone explain this?
I have checked payment, another 12.25 coins send to this address 15AQndHnBmgD8ZmiQVwQRw2pbEKci5yoRs (12.25)
Why? Can someone explain this?
the ccminer bitcore crash is not a problem with the algos.
as you can see from the sources, all the expected combinations are supported.
that won't be true when/if they increase the number of permutations.
and it won't crash anyways, it would just produce invalid shares.
i think it's a thread race condition when computing the permutations.
to fix it, either use __thread variables (but that will make the same calculations for every thread) or use a mutex.
i think the same problem applies to timetravel (machinecoin) as well, but I did never see it.
if this were the real issue, then you got only invalid shares (=wrong function order -> wrong hash), and not vga crash.as you can see from the sources, all the expected combinations are supported.
that won't be true when/if they increase the number of permutations.
and it won't crash anyways, it would just produce invalid shares.
i think it's a thread race condition when computing the permutations.
to fix it, either use __thread variables (but that will make the same calculations for every thread) or use a mutex.
i think the same problem applies to timetravel (machinecoin) as well, but I did never see it.
it's not a vga crash: it's random data in the s_sequence and/or hashOrder variables, leading to crash in the cpu code.
If it crashes with only one GPU, ie one CPU thread, it's not a thread race condition.
I don't think anyone is talking about Machinecoin here SP... >>
the ccminer bitcore crash is not a problem with the algos.
as you can see from the sources, all the expected combinations are supported.
that won't be true when/if they increase the number of permutations.
and it won't crash anyways, it would just produce invalid shares.
i think it's a thread race condition when computing the permutations.
to fix it, either use __thread variables (but that will make the same calculations for every thread) or use a mutex.
i think the same problem applies to timetravel (machinecoin) as well, but I did never see it.
if this were the real issue, then you got only invalid shares (=wrong function order -> wrong hash), and not vga crash.as you can see from the sources, all the expected combinations are supported.
that won't be true when/if they increase the number of permutations.
and it won't crash anyways, it would just produce invalid shares.
i think it's a thread race condition when computing the permutations.
to fix it, either use __thread variables (but that will make the same calculations for every thread) or use a mutex.
i think the same problem applies to timetravel (machinecoin) as well, but I did never see it.
it's not a vga crash: it's random data in the s_sequence and/or hashOrder variables, leading to crash in the cpu code.
the ccminer bitcore crash is not a problem with the algos.
as you can see from the sources, all the expected combinations are supported.
that won't be true when/if they increase the number of permutations.
and it won't crash anyways, it would just produce invalid shares.
i think it's a thread race condition when computing the permutations.
to fix it, either use __thread variables (but that will make the same calculations for every thread) or use a mutex.
i think the same problem applies to timetravel (machinecoin) as well, but I did never see it.
if this were the real issue, then you got only invalid shares (=wrong function order -> wrong hash), and not vga crash. as you can see from the sources, all the expected combinations are supported.
that won't be true when/if they increase the number of permutations.
and it won't crash anyways, it would just produce invalid shares.
i think it's a thread race condition when computing the permutations.
to fix it, either use __thread variables (but that will make the same calculations for every thread) or use a mutex.
i think the same problem applies to timetravel (machinecoin) as well, but I did never see it.
Why waste your power on Machinecoin??...
I agree, there is better timetravel around ;-)
But I think you shouldn't post this here.
Jump to: