Dear Claymore!
This is a feature request:
Can You add a key to disable fan speed monitoring on water-cooled videocards to avoid log messages "828 Failed to get fan speed info"?
Main miner window show this info:
GPU0 t=65C fan=-1%, GPU1 t=68C fan=-1%, GPU2 t=68C fan=-1%, GPU3 t=72C fan=-1%
By default you can see this error in debug log only, is it a problem? The total shares for individual cards shown are not correct for Decred
Already fixed in v9.5, update miner. |
|
|
|
|
I found a few recent questions related to low speed of LBC mining in dual mode. Check Readme, "KNOWN ISSUES" section:
.....
- LBC PoW is not very good for dual mining, it causes a bit less Ethereum mining speed.
.....
Also ASM mode is not implemented for LBC yet, but I'm working on it and expect about x2 speedup for LBC when it is finished (for AMD cards). It's a lot of work though, so it will take some more time.
|
|
|
|
Something I really dislike about your miner Claymore is the fact that if I'm dual mining ETC, when DevFee starts I lose another 30-40 seconds because it needs to swap to a different DAG and then after DevFee ends it changes again to a different DAG (132 on ETC 130 on ETH).
I really, really dislike it about your miner.
Just set an ETC pool for your devfee if mining ETC for christ sake, I understand you do a good job with your miners (you also make an awful lot of money, but it's cool anyway, it's deserved), but that's a long way from 1-2%, it's much closer to around 5% of lost hashrate each our with this dag swapping.
+1 i'm also loosing speed because of this +1 too. Also if mining on NiceHash is even worse, as you can get whatever coin with daggerhashimoto algo, and swap DAG like crazy :-D Ok in next update I will improve nicehash support (so devfee will be mined there too) and add "-allcoins etc" mode which selects devfee ETC pools. New version will be available in 2-3 days. |
|
|
|
Something I really dislike about your miner Claymore is the fact that if I'm dual mining ETC, when DevFee starts I lose another 30-40 seconds because it needs to swap to a different DAG and then after DevFee ends it changes again to a different DAG (132 on ETC 130 on ETH).
I really, really dislike it about your miner.
Just set an ETC pool for your devfee if mining ETC for christ sake, I understand you do a good job with your miners (you also make an awful lot of money, but it's cool anyway, it's deserved), but that's a long way from 1-2%, it's much closer to around 5% of lost hashrate each our with this dag swapping.
You can use pools that accept wallet address directly and remove "-allpools 1" option. Hi Claymore, Because of the AMD init bug (where cards are not initiated sequentially) the current miner version (9.5) is unable to know which card is which. After looking at HWiNFO I noticed that each card has a DeviceInstanceId which doesn't change when I reboot my machine. Why can't I use that to target a OC on that card? Right now every time my machine reboot I have to manually OC each card (Kinda annoying). Doesn't sound like an easy implementation but it doesn't hurt to ask  Miner cannot read DeviceInstanceId via OpenCL. But recently I finally found a way to match the OpenCL list of GPUs and the list of GPUs that is used in ADL for temperature/fans/OC management, it must help, I will try to put it in next update. Also now I can enumerate GPUs as AfterBurner does. |
|
|
|
|
Since RX460 cards become more popular, I will add ASM mode for these cards in next update along with some other improvements, it will be available in 2-4 days.
|
|
|
|
Another problem. Open Options, close options, Cannot save file options_temp.ini Make sure you have rights to create/write this file. and Options_temp.in~ appear in folder Make sure you have rights to create/write this file. |
|
|
|
Had no failing rigs - until today. Sadly I now can confirm that EthMan still did not detect that the rig was up and running again ("View miner console" worked).
I started to use your logging debug version now and will inform you as soon as I have the error "recorded".
Did you try to reproduce the lock with sending the restart command to a read-only mamangement interface like I stated before?
Yeah I got some logs and found the reason of the issue, I will post EthMan v3.3 within 1-2 days. Here is new version of EthMan for tests: https://mega.nz/#!7w4hVKyQ!63zs8B8KBsCnreElYCNz5C0pCLw_5Y_jw9hIQZpWVxY1. Fixed issue with lost connection. 2. Added "retrigger" feature and separate options for every event. I tried last 3 versions of AMD drivers. No change...
Read FAQ, a question about freeze until any key is pressed. |
|
|
|
is anyone running a Fury GPU witha RX card in the same OS/System? how did you get it working on zec?
Added to FAQ in first post. |
|
|
|
Hi Sir,
I know you have bigger miners to make and maintain, but could you please consider doing very little changes to this one, so it can be used on all pools? That's allowing custom usernames and passwords.
The coin has good volume and price is rising.
Thanks
I missed your message, I did not check this thread for a long time. It's not a problem, I removed devfee completely since I don't maintain this miner for a long time. I uploaded v2.3 to Mega. It must accept any usernames. But when I check suprnova pool, it shows "Share above target" error and it would take much more time to understand and fix the reason. May be it works with other hardware or drivers or pool... Unfortunately, currently I don't have time for this miner. |
|
|
|
Claymore,
do you have any ideas how to overcome Polaris hashrate drop for epoch >129 ?
Genoil said that DAG now took 100% of first memory bank (2gb) and go to second memory bank, so access two banks instead of one leads significant hashrate drop.
Do you make any research in this direction, or it is hopeless? What you think, any comments?
I have this probleme with 8g rx 480 hash drop every new dag epoche on ethereum and ethereum classic Minergate miner say with her laste version we do not loss effective Hashrate see here; https://minergate.com/blog/v-6-5-no-hashrate-drop-after-dag-epoch-switch/From the description I understood that now they generate DAG on GPU too. So it is not related to this issue. I see the speed drop. I checked possible workarounds, at least for Polaris, they failed. So probably this hashrate drop cannot be fixed, at least on miner software level. |
|
|
|
Had no failing rigs - until today. Sadly I now can confirm that EthMan still did not detect that the rig was up and running again ("View miner console" worked).
I started to use your logging debug version now and will inform you as soon as I have the error "recorded".
Did you try to reproduce the lock with sending the restart command to a read-only mamangement interface like I stated before?
Yeah I got some logs and found the reason of the issue, I will post EthMan v3.3 within 1-2 days. |
|
|
|
Claymore,
do you have any ideas how to overcome Polaris hashrate drop for epoch >129 ?
Genoil said that DAG now took 100% of first memory bank (2gb) and go to second memory bank, so access two banks instead of one leads significant hashrate drop.
Do you make any research in this direction, or it is hopeless? What you think, any comments?
I did not do any research yet, but I will do it very soon. |
|
|
|
How long does the devfee usually take?
Claymore claim that he take 1%, but in fact he took more. You can watch the status of mining, every devfee mining, he is always get the share. He is cheating on 1%. I think he takes at least 3%. In fact you don't understand mining details. Some people think like you and tried to check fee rate in my miners technically, for example: https://bitcointalk.org/index.php?topic=1681108.0About number of shares: I explained it several times, then added to FAQ here: https://bitcointalk.org/index.php?topic=1670733.0Here it is again: ..... Q: Why do I see more shares for devfee than in my mining for the same time? A: Most pools support variable diff, they change "target share" after some time after connection. For example, you have very powerful rig, after connection you will send shares very often. It takes some CPU time to check your shares so after some time pool will send higher share target and miner will send less shares (but they will have more value). When pool updates share target you will see "Pool sets new share target" line in the miner. This way pool can adjust the number of shares that miner sends and balance its load. So check the log or console text to see current target for main mining thread and for devfee thread. For example: DevFee: Pool sets new share target: 0x0083126e (diff: 500H) - this is for devfee mining connection Pool sets new share target: 0x0024fa4f (diff: 1772H) - this is for main mining connection As you can see, target share for main mining is higher in about 3.5 times, so for main mining miner sends in 3 times less shares (but they have 3x more value) than for devfee mining. ..... For ETH most popular pools don't use vardiff, but if you see many shares in devfee it means that you use such pool. So if you see that devfee mining gets more shares - check in the log what share target is used for devfee, it will be much lower than for main mining, so these shares are much cheaper. Of course you can forget about all these complex technical details and continue think that I fool entire community and take 3% or 5% or 7%... I write miners for a long time and a lot of people use them, such thing would be discovered quickly because there are ways to check real devfee mining rate. Thanks for explaining this, there are many people that just want to use the software and not paying anything and this way of monetizing is just perfect. I don't mind "donating" a small amount to the developer but may I know exact amount of the fee since I can't find it publicly, for eth only and for dual mining. It's a good idea to read Readme!!!.txt file (the main miner documentation) included into miner archive or first post of this thread (see my signature). If you still cannot find it, search for "1%" string there. |
|
|
|
Remote manager reporting lost on my remote rig. It is mining just fine but it stopped communicating with it. Any idea why?
Known bug since EthMan 3.0, debug version EthMan 3.2 still have this bug. Claymore cant reproduce it, so cant fix it. Do you have this bug for this version? https://bitcointalk.org/index.php?topic=1433925.msg19552825#msg19552825Currently I've got zero feedback for this version. I need someone that can confirm that he can reproduce this bug in this version. I've wrote feedback on page 601. The issue remains. Rig have restarted about half an hour ago, but EthMan shows that it stays offline. Choosing "view miner console" opens page with working rig. I have static local ip on miner, so I think, the problem is not in dns Ok, then here is new debug version: https://mega.nz/#!H8IgwToD!rJ2gWczg7I7TRewI5V81U7jSxDhaWkOAMpXhfnSAODYStart it, wait until bug is appeared, confirm that rig can be accessed via "View console" command and send me (via PM) "debug.log" file that is created in EthMan's folder. Please use dropbox, mega or google to store the file if possible. |
|
|
|
Remote manager reporting lost on my remote rig. It is mining just fine but it stopped communicating with it. Any idea why?
Known bug since EthMan 3.0, debug version EthMan 3.2 still have this bug. Claymore cant reproduce it, so cant fix it. Do you have this bug for this version? https://bitcointalk.org/index.php?topic=1433925.msg19552825#msg19552825Currently I've got zero feedback for this version. I need someone that can confirm that he can reproduce this bug in this version. |
|
|
|
Claymore how is this explained , this 48.5 mgh is one rx480 which was hashing before with 28.5 mgh , now it is 48.5 , obviously it is not real , but it is hashing for hour with no errors and even after restart of the miner it is the same , even dual mining? Could it be this samsung ddr that when clocked lies the miner that it hashes fast , but in reality it is not , that is why effective hashrate is lower 30% ! I see on all my machines with samsung ddr that has this low effective hashrate! The micron ones and the r9 390 machines don`t have this low effective hashrate!
Of course this is not real hashrate for RX480. Probably you modified bios/clocks too much and now that card is crazy. |
|
|
|
Hi Claymore,
I'm trying to figure out approximately when my 3GB cards will stop working due to DAG growth. How much extra storage do you need in the GPUs beyond the size of the DAG?
Thanks for big font, it helps a lot. You can try to make it even bigger, also color it (red color is very good). Miner uses about +2% extra space. So if current DAG is 2GB, miner will use about 2.04GB of GPU memory if you specify "-eres 0". |
|
|
|
When i mine to pool, this is all I get :
Received unknown response: {"id":null,"method":"mining.notify","params":["2368","3868abc5dcee23341dee7f75f1be7f90ca9904961fef9e0f102cedba1171408d","86e05d05d5173e977a2e7ca8a1ee3b94f477fdee13e0ddd343316de5354a7fe4",true]}
ETH: Job timeout, disconnect, retry in 20 sec...
What did I do wrong?
You can find sample here https://eth.suprnova.cc/The key is "-esm" parameter. Hi Claymore,
Is your miner compatible with eth-proxy?
Or with the Stratum mode, there's no benifit using eth-proxy anymore?
Check FAQ in Readme. |
|
|
|
@claymore:
1) Maybe I found a hint: Is it possible that it is some kind of IP address caching issue? It seems to happen to rigs which reboot and get another (dynamic) IP address. If I change the "IP" field in EthMan to the current numeric IP address or use an alternative DNS name which resolves to the same computer EthMan shows correct "up" state. If I change it to the old one its shown "down" again. Restarting EthMan seems to update these values and the rig ist shown online, even with the same old name ("IP" entry). Or it is some kind of update process which is only executed when adding/changing a rig entry. But maybe this helps...
2) Did you read my comment about retriggering above and understand my issue?
Please test this version: https://mega.nz/#!C5xiUSYY!QY44OAExh5EQ2elGcH1DvfbkQMTkgMSwOEMLoG0lUCULet me know if you still have the issue. DNS caching can cause some additional delays, but in a minute the lost rig must be found anyway. I will add retriggering in next update. Need advice from Mister Claymore or someone else.
I'm mining now at ethermine.org (Europe (France): eu1.ethermine.org:4444)
The pool uses diff 40M
My 3-4 cards rigs are doing fine, but I have 2 standalone comps with only one 30mhs card in each. And this one-card rigs have huge (5-15%) stale share rate reported by pool. all rigs have identical and fast Internet access with the multi-card rigs, 70-100ms latency to pool. Is it due to high pool diff and low (30mhs) rig speed? Is there a way to fix this without changing a pool? I can't move this cards to multi-card rigs ((
I'm using latest Claymore 9.5 but older versions seem to behave the same.
Thanx in advance
40M? May be 4000M? Stale shares can be caused by delays in new job broadcasts from pool side if the pool sends new jobs to faster miners firstly. Though it's just an idea. |
|
|
|
|
Show Posts
