Release 3.1.11 of cpuminer-opt is available for download. https://drive.google.com/file/d/0B0lVSGQYLJIZZ3VCOERfMHZiQmM/view?usp=sharingNew in 3.1.11 - hodl algo hashrate issue partially fixed. Errata: The hash rate reported at the pool should now be the same as hodlminer-wolf although the miner stilll reports an erroneously high rate. The performance chart uses the pool reported rate. - argon2 algo added, 6% faster than encel version |
|
|
|
|
I have a request regarding term deposits. It seems uncecessarilly difficult to select a
term deposit address. Term deposits require sending to oneself and use a receive address.
But the deposit tab only allows selection from send addresses. It is necessary to go to the
receive tab, copy an address to the clipboard then go back to the deposit tab to paste it.
It aseems to make more sense for the deposit tab to show receive addresses by default.
I also have a question regarding term deposit maturation. I noticed that interest tops accruing
upon maturation and it seems I would need to transfer the coin to a regular address.
I presume I could then send it back into a term deposit. However, can I roll over the TD
by sending the coin directly from the TD address back to the same TD address?
|
|
|
|
|
My theory was wrong, at least with respect to hodl. With hodl the threads work cooperatively
by spliting the scratchpad into sections with each thread searching their own section. First thread
to find it scores a collision.
I had a bug that was getting new work in every thread.
That seems to have solved the most important part of the problem, the hashrate reported at the pool.
Unfortunately it's not the same high hashrate still being reported by the miner.
I will likely build another release with this fix and continue to investigate the local hashrate display issue.
|
|
|
|
Edit: trimmed excessivley long quote.
First PC:
1-Intel Pentium dual core e5200 2.5GHz
2-Windows 7 ultimate 32x
3-I am not so technical i downloded the ,iner from cryptocurrecncy-blog? so you can find the source?
4-Command line: hodlminer -a hodl -o stratum+tcp://hodl.suprnova.cc:4693 -u peltig.1 -p x
5-I don't understand your mean.
6-I don't understand your mean.
Second PC:
1-Intel i3-3210 3.2GHz
2-Windows 7 ultimate 64x
3-I am not so technical i downloded the ,iner from cryptocurrecncy-blog? so you can find the source?
4-Command line: hodlminer -a hodl -o stratum+tcp://hodl.suprnova.cc:4693 -u peltig.1 -p x
5-I don't understand your mean.
6-I don't understand your mean.
Thank you. Neither of your CPUs has AES_NI which is a requirement to use hodlminer-wolf. You need to use the other one. I said twice there were two versions but you still failed to say which one you downloaded. |
|
|
|
|
Something is bugging me about hashrates. First I will point out that the current method the miner
reports hashrate generally agrees with the pools.
This bugs me for the simple reason that one thread finds the solution but the reported hashrate
is the sum of all threads. The hashrate is only correct when a single thread finds a solution each scan.
If all 8 threads find a solution my pool rate would be 800% what the miner reports. This explains somewhat
why the pool sometimes reports hashrates much higher than the miner.
Now to the pools. They don't know how many threads are running, they just get a solution and the number of
hashes to find it (an assumption). They look at the size of the solution and the time it took to find it and
calculate a hashrate. How in hell could the miner ever agree? I must be missing something.
I've been running for about 120 accepts calculating an average efficiency and it's running at about
7%.
That's 7% of 800% = 56%.
Miner reports 450 H/s, multiply by 56% = 252 H/s.
That should be my actual hashrate at the pool.
I think I need to let that sink in for a while. I'm getting dizzy.
|
|
|
|
I think I need to redeesign the hashrate display in order to troubleshoot the scan failures, first to quantify and compare with other miners. I've added a quick efficiency factor by simply using the inverse of the number of fails between successes. 100% means every thread is successful on every scan. The efficiency is also already indicated by the number of thread hashrate lines between shares. Here's what it looks like. [2016-04-07 17:12:20] CPU #7: 32.76 H/s
[2016-04-07 17:12:20] scan efficiency 12.50%
[2016-04-07 17:12:20] accepted: 38/38 (100%), 415.59 H/s yes!
[2016-04-07 17:12:21] CPU #0: 64.15 H/s
[2016-04-07 17:12:21] scan efficiency 100.00%
[2016-04-07 17:12:21] accepted: 39/39 (100%), 427.02 H/s yes!
[2016-04-07 17:12:22] CPU #3: 65.58 H/s
[2016-04-07 17:12:22] CPU #4: 53.58 H/s
[2016-04-07 17:12:22] CPU #2: 49.79 H/s
[2016-04-07 17:12:22] CPU #6: 53.61 H/s
[2016-04-07 17:12:22] CPU #5: 54.44 H/s
[2016-04-07 17:12:22] CPU #1: 50.27 H/s
[2016-04-07 17:12:25] CPU #2: 67.54 H/s
[2016-04-07 17:12:25] scan efficiency 14.29%
[2016-04-07 17:12:25] accepted: 40/40 (100%), 441.93 H/s yes!
[2016-04-07 17:12:27] Stratum difficulty set to 4.96669
[2016-04-07 17:12:27] CPU #6: 58.60 H/s
[2016-04-07 17:12:27] CPU #5: 58.98 H/s
[2016-04-07 17:12:27] CPU #4: 53.22 H/s
[2016-04-07 17:12:27] CPU #1: 45.70 H/s
|
|
|
|
The binaries from cryptominingblog weren't built properly, which is why you and 90% of the other HOdlers are getting this error. You can either build it yourself or wait for them to rebuild it properly  What specifically is wrong with them? I'm using hodleminer-wolf on i7-4790K and hodleminer on core2. No problems with either but I had to install openssl which was trivial. If you try to use hodlminer-wolf on a CPU without AES_NI (core2) it will crash. I don't know whats wrong with them specifically, but even installing openssl didn't solve it for most people. My guess is that they built it for a specific platform and not for a public release, which would be why it crashes on certain pc's but not on others. No one has stated which version they are using and what architecture they are using it on. They both work for me when used properly. |
|
|
|
Here's some data i colllected for hashrates [2016-04-07 14:22:25] 1 miner threads started, using 'hodl' algorithm.
[2016-04-07 14:22:28] Stratum difficulty set to 1
[2016-04-07 14:22:38] scanh start hashes done= 0
[2016-04-07 14:22:44] scanh ret 1 hashes done= 328
[2016-04-07 14:22:44] diff.tv_sec= 6 usec= 16424
[2016-04-07 14:22:44] thr rate= 54.517434
[2016-04-07 14:22:44] CPU #0: 54.52 H/s
[2016-04-07 14:22:44] accepted: 1/1 (100%), 54.52 H/s yes!
Everything adds up. This is exactly what it's getting back from the scan. The problem must be happening later with the submission. Edit: I think I have found a long standing bug. When a share is submitted the miner reports the sum of the hashrates of the last scan of each thread. That's is usually a good approximation but doesn't take into account failed scans. It also doesn't take into account super-scans where a solution is found by 2 threads at the same time. A share is submitted only when the scan returns success. Otherwise the scan was wasted time. This wasted time doesn't get measured by the miner but the pool sure notices the delay since the last submit. That appears to account for discrepency between the miner rate and the pool rate. Fixing that will take some thought. The displayed share submission rate should be the sum of all the scans since the last submission. This will cause volatility in the displayed hashrates but they will be accurate and should match the pool. The per-thread hashrate could also be improved. The display could indicate when a scan has suceeded or failed. That problem seems understood but now the issue is why so many scans fail. I'm going to try to fix that before redesigning the hashrate display. |
|
|
|
How to mine this coin? i downloaded a cpu miner from cryptocureency-blog but it got error.
I'm not sure that Windows binary was compiled as a Windows distribution binary... Wolf's cpu miner doesn't work with my I7 4790K.  It works with mine. Do you have openssl installed? Could you explain how you installed it? I couldn't with any effort. I installed it but it didn't help don't be like an early '90s mac...describe the error in detail
Sheesh, not a single one of you has taken Fuzzbawls advice. How to mine this coin? i downloaded a cpu miner from cryptocureency-blog but it got error.
don't be like an early '90s mac...describe the error in detail I Have 2 PCs. I got this error in Both of them https://i.imgsafe.org/4bb58f6.pngIs it too much to expect someone asking for help to provide details when asked twice? Basic information should include the CPU, OS, source of miner, command line, output, verbose
output (no -q). I'll ignore anyone who asking for help who does not post, at least, this basic info. You should also say what you've tried to troubleshoot it. I'm not going to help someone who's too lazy to help themselves. |
|
|
|
The binaries from cryptominingblog weren't built properly, which is why you and 90% of the other HOdlers are getting this error. You can either build it yourself or wait for them to rebuild it properly What specifically is wrong with them? I'm using hodleminer-wolf on i7-4790K and hodleminer on core2. No problems with either but I had to install openssl which was trivial. If you try to use hodlminer-wolf on a CPU without AES_NI (core2) it will crash. |
|
|
|
Epsylon3, thanks for cpuminer-multi, which is the main base for this great cpuminer!
Hear! Hear! He has made my job much easier. |
|
|
|
the build.sh script is made for that, it does a "make clean" before
tested, and i see a good hashrate on the miner side, but seems to be only 150H/s on pools side (both suprnova and blockquary)
Yes that is a problem. I don't understand, the hashrate calculation is very simple and the hashes_done calculation is all self contained in the algo source file. scanhash_hodl is counting the collisions and the miner thread measures the time and it's a simple division. I don't see where it could go wrong. It happens with both AES_NI and NON_AES_NI implementations of hodl. It doesn't happen with any other algo. If the hashes_done calculation is wrong then it is in code was copied as-is from the original hodlminer. If the time is wrong it is in code that is the same for all algos. The only other thing I can think of is phantom accepts or silent rejects. Either the miner is dsplaying shares that were never submitted or not reporting shares that were rejected. It happens with both AES_NI and NON_AES_NI implementations of hodl. It doesn't happen with any other algo. The pool reported hashrate appears to be inline with both precedessors, although it's hard to be sure with the flunctuations. I've seen it as high as 400 H/s with both Wolf and opt/wolf on an i7-4790K and i7-6700K repsectively. I will do some instrumenting to gather data to see if I can figure out what's going on. FYI, I haven't maintained build.sh, so YMMV |
|
|
|
How to mine this coin? i downloaded a cpu miner from cryptocureency-blog but it got error.
I'm not sure that Windows binary was compiled as a Windows distribution binary... Wolf's cpu miner doesn't work with my I7 4790K. It works with mine. Do you have openssl installed? Could you explain how you installed it? I couldn't with any effort. I installed it but it didn't help don't be like an early '90s mac...describe the error in detail
Sheesh, not a single one of you has taken Fuzzbawls advice. |
|
|
|
So I've been mining a couple of days and getting solutions submitted and accepted... but they mostly don't turn up in the unconfirmed section on my dashboard. Am I missing something or it isn't working properly?
Coins won't sjow up in unconfirmed until a block is found. Do you have anything in the earnings estimate? |
|
|
|
How to mine this coin? i downloaded a cpu miner from cryptocureency-blog but it got error.
I'm not sure that Windows binary was compiled as a Windows distribution binary... Wolf's cpu miner doesn't work with my I7 4790K. It works with mine. Do you have openssl installed? |
|
|
|
No CPU mining here but I like your style,
0cc24f5a79ad5200fc546bd534523d2cb25da73420830d59eed7c9cf4732e99b
Cheers!
WOW, my first donation. Many thanks. I'll have to make sure I don't post any sarcastic replies to any of your mining questions, CPU or otherwise. |
|
|
|
cpuminer-opt v3.1.10 is available for download with support for HOdl. https://drive.google.com/file/d/0B0lVSGQYLJIZckxmTS1aRWQ5OEU/view?usp=sharingcpuminer-opt is a multi-algo CPU miner optimized for SSE2 and AES_NI and currently supports over 25 algos. Follow the link in my sig for details. It is only available as source and can be compiled in Linux. I hope to someday have a Windows version available. Thanks to the original developpers of hodleminer and Wolf0 for his AES_NI optimisations. |
|
|
|
i'm having a problem when running more than one gpu, on a old algo like x15, the second gpu do not run at full speed, but it's not throttling, it simply sit there at low core speed, why this?
when i restart the machine for the first few seconds it begin to run at full speed, then the miner close and when i restart it once again it run at slow speed, tried also with the Yimp fork but nothing
Oh dear, I've seen this too much. Here is what I know. Sometimes when a miner stops and restarts, usually to switch algos, it will exhibit any of the following symptoms: - it will fail to start with the same parameters - it will start with reduced intensity (-i) - it will start in a degraded state, low clock A reboot will correct the problem. The occurrance appears to be random. Sometimes a card will get hit multiple times per day, sometimes not for several days Only some cards are affected, some never exhibit the problem. There is no pattern to the affected cards, Maxwell and Kepler have both been affected. It occurs on Windows and linux. It does not appear to be driver related. It appears to affect only specific individual cards. There was discussion about this several months ago. A search on "degraded" might find something. The bottom line is it was never solved. It's possibly a HW issue. I do have some new information, It may be heat related, possibly heat stressing a marginal component. I recently moved an affected card to the basement where it's cooler. It had been crashing often when profit switching. Since the move it has been more stable but I have not been profit switching with it. I only switch manually every few days. I may setup profit switching on this PC to try to recreate the problem. Well there ya go. It's one of those things that has been nagging me for a while. I feel better now. You could try swapping the cards to see if the problem moves. what i know is, it only appear with x15 algo and maybe other xX algo, all other algo are working right, so i think it's not so much hardware related, i've already swapped the card and the same problem is occuring only one card is running at full speed(the one not in the first slot, in other words, the one that is not mining is always the one near the cpu on the x16-x16 riser, at this point it could be the riser, but i doubt because the other algo are running) therefore this strengthens the fact that it might not be HW related, also one of the two card was recently rmaed because i thought it was the card causing this, but nothing, the problem is still there, now i'm running 361 drivers version, i'll try with 364 tomorrow to see if it change something You probably have a different problem then. As I mentioned the problem I'm seeing is always the same card regardless of the MB, slot, riser, OS or drivers. |
|
|
|
|
I have Wolf0's AES merged into cpuminer-opt and am running the first test.
The locally reported hashrate issue seems to persist but is constant. I'm not
sure why it's happening, it's only with hodl.
First impression is about a 10% increase over the non-aes version. If testing goes well
cpuminer-opt v3.1.10 will be released later today with support for hodl on CPUs with,
and without AES_NI, as well as all the other optimized algos supported by cpuminer-opt.
|
|
|
|
|
Show Posts
