Finally I have fixed the bug with Vega.
New version will be available within 24 hours.
Also I will reduce devfee and it will be executed once an hour, similar to dual and zec miners.
@Claymore Nice  . is there any chance to dual mine XMR with other coin ?.. Thanks for your developing efforts Yes it is possible technically, but requires some efforts to implement it properly. |
|
|
|
Finally I have fixed the bug with Vega.
New version will be available within 24 hours.
Also I will reduce devfee and it will be executed once an hour, similar to dual and zec miners.
Linux will get an update as well? Or holding back on it for now? Yes I will release Linux version too. Though Vega won't work in Linux, currently I don't support ROCm drivers. |
|
|
|
|
Finally I have fixed the bug with Vega.
New version will be available within 24 hours.
Also I will reduce devfee and it will be executed once an hour, similar to dual and zec miners.
|
|
|
|
... I do not understand why many write "thank you for the work," "it will not be easy" and that kind of crap ...  If we use the program from mr. Claymore and do not specify the "-nofee 1" option, we become mr. Claymore's clients and pay him a 2% fee (ex. SSL conn...etc). I think Mr. Claymore should tell us "thank you" ...? Right?  I, as an active mr. Claymor's client, have a number of questions for mr. Claymore: 1. How to verify the reliability of 2% of your rewards? Real indicators are 10% or even 15%. The information is taken from the number of allocated shares on the pool and the indicators of the miner. 2. Why when I specify the option "-nofee 1" does your program report that some optimizations are disabled? And how does disabling optimizations relate to your reward? Why? 3. How does the "-h" parameter affect performance? Your measurements, recomendations? 4. Comments on the following message when your program is running: cannot find block data: {"id":4,"jsonrpc":"2.0","result":null,"error":{"code":-1,"message":"Lowdifficultyshare"}} cannot convert blob data How does this affect performance? Is the action accepted? 5. Will there be comments to the comparisons of the performance of your miner and other's? Yes, we have to thank him for is great work. With his miner I get a 10% higher hashrate on some cards. Donating him 2% gives me still 8% more profit. You don't have to use his miner! Just be a dick, take the stak miner source code, remove the fees and compile it yourself. As already explained, it's not 2% of the shares, it's 2% of your mining time. Take a stopwatch and measure the time, the miner uses for dev-fees and the time it's mining for you. ...be a dick? Excuse me, I did not go on insults ... At the expense of time or shares ... think about it - 2% of the time gives a reduction of shares at 10..15% ... funny you. The questions are clearly not for you. Questions on the merits. Your questions are not new, all of them. 1. It's a very good idea to read FAQ in the first post of this thread. If you really think that I take 10-15% of your hashrate - don't use my miners. If you want to share this "news" here: show some proofs at least, the miner writes detailed log file and you can examine it if you have some basic knowledge about pool mining. 2. Because my miner is not free. If you want me to lose 100% earnings from you, I want you to lose a few percents of your earnings too. You always can use open-source miners if you think that you will earn more or if they are more convenient for you. 3. Miner selects best "-h" value automatically. If you think that you can find better value, you can try to do it. 4. The reason depends on pool, may be it was stale share, or GPU found solution incorrectly, you can find more details in the log file. You lost this share anyway. 5. I don't understand why you wait these comparisons from me, you should do it yourself to find the best miner for you. |
|
|
|
As I said, I am not happy to see that those problems are getting noticed by more users everyday. For myself, lowering the voltages seems to did the trick but I still experience some freezes now and then (I guess that I didn't lower them enough).
I am hoping that with so many cases around, Mr. Claymore can verify the existence of the problem.
What I would like to hear from Mr. Claymore is if there are any thoughts for a solution and what I would love to hear is an ETA if one exists.
1. I still cannot reproduce this issue, I described what tests I did: https://bitcointalk.org/index.php?topic=1433925.msg21966972#msg21966972If you have ste-by-step guide how to reproduce this issue - let me know. 2. I'm not sure if it is possible to fix this issue at all, since all these issues are from buggy ADL. |
|
|
|
Hi guys,
Any idea how to disable GPU 10, 12, 13... etc. Like GPU 1 to 9 using the keyboard while mining.
GPU #0...#9 are managed with "0"..."9" keys. "a", "b", "c" keys are for GPU #10, #11, #12. If you have more than 13 GPUs, there is no way to manage GPU #13 and higher with keys. |
|
|
|
@Claymore wait for your update to test on vega  Currently I'm stuck on Vega support, trying to fix some weird bugs I found in assembler, so it seems it will take a couple of days more than I expected. Maybe you release new version for all cards except Vega? And after will work on Vega support? We'll test new version at that time... Nhoooo waaay. I want vega support : ) I'm understand you. But if all ready for other cards why don't release it and continue working on vega support? It takes me almost a day to build and test new version, so it will be slower if I have to do it twice. But I will do it if I cannot fix the bug within two days. |
|
|
|
@Claymore wait for your update to test on vega Currently I'm stuck on Vega support, trying to fix some weird bugs I found in assembler, so it seems it will take a couple of days more than I expected. |
|
|
|
@Claymore will you release new miner today?
New version is almost ready, I will release it in 1-2 days. |
|
|
|
maybe its time for you remove your address and put something like "insertyourwalletadresshere" dont you think ? Oh right, I forgot your the 2% thief...
Thanks for your advice. Here is my experience, if I remove it: 1. People won't be able to launch "start.bat" just to check that miners works, with default settings at least. For example, when I get PMs with support requests, often I say "just launch start.bat to check if miner works at all" and it helps in many cases, because sometimes people break something when they change options. 2. A lot of newbies won't even know the wallet address format at all. |
|
|
|
Hi claymore, i sent an message to you. did u read it ? regards Yes, yesterday, if you check your private messages you will find it. If you cannot find it, please check again, "My messages" text at the top. PS. For everyone (newbies specially) who mines to default wallet address in the miner for some reason: Some people mine to this address sometimes, by accident or when they test my miner with default settings to check if it works, all my test rigs mine to it all the time too. Please do not contact me directly with requests to return your coins, I cannot do it because I don't know if these coins are really yours or you are trying to cheat. Instead, ask your pool support to contact me via PM on this forum (all popular pools have accounts here and I know them) and confirm that it is your coins, after it I will return it immediately. I will not comment the idea to mine to default wallet, but please read Readme and find the phrase "Do not forget to specify your wallet address!" there, it will save some time for everyone. |
|
|
|
About Vega support on Linux - really, I know you're not a Linux type guy... but you honestly should check that shit out. AMD worked with the LLVM/Clang people to get complete support for pretty much every GCN version up to Vega. Now, you're probably thinking that you more or less have the same shit on Windows... but the killer feature of the new toolchain (for me, at least), was the fact that you no longer should ever have to write your kernel in nothing but ASM starting from the ground up, or as I did sometimes, feed the AMD Catalyst OCL compiler some C that it hopefully doesn't fuck up too badly with, and then disassemble the result for (usually quite substantial) modifications. Instead, you first have complete (more or less) control over the emitted ISA through the use of inline assembly. While it is currently slightly stupid (for example, if told that it is to take three uints as input, one uint as output, and via the constraints you aren't specific enough and instead of specifying the TYPE of GPR (VGPR or SGPR - there's a generic constraint that simply specifies it must be a GPR and the compiler should decide), you tell it to simply use a register... it might choke when building due to the register allocator deciding to emit ISA to the assembler that is impossible to encode. In my case, it was that it attempted to use v_alignbit_b32 with a VGPR as the output, one more VGPRa as a param, and the other two params as SGPRs, which is illegal. Fixing it was simply a matter of being slightly more strict with my constraints. They even have a LARGE set of AMDGPU-specific intrinsic functions that also can be used in your OCL. Many, many kinds of common cases where one would otherwise find inline assembly the best option has been simplified even further through the use of the new builtins. The first ones that spring to mind for me are the ones which expose ds_permute_b32 and ds_bpermute_b32 to the developer in a neat and clean built-in function. Other than the little issue I found with the register allocator being a bit dumb if I give it too much freedom (which was trivially diagnosed & fixed) - I honestly have hit far less bugs in this than the old Catalyst compiler... which offers a fraction of the functionality! As for no good *nix protections... awww. I'm not actually interested in circumventing the devfee - it's just somewhat fun; ceases to be so if you don't really try, though! Anyways - I totally get it; I don't agree it's a lost cause (well, not any more so than it being a lost cause on Windows, or any other OS), but God knows it's quite a bit more of a pain in the ass to deter someone when your program is run under *nix instead of Win. Shit - good one spotting the license on UPX. I didn't know that. ROCm does not support Windows, so I'm not going to migrate to it. Also I'm not interested in inline asm and don't have to write in asm directly. Instead, I created own opencl compiler and now I don't care about any limitations or issues. |
|
|
|
I decided to upgrade this miner to common codebase that I use for dual and zcash miners, it will take additional 2-3 days. I'll try to release new version this weekend, but no guaranties.
Vega support? I kind of doubt it based on his tenative ETA, but maybe. Reason being, he says he's already gotta update the framework to the same one he uses for his other miners, which I'm guessing isn't a super simple task given how long this miner has been unchanged (during which time he's released quite a few updated to his other miners.) Adding support for Vega that is presentable isn't super simple, either, as optimizations for new ISA extensions do take a bit. This might be made simpler if he leverages some of the more advanced features of the new LLVM/Clang toolchain used for ROCm, though. Additionally, even if he wanted to rush out a basic implementation of Vega support, he also is at least somewhat mindful of protecting his intellectual property: he won't be able to embed his kernels for Vega like he has done for some of the others (as AMD IL), simply because Vega only works with the new ROCm stack, and there IS no AMD IL used anymore. Since there's really only one GCN version which MUST be used with ROCm, though, I suppose he could simply embed it as ISA like he's done with some others. Plus, then, he has to thwart the common debugging/analysis angles that he's already covered for the old, Catalyst based shit (such as GPU_DUMP_DEVICE_KERNEL, or AMD_OCL_BUILD_OPTIONS_APPEND environment variables.) So, for him, it's not likely to be a simple and straightforward implement and then run the executable through his packer of choice (I believe this is VMProtect for his Windows based ones, his Linux based ones he uses a stub which loads one of the bin files in the current directory, transforms it using appears to be a custom permutation, and then executes it - this new binary is packed with UPX (I forget which version it is now; also, see footnote.)) Footnote: Claymore, you don't have to respond - in fact, I'm fairly sure you won't - but please, for the Linux miners... at least clobber the UPX signature on the decoded Data3.bin. That really was a glaring inattention to detail, IMO. 1. CN miner is rather old, it was created in 2014, and I rarely updated it. For dual and zcach miners I made hundreds of updates in code, I cannot apply them all to this miner easily. So I have to move stratum/kernels code and related stuff to latest framework. Not a complex task, but to make everything work properly, I will have to spend a couple of days at least. 2. Vega support for Windows - yes. For Linux - not right now, my devtools for asm don't work with ROCm, I will have to spend some time to add it. 3. I'm not going to create any good protection for Linux, it's impossible for opensource OS. So if you have some skills you can crack it and be happy PS. UPX license does not allow you to change generated binary. Anyway, changing signature is too easy, I could change entire compression method, but I have much more important things in my todo list. |
|
|
|
|
I decided to upgrade this miner to common codebase that I use for dual and zcash miners, it will take additional 2-3 days. I'll try to release new version this weekend, but no guaranties.
|
|
|
|
Mister Claymore.
Question about Vega eth hashrate.
We already achieved impressive 2000h/s Monero speed using HBCC with blockchain drivers and 2 high intensity threads with xmr-stak-amd.
PM me for details.
Is it possible that with complete miner rewrite, maybe with 2 DAG files in one GPU we can get significant boost with ETH speed?
Or maybe this miner already exists and is used with some private farms?
1. Do you see improvements for enabled HBCC in multi-GPU system? If you use single GPU it may help a bit in some cases, but I doubt that it will help if you have six GPUs. 2. I'm not aware of any faster private ETH miners. I have no experience with 6 Vega rigs but it certainly works for 3 gpu-s. Have you tried to start XMR CPU miner in parallel? Perhaps HBCC just uses bandwidth of main system memory. Just a guess, I did not check it yet. Though CPU miner mainly uses L3 CPU cache, not main memory, but soon I will check it anyway. I have finished asm XMR kernels for all GPUs except Vega, I will check Vega in a day. |
|
|
|
Mister Claymore.
Question about Vega eth hashrate.
We already achieved impressive 2000h/s Monero speed using HBCC with blockchain drivers and 2 high intensity threads with xmr-stak-amd.
PM me for details.
Is it possible that with complete miner rewrite, maybe with 2 DAG files in one GPU we can get significant boost with ETH speed?
Or maybe this miner already exists and is used with some private farms?
1. Do you see improvements for enabled HBCC in multi-GPU system? If you use single GPU it may help a bit in some cases, but I doubt that it will help if you have six GPUs. Also for XMR, may be you see boost because you use bandwidth of main RAM? Try to start CPU miner to check it. 2. I'm not aware of any faster private ETH miners. |
|
|
|
Claymore, I did not check ETH only mode, but in ETH+DCR mode it is easy to reproduce: 1) start mining (no clocks settings in bat file in my case) 2) wait until miner looses connection to pool (you can force it by unpluggung lan cable) 3) wait until miner connects to the pool again (plug in the lan cable) 4) in most cases the graphic card will work in P0/P1/P2 state with low clocks until you restart the miner I have copyed parts of the log to this post, maybe it will help? https://bitcointalk.org/index.php?topic=1433925.msg21431939#msg21431939 Then you should be able to see this issue if you press "0" key to disable GPU0 and then press it again two times to enable it. When I do it, everything works fine, I see P0 clocks when GPU is disabled and P7 clocks when it is enabled. |
|
|
|
|
I tried to reproduce the issue with clocks and low speed until miner restart.
Windows 10, latest blockchain drivers, stock RX580 Nitro+.
1. No overclock: If I start miner in ETH-only mode, it shows about 16MH/s only (and low memory controller load in GPU-Z) and I see this speed for about 20 seconds, then it shows 24.6MH and works fine. For dual mode it shows full speed immediately. Unfortunately, I have no idea why GPU works slowly within first 20 seconds, it is something related to drivers.
2. I close the miner and apply some changes in clocks: memory 2000 -> 2100, core 1300 -> 1100. When I start miner, I see that it applies new clocks in about 10 seconds, but still shows 18MH/s only for first 20 seconds. Then it shows about 25.5MH.
Note that I use default ROM so these speeds are not high.
3. I close miner and apply new clocks again: -cclock 1000, -mclock 2050. Same behavior: it shows low speed at start, then normal speed for these clocks. GPU-Z shows changes in clocks in about 10 seconds after start.
So right now I cannot reproduce the issue with new clocks: in my tests new clocks are applied immediately, I don't need to restart the miner or reboot the system.
|
|
|
|
First post in this forum, just to say good job Claymore on the 10.0 version, it seems to take really well the clock and voltage options now if paired with AMD GPUs and the blockchain driver.
I would like to ask Claymore 2 questions:
- I have probably have run into a little issue in regards to core voltage settings with the miner. I have one GPU that when set to non-rounded voltage values (as the GPU only recognizes 6.25mv steps, this means all the voltage values that arent x25mv, x50mv, x75mv and x00mv) it misheaves pretty quickly and has OCL thread hang just a minute after starting mining (DAG is already loaded and no EDC errors are shown. If I use rounded values, it seems to take them better and if a OCL thread hang happens, it happens after several hours and probably blamed to memory clock instability.
- As you know, the clock and voltage control API from AMD has a mechanism built in that in the end reduces performance very time you touch any core/mem voltage/clock values if they were changed AFTER the GPU entered, even if for just a little moment, in maximum core and memory Pstate. I have seen when doing the OC/UV settings with your miner that the settings I put are enforced just before the DAG loads, but still with soft monitoring the GPUs enter for a brief period in max clock/voltages before that, causing that any clock/volt setting enforced by the miner, if it happens to change an existing value (this doesnt happen at all if the GPU had these values since last reboot), it enters in this "reduced performance mode" and thus hashrate is lower than you should. Is there any chance that the voltage/clock options are enforced first of all, so this behaviour doesnt happen? Because every time I have a OCL thead/hang, I have to do 2 reboots, the first one automatic from the miner and the second one to have the clock/volt dialed in a first time so the next reboot the GPUs dont enter in this "lower performance mode". i know i could just bios flash all the OC/UV/fan settings, but im still at finding the best OC/UV settings for each gpu, and I would like to nail them via driver changes rather than BIOS modding yet.
All in all very satisfied with this new version.
Thanks in advance!
I'm running v10 and the overclocking and voltage control are pretty great features, but they need some more work.
I have a very strange problem. Most of the time, when I power on the rig and start Claymore, the cards appear to be clocked to the correct frequencies set in the .bat file, but they mine with the hashrate of stock clocks. I have to stop Claymore and start it again for the cards to mine properly. For example, at stock speeds (1265/1750mhz) they mine with 24mh and at 1100/2050 they mine with 29mh. On the first run, gpu-z shows 1100/2050 clocks but the cards mine at 24mh. When I restart Claymore, the cards are at 1100/2050 again but they mine with 29mh. Also, sometimes the voltages don't change accordingly, so every time I have to check the voltages with gpu-z, to see if everything is correct and this kinda blows the idea of having a fast way to restart a miner and have him up and running in no time. I know other people that have the same problems. Hope that this gets fixed soon, since this automatic overclocking from Claymore is an extremely helpful and easy way to overclock.
I need to know Windows version, GPU model and drivers version to be able to reproduce this issue. |
|
|
|
Update: Finally I managed to get about 5% speedup for this miner for almost all cards, I will release new version in about a week. Linux version too.
You were told correctly: read first post or Readme file. You will find these lines:
....
This miner is free-to-use, however, current developer fee is 2% if you use secure SSL/TLS connection to mining pool, miner mines 49 rounds for you and 1 round for developer.
If you use unsecure connection to mining pool, current developer fee is 2.5%, miner mines 39 rounds for you and 1 round for developer.
If you don't agree with the dev fee - don't use this miner, or use "-nofee" option.
....
Please spend some time to translate and understand this info.
Okay, but it is not in the license, but in "history.txt" is the suggestion to insert in the file license.txt a clause informing this, because few when they lower the program read only the license (when they read). in history reports the following "- reduced devfee, it's 2% now if you use secure SSL / TLS connection, currently miningpoolhub pool supports encrypted connections, see Readme for samples." as you have been quoted only in the file available for download Claymore CryptoNote GPU Miner v9.7 Beta - POOL.rar does not have readme file neither in the root nor in the folder "Remote manager" I do not distribute any .RAR files, so you downloaded miner from some other place, that's why it does not contain Readme file. It may also contain some other bad things then. What prevents you from going to the first message of this thread and downloading the miner directly from the links I placed there? |
|
|
|
|
Show Posts
