So one vote for decred and one for sia so far. At any rate, decr and sia will be the first two supported secondary coins for dual mining, probably in this order,
Your best bet for getting people to use it more, would be adding a secondary algo that isn't already covered by Claymore |
|
|
|
looks like there is a regression in 3.7.8: 4way lyra2z started throwing low difficulty shares error aes-avx2 works fine, and 3.7.7 4way worked fine [2018-01-04 15:17:07] 4 miner threads started, using 'lyra2z' algorithm.
[2018-01-04 15:17:07] Starting Stratum on stratum+tcp://europe.lyra2z-hub.miningpoolhub.com:17025
[2018-01-04 15:17:08] Stratum difficulty set to 5
found 2
[2018-01-04 15:33:44] 4 WAY hash nonces submitted: 1
[2018-01-04 15:33:44] Rejected 1/1 (100.0%), 17.73 MH, 370.84 kH/s
[2018-01-04 15:33:44] reject reason: low difficulty share of 6.130744886502982e-8
[2018-01-04 15:33:44] factor reduced to : 0.67
|
|
|
|
It's my turm to ask fr help. I'm fine tuning the new Windows crposs compile environment and I'd like to remove one ugly workaround, editting configure.ac. This code should properly link pthreadGC2 when cross compiling: # GC2 for GNU static
if test "x$OS" = "xWindows_NT" ; then
# MinGW
AC_CHECK_LIB([pthread], [pthread_create], PTHREAD_LIBS="-lpthreadGC2",[])
else
AC_CHECK_LIB([pthread], [pthread_create], PTHREAD_LIBS="-lpthread",[])
fi
but the procedure requires the following edit: # GC2 for GNU static
if test "x$OS" = "xWindows_NT" ; then
# MinGW
AC_CHECK_LIB([pthread], [pthread_create], PTHREAD_LIBS="-lpthreadGC2",[])
else
AC_CHECK_LIB([pthread], [pthread_create], PTHREAD_LIBS="-lpthreadGC2",[])
fi suggesting the logic isn't working. Any suggestions to make the logic work? perhaps moving it to the case clause starting on line 45? |
|
|
|
I tried exploring the old coins from 2013 no luck. I ran pywallet to see what kind of name and version numbers I get. All I got was
],
"minversion": 60000,
"mkey": {},
"names": {
"ALUMnWGxXWFcQp9T76fT75iCKv4sTVDjfb": ""
},
Does anybody recognize ALUMnWGxXWFcQp9T76fT75iCKv4sTVDjfb as an address of any coin?
if you try to decode it on http://lenschulwitz.com/base58you will see that the first 2 digits are 17, which are "coin version" according to a table here: https://bitcoin.stackexchange.com/questions/19589/how-to-determine-what-type-of-coins-a-wallet-dat-contains/2941317 is Primecoin checking Primecoin explorer shows no activity on that specific address, but you can try to download the wallet and rescan If you get rich, let me know ^^ |
|
|
|
Hi,
A very stupid question indeed but need to know:
I have a ETH wallet created from geth.
I started mining with nanopool.
Then I decide to stop nanopool and start with ethermine. By mining both pools (at one time) some coins (fraction of coin) will be generated.
I want to know is there are way I can check consolidated balance of generated ETH (nanopool + ethermine).
Thanking you in anticipation and looking forward.
Regards,
Rizwan
When you mine on a pool, you actually mine to a pool's wallet and they internally register your shares to your wallet. Once you reach payout minimum and request the payment, only then your balance will be transfered to your wallet. If you didn't reach the minimum on nanopool, you will not receive what you mined there to your wallet. |
|
|
|
Can anybody tell some thing about L2/L3 cache usage? E.g., I got a 16-core CPU, it has 16Mb L2 and 16Mb L3. So, if the thread count and cpuminer-opt option "--cpu-affinity" are both set correctly, will the (e.g. cryptonight - 2Mb per thread) faster L2 cache be used instead of L3? Or the L2 size does not affect?
L2 cache is faster than L3 and holds core specific cache which prevents from other cores overriding that cache every time. L3 is shared among the cores and is slightly slower. Theoretically, with 16MB of L2 cache, 8 threads will provide the highest hash rate. I'm not sure how much exactly L3 cache will benefit, but it will definitely speed up memory read operations |
|
|
|
Hi! I have a 7820x, running the cpuminer-aes-avx2. How frequently should i be getting shares? [2017-12-21 16:10:38] Starting Stratum on stratum+tcp://europe.lyra2z-hub.miningpoolhub.com:17025
[2017-12-21 16:10:38] 16 miner threads started, using 'lyra2z' algorithm.
[2017-12-21 16:10:39] Stratum difficulty set to 5.25
[2017-12-21 16:10:40] CPU #5: 65.54 kH, 84.80 kH/s
[2017-12-21 16:10:40] CPU #11: 65.54 kH, 84.09 kH/s
[2017-12-21 16:10:40] CPU #6: 65.54 kH, 83.93 kH/s
[2017-12-21 16:10:40] CPU #7: 65.54 kH, 83.82 kH/s
[2017-12-21 16:10:40] CPU #1: 65.54 kH, 83.44 kH/s
[2017-12-21 16:10:40] CPU #3: 65.54 kH, 83.23 kH/s
[2017-12-21 16:10:40] CPU #15: 65.54 kH, 82.29 kH/s
[2017-12-21 16:10:40] CPU #14: 65.54 kH, 80.57 kH/s
[2017-12-21 16:10:40] CPU #13: 65.54 kH, 77.32 kH/s
[2017-12-21 16:10:40] CPU #2: 65.54 kH, 76.42 kH/s
[2017-12-21 16:10:40] CPU #4: 65.54 kH, 76.15 kH/s
[2017-12-21 16:10:40] CPU #9: 65.54 kH, 75.80 kH/s
[2017-12-21 16:10:40] CPU #8: 65.54 kH, 75.62 kH/s
[2017-12-21 16:10:40] CPU #12: 65.54 kH, 68.49 kH/s
[2017-12-21 16:10:40] CPU #10: 65.54 kH, 71.25 kH/s
[2017-12-21 16:10:40] CPU #0: 65.54 kH, 59.62 kH/s
[2017-12-21 16:11:30] CPU #0: 3577.25 kH, 71.30 kH/s
[2017-12-21 16:11:31] CPU #10: 4275.30 kH, 83.62 kH/s
[2017-12-21 16:11:35] CPU #13: 4639.47 kH, 83.58 kH/s
[2017-12-21 16:11:37] Stratum difficulty set to 5
[2017-12-21 16:11:37] CPU #12: 4109.55 kH, 72.35 kH/s
[2017-12-21 16:11:37] CPU #9: 4548.01 kH, 79.79 kH/s
[2017-12-21 16:11:37] CPU #2: 4585.23 kH, 80.09 kH/s
[2017-12-21 16:11:37] CPU #15: 4937.36 kH, 85.86 kH/s
[2017-12-21 16:11:37] CPU #3: 4993.95 kH, 86.68 kH/s
[2017-12-21 16:11:38] CPU #1: 5006.67 kH, 86.68 kH/s
[2017-12-21 16:11:38] CPU #7: 5029.18 kH, 86.32 kH/s
[2017-12-21 16:11:38] CPU #4: 4569.20 kH, 78.45 kH/s
[2017-12-21 16:11:39] CPU #6: 5035.64 kH, 85.53 kH/s
[2017-12-21 16:11:39] CPU #5: 5087.90 kH, 85.89 kH/s
[2017-12-21 16:11:40] CPU #14: 4833.91 kH, 81.01 kH/s
[2017-12-21 16:11:41] CPU #11: 5045.35 kH, 82.70 kH/s
[2017-12-21 16:11:41] CPU #8: 4537.48 kH, 74.38 kH/s
[2017-12-21 16:12:30] CPU #0: 4278.13 kH, 71.76 kH/s
[2017-12-21 16:12:37] CPU #9: 4787.25 kH, 79.32 kH/s
[2017-12-21 16:12:38] CPU #2: 4805.56 kH, 79.20 kH/s
[2017-12-21 16:12:38] CPU #3: 5200.94 kH, 86.02 kH/s
[2017-12-21 16:12:38] CPU #7: 5179.36 kH, 86.31 kH/s
[2017-12-21 16:12:38] CPU #13: 5014.52 kH, 79.68 kH/s
[2017-12-21 16:12:39] CPU #15: 5151.78 kH, 84.08 kH/s
[2017-12-21 16:12:39] CPU #1: 5200.98 kH, 84.64 kH/s
[2017-12-21 16:12:39] CPU #6: 5131.52 kH, 84.98 kH/s
[2017-12-21 16:12:39] CPU #11: 4961.90 kH, 85.15 kH/s
[2017-12-21 16:12:39] CPU #5: 5153.53 kH, 85.32 kH/s
[2017-12-21 16:12:40] CPU #8: 4462.65 kH, 75.75 kH/s
[2017-12-21 16:12:40] CPU #4: 4707.14 kH, 75.73 kH/s
[2017-12-21 16:12:42] CPU #12: 4341.00 kH, 66.93 kH/s
[2017-12-21 16:12:42] CPU #14: 4860.43 kH, 77.34 kH/s
[2017-12-21 16:12:45] CPU #10: 5017.19 kH, 67.61 kH/s
[2017-12-21 16:13:29] CPU #0: 4305.70 kH, 73.23 kH/s
[2017-12-21 16:13:36] CPU #13: 4780.92 kH, 82.24 kH/s
[2017-12-21 16:13:37] CPU #3: 5161.37 kH, 86.74 kH/s
[2017-12-21 16:13:37] CPU #15: 5044.65 kH, 85.72 kH/s
[2017-12-21 16:13:38] CPU #2: 4752.13 kH, 79.34 kH/s
[2017-12-21 16:13:38] CPU #1: 5078.11 kH, 86.35 kH/s
[2017-12-21 16:13:38] CPU #10: 4056.34 kH, 77.22 kH/s
[2017-12-21 16:13:38] CPU #7: 5178.68 kH, 86.25 kH/s
[2017-12-21 16:13:39] CPU #9: 4759.43 kH, 77.37 kH/s
[2017-12-21 16:13:39] CPU #12: 4015.68 kH, 70.24 kH/s
[2017-12-21 16:13:39] CPU #6: 5098.65 kH, 85.15 kH/s
[2017-12-21 16:13:39] CPU #4: 4544.05 kH, 77.24 kH/s
[2017-12-21 16:13:39] CPU #5: 5118.91 kH, 85.77 kH/s
[2017-12-21 16:13:40] CPU #14: 4640.67 kH, 80.69 kH/s
[2017-12-21 16:13:41] CPU #3: 330.72 kH, 87.31 kH/s
[2017-12-21 16:13:41] Accepted 1/1 (100%), 71.13 MH, 1295.03 kH/s
[2017-12-21 16:13:43] CPU #11: 5109.20 kH, 79.99 kH/s
[2017-12-21 16:13:44] CPU #8: 4544.92 kH, 70.66 kH/s
[2017-12-21 16:14:25] CPU #10: 3965.49 kH, 83.67 kH/s
[2017-12-21 16:14:26] Accepted 2/2 (100%), 71.27 MH, 1291.23 kH/s
[2017-12-21 16:14:30] CPU #0: 4393.88 kH, 71.95 kH/s
[2017-12-21 16:14:36] CPU #13: 4934.42 kH, 82.94 kH/s
[2017-12-21 16:14:36] CPU #9: 4642.40 kH, 80.83 kH/s
[2017-12-21 16:14:37] CPU #15: 5143.28 kH, 85.80 kH/s
[2017-12-21 16:14:38] CPU #2: 4760.36 kH, 79.54 kH/s
[2017-12-21 16:14:38] CPU #7: 5175.09 kH, 86.71 kH/s
[2017-12-21 16:14:38] CPU #1: 5181.28 kH, 85.80 kH/s
[2017-12-21 16:14:39] CPU #6: 5108.85 kH, 85.45 kH/s
[2017-12-21 16:14:39] CPU #5: 5146.04 kH, 85.61 kH/s
[2017-12-21 16:14:40] CPU #4: 4634.46 kH, 76.42 kH/s
[2017-12-21 16:14:40] CPU #14: 4841.69 kH, 80.24 kH/s
[2017-12-21 16:14:41] CPU #11: 4799.43 kH, 82.87 kH/s
[2017-12-21 16:14:42] CPU #3: 5238.40 kH, 86.59 kH/s
[2017-12-21 16:14:43] CPU #8: 4239.53 kH, 71.53 kH/s
[2017-12-21 16:14:52] CPU #12: 4214.46 kH, 57.41 kH/s
[2017-12-21 16:15:25] CPU #10: 5020.03 kH, 83.90 kH/s
[2017-12-21 16:15:32] CPU #0: 4316.83 kH, 69.57 kH/s
[2017-12-21 16:15:36] CPU #13: 4976.62 kH, 82.28 kH/s
[2017-12-21 16:15:37] CPU #9: 4849.66 kH, 80.38 kH/s
[2017-12-21 16:15:37] CPU #2: 4772.59 kH, 80.22 kH/s
[2017-12-21 16:15:37] CPU #4: 4585.38 kH, 79.91 kH/s
[2017-12-21 16:15:37] CPU #1: 5147.76 kH, 86.96 kH/s
[2017-12-21 16:15:38] CPU #15: 5148.22 kH, 85.20 kH/s
[2017-12-21 16:15:38] CPU #7: 5202.51 kH, 86.35 kH/s
[2017-12-21 16:15:39] CPU #8: 4291.55 kH, 77.85 kH/s
[2017-12-21 16:15:39] CPU #6: 5127.22 kH, 85.67 kH/s
[2017-12-21 16:15:40] CPU #5: 5136.80 kH, 85.15 kH/s
[2017-12-21 16:15:40] CPU #11: 4972.19 kH, 83.73 kH/s
[2017-12-21 16:15:41] CPU #12: 3444.66 kH, 70.74 kH/s
[2017-12-21 16:15:41] CPU #14: 4814.44 kH, 79.10 kH/s
[2017-12-21 16:15:42] CPU #3: 5195.11 kH, 86.75 kH/s
[2017-12-21 16:16:25] CPU #10: 5034.10 kH, 83.72 kH/s
[2017-12-21 16:16:28] CPU #0: 4174.34 kH, 73.82 kH/s
[2017-12-21 16:16:37] CPU #9: 4822.97 kH, 79.99 kH/s
[2017-12-21 16:16:37] CPU #2: 4813.11 kH, 80.12 kH/s
[2017-12-21 16:16:38] CPU #1: 5217.61 kH, 86.26 kH/s
[2017-12-21 16:16:38] CPU #7: 5180.70 kH, 86.48 kH/s
[2017-12-21 16:16:39] CPU #13: 4936.59 kH, 79.50 kH/s
[2017-12-21 16:16:39] CPU #6: 5140.16 kH, 85.47 kH/s
[2017-12-21 16:16:39] CPU #5: 5109.02 kH, 85.51 kH/s
[2017-12-21 16:16:40] CPU #4: 4794.73 kH, 76.77 kH/s
[2017-12-21 16:16:41] CPU #15: 5111.75 kH, 80.96 kH/s
[2017-12-21 16:16:41] CPU #11: 5023.96 kH, 82.16 kH/s
[2017-12-21 16:16:42] CPU #3: 5205.14 kH, 86.34 kH/s
[2017-12-21 16:16:43] CPU #8: 4670.95 kH, 72.50 kH/s
[2017-12-21 16:16:45] CPU #12: 4244.44 kH, 66.24 kH/s
[2017-12-21 16:16:45] CPU #14: 4746.10 kH, 74.16 kH/s
[2017-12-21 16:17:25] CPU #10: 5023.45 kH, 84.01 kH/s
[2017-12-21 16:17:29] CPU #0: 4429.10 kH, 72.51 kH/s
[2017-12-21 16:17:36] CPU #9: 4799.67 kH, 81.03 kH/s
[2017-12-21 16:17:36] CPU #13: 4769.73 kH, 82.50 kH/s
[2017-12-21 16:17:38] CPU #2: 4807.06 kH, 79.54 kH/s
[2017-12-21 16:17:38] CPU #7: 5188.97 kH, 87.07 kH/s
[2017-12-21 16:17:38] CPU #1: 5175.43 kH, 86.54 kH/s
[2017-12-21 16:17:38] CPU #15: 4857.76 kH, 85.22 kH/s
[2017-12-21 16:17:39] CPU #5: 5130.78 kH, 85.92 kH/s
[2017-12-21 16:17:40] CPU #4: 4606.11 kH, 76.48 kH/s
[2017-12-21 16:17:40] CPU #6: 5128.05 kH, 83.24 kH/s
[2017-12-21 16:17:41] CPU #11: 4929.45 kH, 82.94 kH/s
[2017-12-21 16:17:41] CPU #14: 4449.36 kH, 79.10 kH/s
[2017-12-21 16:17:42] CPU #3: 5180.65 kH, 86.49 kH/s
[2017-12-21 16:17:43] CPU #12: 3974.14 kH, 68.53 kH/s
[2017-12-21 16:17:52] CPU #8: 4349.86 kH, 63.04 kH/s
[2017-12-21 16:18:25] CPU #10: 5040.52 kH, 83.91 kH/s
[2017-12-21 16:18:31] CPU #0: 4350.49 kH, 70.41 kH/s
[2017-12-21 16:18:36] CPU #13: 4949.95 kH, 83.19 kH/s
[2017-12-21 16:18:36] CPU #9: 4861.74 kH, 80.68 kH/s
[2017-12-21 16:18:36] CPU #7: 5224.21 kH, 88.82 kH/s
[2017-12-21 16:18:36] CPU #2: 4772.58 kH, 81.08 kH/s
[2017-12-21 16:18:37] CPU #1: 5192.42 kH, 87.51 kH/s
[2017-12-21 16:18:37] CPU #15: 5113.32 kH, 85.91 kH/s
[2017-12-21 16:18:38] CPU #4: 4589.08 kH, 78.57 kH/s
[2017-12-21 16:18:39] CPU #5: 5155.06 kH, 85.83 kH/s
[2017-12-21 16:18:40] CPU #14: 4746.14 kH, 80.74 kH/s
[2017-12-21 16:18:40] CPU #11: 4976.43 kH, 83.85 kH/s
[2017-12-21 16:18:41] CPU #8: 3782.38 kH, 77.32 kH/s
[2017-12-21 16:18:41] CPU #12: 4111.55 kH, 70.59 kH/s
[2017-12-21 16:18:42] CPU #3: 5189.48 kH, 86.51 kH/s
[2017-12-21 16:18:54] CPU #6: 4994.18 kH, 68.21 kH/s
[2017-12-21 16:19:25] CPU #10: 5034.47 kH, 84.04 kH/s
[2017-12-21 16:19:28] CPU #0: 4224.42 kH, 73.89 kH/s
[2017-12-21 16:19:32] CPU #1: 4835.62 kH, 87.71 kH/s
[2017-12-21 16:19:32] Accepted 3/3 (100%), 76.56 MH, 1296.93 kH/s
[2017-12-21 16:19:35] CPU #13: 4991.49 kH, 84.45 kH/s
[2017-12-21 16:19:36] CPU #9: 4840.61 kH, 80.64 kH/s
[2017-12-21 16:19:37] CPU #11: 5031.19 kH, 89.15 kH/s
[2017-12-21 16:19:37] CPU #2: 4864.53 kH, 80.76 kH/s
[2017-12-21 16:19:37] CPU #7: 5329.22 kH, 88.15 kH/s
[2017-12-21 16:19:37] CPU #12: 4235.44 kH, 76.14 kH/s
[2017-12-21 16:19:37] CPU #15: 5154.50 kH, 85.88 kH/s
[2017-12-21 16:19:38] CPU #4: 4714.09 kH, 79.47 kH/s
[2017-12-21 16:19:38] CPU #8: 4639.41 kH, 81.19 kH/s
[2017-12-21 16:19:39] CPU #14: 4844.45 kH, 82.46 kH/s
[2017-12-21 16:19:39] CPU #5: 5149.92 kH, 86.03 kH/s
[2017-12-21 16:19:40] CPU #6: 4092.42 kH, 88.06 kH/s
[2017-12-21 16:19:40] CPU #3: 5190.38 kH, 88.69 kH/s
[2017-12-21 16:39:31] lyra2z block 66360, diff 19586.650
[2017-12-21 16:39:31] CPU #11: 4566 H, 71.83 kH/s
[2017-12-21 16:39:31] CPU #5: 70 H, 69.79 kH/s
[2017-12-21 16:39:31] CPU #2: 4573 H, 71.94 kH/s
[2017-12-21 16:39:31] CPU #15: 3428 H, 56.61 kH/s
[2017-12-21 16:39:31] CPU #14: 3218 H, 60.11 kH/s
[2017-12-21 16:39:31] CPU #8: 3386 H, 58.84 kH/s
[2017-12-21 16:39:31] CPU #7: 4212 H, 67.33 kH/s
[2017-12-21 16:39:31] CPU #3: 5190.38 kH, 88.69 kH/s
[2017-12-21 16:39:31] CPU #12: 4483 H, 74.03 kH/s
[2017-12-21 16:39:31] CPU #4: 4359 H, 73.20 kH/s
[2017-12-21 16:39:31] CPU #9: 3465 H, 54.51 kH/s
[2017-12-21 16:39:31] CPU #6: 61 H, 60.82 kH/s
[2017-12-21 16:39:31] lyra2z block 66361, diff 19586.650
[2017-12-21 16:39:31] CPU #12: 121 H, 120.52 kH/s
[2017-12-21 16:39:31] CPU #15: 234 H, 93.34 kH/s
[2017-12-21 16:39:31] CPU #7: 227 H, 113.22 kH/s
[2017-12-21 16:39:31] CPU #8: 224 H, 111.72 kH/s
[2017-12-21 16:39:31] CPU #4: 71 H, 70.72 kH/s
[2017-12-21 16:39:31] CPU #3: 158 H, 78.80 kH/s
[2017-12-21 16:39:31] CPU #5: 333 H, 110.74 kH/s
[2017-12-21 16:39:31] CPU #9: 62 H, 123.26 kH/s
[2017-12-21 16:39:31] CPU #14: 213 H, 84.96 kH/s
[2017-12-21 16:39:31] CPU #11: 391 H, 111.36 kH/s
[2017-12-21 16:39:31] CPU #6: 61 H, 60.82 kH/s
[2017-12-21 16:39:31] CPU #2: 274 H, 91.12 kH/s
[2017-12-21 16:40:14] CPU #6: 3649.05 kH, 84.96 kH/s
[2017-12-21 16:40:25] CPU #3: 4728.18 kH, 86.29 kH/s
[2017-12-21 16:40:26] CPU #4: 4243.03 kH, 77.01 kH/s
[2017-12-21 16:40:33] CPU #0: 4433.56 kH, 72.43 kH/s
[2017-12-21 16:40:33] CPU #1: 5262.38 kH, 85.90 kH/s
[2017-12-21 16:40:33] CPU #13: 5067.18 kH, 82.57 kH/s
[2017-12-21 16:40:34] CPU #14: 5097.73 kH, 80.89 kH/s
[2017-12-21 16:40:36] CPU #15: 5600.32 kH, 85.75 kH/s
[2017-12-21 16:40:39] CPU #2: 5467.24 kH, 79.73 kH/s
[2017-12-21 16:40:47] CPU #10: 5042.38 kH, 66.58 kH/s
[2017-12-21 16:40:48] CPU #5: 6644.50 kH, 85.42 kH/s
[2017-12-21 16:40:50] CPU #7: 6793.02 kH, 86.06 kH/s
[2017-12-21 16:40:50] CPU #11: 6681.86 kH, 84.65 kH/s
[2017-12-21 16:40:58] CPU #8: 6703.24 kH, 76.37 kH/s
[2017-12-21 16:41:02] CPU #9: 7395.63 kH, 80.61 kH/s
[2017-12-21 16:41:07] CPU #1: 2912.99 kH, 85.90 kH/s
[2017-12-21 16:41:07] Accepted 4/4 (100%), 80.46 MH, 1335.75 kH/s
[2017-12-21 16:41:13] CPU #12: 7231.08 kH, 70.79 kH/s
[2017-12-21 16:41:13] CPU #6: 5097.58 kH, 85.87 kH/s
[2017-12-21 16:41:24] CPU #4: 4620.55 kH, 78.77 kH/s
[2017-12-21 16:41:26] CPU #3: 5177.51 kH, 85.91 kH/s
[2017-12-21 16:41:32] CPU #0: 4345.54 kH, 73.69 kH/s
[2017-12-21 16:41:34] CPU #13: 4954.33 kH, 81.55 kH/s
[2017-12-21 16:41:34] CPU #14: 4853.19 kH, 79.92 kH/s
[2017-12-21 16:41:36] CPU #15: 5145.03 kH, 85.10 kH/s
[2017-12-21 16:41:39] CPU #2: 4784.08 kH, 79.61 kH/s
[2017-12-21 16:41:48] CPU #5: 5125.20 kH, 86.47 kH/s
[2017-12-21 16:41:49] CPU #7: 5163.88 kH, 86.63 kH/s
[2017-12-21 16:41:50] CPU #11: 5079.28 kH, 84.72 kH/s
[2017-12-21 16:41:52] CPU #10: 3994.79 kH, 62.27 kH/s
[2017-12-21 16:41:58] CPU #8: 4582.12 kH, 76.62 kH/s
[2017-12-21 16:42:03] CPU #9: 4836.49 kH, 79.81 kH/s
[2017-12-21 16:42:06] CPU #1: 5154.29 kH, 86.65 kH/s
[2017-12-21 16:42:11] CPU #12: 4247.53 kH, 73.07 kH/s
[2017-12-21 16:42:13] CPU #6: 5152.45 kH, 85.64 kH/s
[2017-12-21 16:42:24] CPU #0: 4421.37 kH, 84.97 kH/s
[2017-12-21 16:42:24] CPU #4: 4725.99 kH, 79.42 kH/s
[2017-12-21 16:42:25] CPU #3: 5154.60 kH, 86.89 kH/s
[2017-12-21 16:42:27] CPU #13: 4893.18 kH, 92.04 kH/s
[2017-12-21 16:42:33] CPU #14: 4795.47 kH, 82.25 kH/s
[2017-12-21 16:42:35] CPU #15: 5105.90 kH, 87.17 kH/s
[2017-12-21 16:42:35] CPU #2: 4776.40 kH, 85.23 kH/s
[2017-12-21 16:42:40] CPU #7: 5198.02 kH, 102.06 kH/s
[2017-12-21 16:42:42] CPU #5: 5188.49 kH, 96.08 kH/s
[2017-12-21 16:42:46] CPU #11: 5083.27 kH, 90.52 kH/s
[2017-12-21 16:42:49] CPU #10: 3736.22 kH, 64.48 kH/s
[2017-12-21 16:42:50] CPU #8: 4596.90 kH, 88.44 kH/s
[2017-12-21 16:42:56] CPU #9: 4788.59 kH, 90.80 kH/s this is normal, lyra2z on mph has high starting difficulty, it gets better after some time |
|
|
|
Hey guys, anybody knows what is the hashrate of a Sapphire Nitro+ RX580 8GB on Lyra2Rev2?
The reason i'm asking is that i get 5 Mh/s which seems pretty low to me. On my 1070 i get like 30 MH/s+. Its a huge difference between both cards, is that normal?
Me too. Wondering the same thing getting 5 Mh/s using RX580 8GB. Can somebody help please ? Thanks, You can get like 8 Mh/s at most with sgminer (I'm using the nicehash version https://github.com/nicehash/sgminer/releases) with "-k lyra2rev2 -g 2 -w 64 -I 16" There is also mkxminer, but its pools support is limited https://bitcointalk.org/index.php?topic=2360168.0It can get you to 30+ |
|
|
|
Sir, where did you find this info? Cache Block diagram looks exactly like the one from sandy bridge times, everything seems to be the same as inside kaby.
Nope, the structure is the same, but the amount increased. This leads to better mining performance in cache-bound algos, and better flexibility (w/o looking at core count). E.g. on i5 8600K you may now use 2 double threads for cryptonight (2x4Mb) at around 320+ H/s and you will be able to use the rest (1Mb) for video decoding (which uses cache as well). This is good, and affects power consumption and heating (in a good way) as well. It's the same 2Mb per core on i7 and 1.5Mb per core on i5, just more cores. So no real changes |
|
|
|
So again, i made it for myself. I am seeing if there would be any value if me making it configurable and sharing with others. Software would be free, and open source. I would accept donations though.
Sounds like a useful enhancement above basic sh/BAT files. Put it up at Github. It also makes sure i finish each pplns cycle before switching as the hub itself is managing my coin switching.
This is likely to be the most useful feature, because MPH already takes care of it for you on 17xxx and 12xxxx. So if you can use that on the 20xxxx ports or other pools, it's very useful. First off it wouldn't work with other pools. Simplifying to one pool was more the goal. Using the built in system (12xxx Ports) to do the switching. My app was more about reporting and information gathering than control the switching. However as i dug deeper down the rabit whole it seems unlikely a public version is going to happen. It ended up being 3 parts. first part: Controls the mining software and has an api conversion for the miner apis. AKA all miners report the same way so i can use a universal get for miner statistics. second part: a caching proxy that provides miningpoolhub data in a easy to digest format and limits the call to the hub to avoid overload. third part: The clean nice looking front end that display everything i need to see. So with the resulting complexity i don't think i will go through the effort of making it something i can share. If someone is Serious about having it setup for themselves they can let me know and we can talk privately. It is nice to be able to see at a glance, what coin and algo i am running, as well as projected profits based on MPH Pools and off of last 24 hours profit. that sounds like megaminer, multipoolminer or awesomeminer https://bitcointalk.org/index.php?topic=2059039.0 |
|
|
|
few benchmarks on yescryptr16
3.7.7 "v1" (gcc 4.8.3)
avx - ~930 h/s
sse2 - ~ 870 h/s
3.7.7 v2 (gcc 5.3.1)
avx - ~950 h/s
sse2 - ~970 h/s
3.7.7 4ward (gcc 6.2.1)
avx - ~970 h/s
sse2 - ~960 h/s
additional algos that show better performance in sse2 than avx (although very small):
yescrypt, poltimos and lbry
This shows gcc-5.3.1 might be the issue. Is that on a Coffeelake? If not it eliminates that as a Coffeelake issue and looks purely like a compiler version issue. i5 7600k, kaby lake nothing major changed from skylake to kaby lake and to coffe lake, and skylake support was added in gcc 6, so I'm guessing it does a better job optimizing the code |
|
|
|
|
few benchmarks on yescryptr16
3.7.7 "v1" (gcc 4.8.3)
avx - ~930 h/s
sse2 - ~ 870 h/s
3.7.7 v2 (gcc 5.3.1)
avx - ~950 h/s
sse2 - ~970 h/s
3.7.7 4ward (gcc 6.2.1)
avx - ~970 h/s
sse2 - ~960 h/s
additional algos that show better performance in sse2 than avx (although very small):
yescrypt, poltimos and lbry
|
|
|
|
Looks like there is some performance problem with yescript16 implementation on coffee-lake cpus Intel i5 4440 (stock 3.3GHz) @4 threads generates ~600h/s Intel i7 5820k (no overclock, 3.6GHz) @12 threads generates ~1200h/s in pool and up to 1400 in solo mining (6 threads generate little less) with both cpuminer-opt (3.7.6 and 3.7.7v2) under windows64 and under ubuntu64 Intel i7 8700k (stock 4.3GHz) @12 threads generates only 950h/s (both pool and solo), overclocking to 5Ghz (50x100) with cache overclock to 4.6Ghz (stock is 4.2) gives no profit, even more usually performance degrade (power limit disabled, core temperatures are ~75C so no throttling involved), 1-2-3-4-5-6 threads gives less results, overclocking bus to 130Mhz (also with ram) gives no result - maximum is about 950h/s Even more funny - on stock frequency, switching from AVX to SSE2 gives some performance boost from 950 to 1000-1050h/s I understand that 8700k lacks quad-channel RAM and has little bit less L3 cache (12 vs 15Mb), compared to 5820, but bottleneck is obviously something different because ram overclock gives no result (so double channel is not a problem, we should see performance boost when overclocking bus and ram) and cache is also not a problem (25% cache is gone but we gain >30% frequency bonus (when overclocked) so our smaller cache works at higher speeds together with cpu cores - we can put less but more frequent and calc it in less time - ) also, compared to 4440, if cache was a bottleneck, we have twice more (12 vs 6Mb), taking in mind much higher speed and optimized pipelane, if cache only matters, we should have 2x gain, compared to 4440 I hope for a fix  I think it's definitely not normal, You should be getting more. And SSE2 really is faster than AVX On i5 7600k @4.5Ghz I get ~920 H/s on AVX and ~950 on SSE2 (!) |
|
|
|
This is why I also have 2FA disabled on coin exchanges. A friend, just a couple of days ago, broke his phone and can no longer access the coins held on an exchange...I did warn him. use Authy instead on Google authenticator. It attaches to your phone number and you can always recover your MFAs |
|
|
|
Я чертов идиот
good idea, lets all use our native language ! NOT Some russians are so pathetic, like their dictator... pathetic loser... I blame your parents.
fcking idiot, I blame your parents.
I blame your parents
is this the famous cryptodouche club ? Filled with clueless wannabe ? Just asking...
that was both a clueless and stupid comment, well done !
for some reason a large part of your posts is filled with hate for everyone... I pity your parents |
|
|
|
Can you have payment in BCH?
I'd rent my L3+
Agree. I'm looking for BCH payout. You can get payout in any coin that is mined on the pool, provided there are enough blocks mined in that coin |
|
|
|
question , what am i missing , for example Claymore ETH only testing dual with DCR , even tho Lbry and SC are included in config file , same with Excavator , i manually added additionally Lbry to miner json , still nothing , messing with 5.0 master
p.s. since i have MPH and Yiimp on my pool list , blake2b and lbry should be available ...
have you defined wallets for Yiimp coins?, Yiimp hasn´t autoexchange to BTC, you only can mine on a pool if you has defined wallet for that coin in config.txt yep , i have defined wallets for all yiimp and mph listed coins I have tried and found Yiimp pool is "complicated" for dual mining. Decred pool is usually full It has Blake2s, but not siacoin only Neva and Tajcoin (has you wallets for that? Lbry is working well for me when I add @@Walllet_LBC siacoin = blake2b blake2s is a different algo |
|
|
|
One thing I couldn't resolve is that neoscrypt always fails to run (same in My9bot's version)
I can look into this now. -DNOASM didn't solve the issue, it still fails. But you are right, this algo is definitely not the best performer, so I don't know if its worth investing much time in it I found a potential problem that could cause data misalignment. In algo/neoscrypt.c line 56: #if (WINDOWS)
/* sizeof(unsigned long) = 4 for MinGW64 */
typedef unsigned long long ulong;
#else
typedef unsigned long ulong;
#endif
typedef unsigned int uint;
Further down in the code some data defined as uint is accessed as ulong which has stricter alignment requirements if defined as long long. If the condition is removed and ulong is the same as uint it shouldn't crash. I found no other compilation divergence and alignment bugs can slip through unnoticed for a time. The trigger seems to be the different compile environment. Can you test to confirm? tried this // #if (WINDOWS)
/* sizeof(unsigned long) = 4 for MinGW64 */
// typedef unsigned long long ulong;
// #else
typedef unsigned long ulong;
// #endif
typedef unsigned int uint; same problem, unless I'm doing it wrong ) |
|
|
|
One thing I couldn't resolve is that neoscrypt always fails to run (same in My9bot's version)
I can look into this now. I suspect the neoscrypt problem is related to its use of asm. It is controlled by a NOASM compile flag. I didn't find any hooks for Windows so it should compile the same as Linux. It works with the old mingw environment used to build previous binaries. The only obvious difference is the mingw host, The old way was built on a Windows host, the new ones cross compiled on a Linux host. I don't know if that makes any difference. Digging deeper will be very time consuming and considering neoscrypt performance on CPU it's hardly worth the effort, especially if the result is to disable ASM and performance drops. An easy test would be to recompile with -DNOASM and see if it works and how the performance compares with the old mingw build. I'll leave it up to you if you're interested. The results will help determine how to proceed. -DNOASM didn't solve the issue, it still fails. [2017-12-19 18:11:05] 4 miner threads started, using 'neoscrypt' algorithm.
[2017-12-19 18:11:05] Starting Stratum on stratum+tcp://neoscrypt.mine.zpool.ca:4233
[2017-12-19 18:11:05] Binding thread 0 to cpu 0 (mask 1)
[2017-12-19 18:11:05] Binding thread 1 to cpu 1 (mask 2)
[2017-12-19 18:11:05] Binding thread 2 to cpu 2 (mask 4)
[2017-12-19 18:11:05] Binding thread 3 to cpu 3 (mask 8)
[2017-12-19 18:11:07] Stratum session id: 67d8d8d809e8d6ce65058b9626f51cf4
[2017-12-19 18:11:07] Stratum difficulty set to 512
[2017-12-19 18:11:11] DEBUG: job_id='347' extranonce2=00000000 ntime=123a395a
[2017-12-19 18:11:11] neoscrypt block 2011810, diff 110.548
But you are right, this algo is definitely not the best performer, so I don't know if its worth investing much time in it |
|
|
|
|
Show Posts
