|
I tested bsod a few weeks ago. The opensource miners (sp-mod) seems to be finding more blocks. The fee miners have optimized the stratum code and seem to be stealing from the other miners.
|
|
|
|
hello,
Is it possible to mine X16R solo on that miner?
Not with the opensource, but you can try https://bsod.pw with -p solo in the password. 0.03334BTC / GHASH with solomining. 3-4 times more profitable than mining on the other yiimp clone pools. Did a short test with 5GHASH and got 6 blocks, around 30000 raven in 24 hours with the sp-mod.. pretty good. |
|
|
|
too high intensity?  The testcard is running with -i 19 |
|
|
|
The opensource version seems to have a bug with stale work. once in a while the miner hang with a huge delay like this. Could be a network problem, but I think my mod is configured to always send stale work. Some of the pools doesn't accept stale work and will give a penalty. Pool/stratum tuning is not important for solomining..  |
|
|
|
it's not a fact that he will be the fastest in terms of profitability in coins
Because there are faster private kernels out there that will give you a bether profit. Let's say I have a raven miner that is 20% faster than enemy 1.20. Then I deploy this miner on my xxx xxx 1080ti cards and solomine raven. Your profit ill be shreaded, and you will move to another more profitable coin. (ethereum) |
|
|
|
|
Opensource miners should be compared to opensource miners. Opensource miners will rarely be the fastest miners. I have forked the nevermore x16r miner from april 2018 and made it around 20-25% faster.
Ravencoin has a total hashrate of around 2.5THASH. The private miners have a 90% marketshare. 1% of that is around
22 500 MHASH, So the fee alone is worth 0.195 bitcoin every day (around $1300). And that's only for one coin. Ravencoin is ranked #146 on coinmarketcap sorted by the total coin supply value.
If I release a free x16r miner with bether performance, the other miner devs will loose alot of money. Thats why they come to shit in my thread.
|
|
|
|
CUfunction ASM_SIMD = NULL;
// if (LoadPtxKernel("Enemy_120_simd_32_52.ptx", &ASM_SIMD) != CUDA_SUCCESS)
if (LoadPtxKernel("cuda_x11_simd512.compute_52.ptx", &ASM_SIMD) != CUDA_SUCCESS)
{
exit(EXIT_FAILURE);
}
Competition is good for the hashrate. My fork will still be opensource, but the actual cuda work is done in the ptx assembly files compiled at runtime. The ptx files extracted from the free competition miners, modded to fit my miner. Free opensource speed boost. Without virus warnings. |
|
|
|
|
The x17 profit is declining. The noob miners move to something more profitable...
That's the difference between private kernel code and public code.
|
|
|
|
kernels from cd/t-rex/enemy.
The best from cd/t-rex/enemy kernels is only giving 28MHASH on the 1080ti (x17). So I add the profitable percent. The +10% the other guys can't copy.. |
|
|
|
|
I have found evidence of my gpl code in their work. The sourcecode is provided for free in the public exefiles released by team cryptodregde/team enemy/team-t-rex (assembly language). My miner will be opensource and under GPL. The ptx kernels will be compiled runtime and executed by my program. If they release a faster miner, I will extract the new ptx code to make sure that my opensource miner always is the fastest.
|
|
|
|
_sp and in a month write that we steal your code from you  I don't steal code. I plan use your free code in you "free" miner and release the sourcecode with it. (the Ptx assembly code). Then I won't violate the GPL licence you are violating. My miner will be faster,opensource, free and with a smaller devfee of 0.8% |
|
|
|
but for free
I have extracted all the kernels from the other devs and can soon publish a ptx opensource miner.. 30MHASH x17(asus 1080ti 90% tdp, +130 core +600 mem). 0.8% dev fee. Kernels made by t-rex/enemy/sp-mod. Thanks for the free work guys.. |
|
|
|
I don't earn any money from my opensource work, but my private bins are getting faster and faster. X16R/X17 has improved to become +30% faster in a few months thanks to optimalizations. I made the 27MHASH x17 miner first.. Here is a post from August 8th. When enemy 1.14 and t-rex 5.7 was "the fastest" Still 20% slower than Enemy?
My private is around 20% faster than (enemy 1.14)/(t-rex 5.7) in x16r/x16s/x17 27 MHASH x17 1080ti, (2BTC) |
|
|
|
Taking into consideration the fact that cards P106-090 6GB are completely specialized product intended for ETH/ETC mining
Did you try to mine a coin with a smaller dagger buffer? Musiccoin / expanse etc.. |
|
|
|
"The maximum shared memory per block remains limited at 48KB as with prior architectures".
So you need 2 blocks. |
|
|
|
Thanks - your contributions have made it easier for even a relative novice to make further modifications to the code and come out (slightly) ahead of enemy and trex, even before their fees.
Convert simd to use shared memory instead of a big memory buffer (d_temp4[thr_id]) and then you get a good speedup. this has already been done in the other private miners. I might opensource later on.. here from enemy 1.20 SIMD implementation disassembly converted to ptx enemy 1,20 is using 16kb of sharedmem ..
st.shared.u32 [%r1671], %r1666;
shfl.sync.up.b32 %r1672|%p370, %r162, %r304, %r1653, %r302;
selp.b32 %r1673, %r144, %r1672, %p92;
shfl.sync.up.b32 %r1674|%p371, %r154, %r304, %r1653, %r302;
selp.b32 %r1675, %r136, %r1674, %p92;
mul.lo.s32 %r1676, %r1673, 185;
mul.lo.s32 %r1677, %r1675, 185;
prmt.b32 %r1678, %r1676, %r1677, %r1661;
shfl.sync.idx.b32 %r1679|%p372, %r1678, %r1665, %r301, %r302;
st.shared.u32 [%r1671+4], %r1679;
shfl.sync.up.b32 %r1680|%p373, %r126, %r304, %r1653, %r302;
selp.b32 %r1681, %r108, %r1680, %p92;
shfl.sync.up.b32 %r1682|%p374, %r118, %r304, %r1653, %r302;
selp.b32 %r1683, %r100, %r1682, %p92;
mul.lo.s32 %r1684, %r1681, 185;
mul.lo.s32 %r1685, %r1683, 185;
prmt.b32 %r1686, %r1684, %r1685, %r1661;
shfl.sync.idx.b32 %r1687|%p375, %r1686, %r1665, %r301, %r302;
st.shared.u32 [%r1671+8], %r1687;
shfl.sync.up.b32 %r1688|%p376, %r1613, %r304, %r1653, %r302;
selp.b32 %r1689, %r180, %r1688, %p92;
shfl.sync.up.b32 %r1690|%p377, %r190, %r304, %r1653, %r302;
selp.b32 %r1691, %r172, %r1690, %p92;
mul.lo.s32 %r1692, %r1689, 185;
mul.lo.s32 %r1693, %r1691, 185;
prmt.b32 %r1694, %r1692, %r1693, %r1661;
shfl.sync.idx.b32 %r1695|%p378, %r1694, %r1665, %r301, %r302;
st.shared.u32 [%r1671+12], %r1695;
shfl.sync.up.b32 %r1696|%p379, %r91, %r304, %r1653, %r302;
selp.b32 %r1697, %r73, %r1696, %p92;
shfl.sync.up.b32 %r1698|%p380, %r3433, %r304, %r1653, %r302;
selp.b32 %r1699, %r3432, %r1698, %p92;
mul.lo.s32 %r1700, %r1697, 185;
mul.lo.s32 %r1701, %r1699, 185;
prmt.b32 %r1702, %r1700, %r1701, %r1661;
ld.const.u8 %r1703, [%r1664+8];
shfl.sync.idx.b32 %r1704|%p381, %r1702, %r1703, %r301, %r302;
st.shared.u32 [%r1671+128], %r1704;
...
|
|
|
|
Streebog can only fit 2 (3) copies of the tables in shared mem, unless you can compute them on fly. Did you manage to apply the "trick" to it?
The streebog opensource implementation use 8kb of shared memory. and the pascal chip has 96kb of shared memory. But you have some limitations. I see that the cryptodredge 0.9 is using 48kb shared memory. You can use more shared memory if you disable the level1 cache.. |
|
|
|
|
Pushed a 20% faster shavite_final implementation to github. Another #include "cuda_x11_aes_sp.cuh" modification...
The sp-modded Optimized AES has been applied to the following hashing functions.
echo (done)
fugue (done)
shavite (only the final function / if shavite is the last algo in the chain)
whirlpool(not done)
streborg(not done)
|
|
|
|
|
Show Posts
