Hi!
Please fix error with connect DevFee to eth-eu.dwarfpool.com:
DevFee: ETH: Stratum - connecting to 'eth-eu.dwarfpool.com' <188.165.233.56> port 8008
DevFee: ETH: Stratum - Connected (eth-eu.dwarfpool.com:8008)
ETH: Authorization failed
: {"id":2,"jsonrpc":"2.0","result":false}
ETH: Job timeout, disconnect, retry in 20 sec...
I changed the hosts file to the server -eu pointed to -ru, Error remained:
DevFee: ETH: Stratum - connecting to 'eth-eu.dwarfpool.com' <212.24.48.118> port 8008
DevFee: ETH: Stratum - Connected (eth-eu.dwarfpool.com:8008)
ETH: Authorization failed
: {"id":2,"jsonrpc":"2.0","result":false}
ETH: Job timeout, disconnect, retry in 20 sec...
Use v4.0Beta2, see OP: v4.0 Beta2 - bug fix related to "-allpools 1" and "-allcoins 1" options, download this update if you use these options. |
|
|
|
Well done, Claymore. The only thing missing so far is e-mail notification.
Or may be, I am wrong, and you have this option too? Couldn't find it anyway.
I'll try to add it in next update. Thanks, mate. Just checked it: http://dwarfpool.com/faq/..... Monitoring To enable monitoring of your worker, use email as password. To disable monitoring, restart your miner without email as password. Email will be send if no shares last 15 minutes. ..... So set "-epsw myemail@mymailprovider.com" and that is all. Have you checked it? |
|
|
|
Well done, Claymore. The only thing missing so far is e-mail notification.
Or may be, I am wrong, and you have this option too? Couldn't find it anyway.
I'll try to add it in next update. |
|
|
|
@ Claymore
I updated to v3.3 from a previous 3.x version and was no longer able to mine due to failing to create a big buffer. I was forced to revert to v 1.2 to resolve the issue as any other builds replicate the problem. Absolutely no changes were made to the system in question; all I did was close the previously working miner and updated the directory's contents. All environment variables have been set as well as 2 x 8 GB pagefiles and I've also removed temp files as well as the dag directory which I additionally decided to provide an alternate one on a seperate hard drive to hopefully eliminate the problem. I also tried renaming the dag files successfully created by QTminer in hopes of using them with yours but that also didn't work. My other rig is also Hawaii-based and surprisingly doesn't suffer from this symptom. I just gave v4.0 a try but it still introduces the same error.
Any feedback would be much appreciated!
v3.3 takes may be 10-20 more GPU memory, that's the only difference between previous versions. You even did not mention what cards are used, how much RAM etc. I'm clueless as to why all versions excluding v1.2 fail to create a big buffer despite the fact that they were previously working prior to updating to v3.3. I did mention that the rig in question is seated with a Hawaii-based GPU, more precisely a reference Sapphire 290x operating on Windows 7 x64, Intel Pentium D w/ 2 x 2GB RAM although only 3.25 GB are usable. I can send you my log along with any other information deem it necessary. Thanks for the quick reply! Why only 3.25GB are usable? |
|
|
|
First I want to say, great miner -- Nicely done Claymore.
Been reading about this for a few weeks and just fired it off on my rig last night so version 4.0 is the first version I have used.
4.0 mined all night then for whatever reason this morning, just stopped mining but GPU loads and Miner reported hash rate remained unchanged.
I noticed after 2 hours the pool indicated the effective hash rate was 0 but the miner was still reporting an unchanged hash rate to the pool.
I quit/relaunched the miner and didn't see a change within a few minutes, so I switched to a different miner (without rebooting) and it started up just fine.
----Note: I may not have waited long enough for the pool to update its reporting before I switched miners.
Don't know if this information helps you or the community but I figured I would share it.
System specs as of right now
Windows 10 X64
2x R9 380X
Crimson 15.12 Drivers
Miner shows goot hashrate, so it must send shares, but pool shows zero rate? PM me log file and command line that you use. PM Sent with Link to log file. forgot to mention the system that this occurred on has a SSD and 16GB of Ram, do not know if that is relevant to this problem or not. Issue confirmed and will be fixed in next update by adding watchdog for all miner threads, not only GPU-related threads. |
|
|
|
@ Claymore
I updated to v3.3 from a previous 3.x version and was no longer able to mine due to failing to create a big buffer. I was forced to revert to v 1.2 to resolve the issue as any other builds replicate the problem. Absolutely no changes were made to the system in question; all I did was close the previously working miner and updated the directory's contents. All environment variables have been set as well as 2 x 8 GB pagefiles and I've also removed temp files as well as the dag directory which I additionally decided to provide an alternate one on a seperate hard drive to hopefully eliminate the problem. I also tried renaming the dag files successfully created by QTminer in hopes of using them with yours but that also didn't work. My other rig is also Hawaii-based and surprisingly doesn't suffer from this symptom. I just gave v4.0 a try but it still introduces the same error.
Any feedback would be much appreciated!
v3.3 takes may be 10-20 more GPU memory, that's the only difference between previous versions. You even did not mention what cards are used, how much RAM etc. |
|
|
|
@Claymore can this help u eccelerate the speed of yr miner? New miner binaries now available! Updated the OP text to reflect the release. Big thanks to Epsylon3 and Wolf0 who completed RFP-5 milestones that made this release possible! More information in the announcement. https://forum.decred.org/threads/new-miner-binaries-now-available.3409/i just ask.... tks In that thread I don't see any comments that confirm that new release is faster for AMD. Though I know how to speedup DCR mining by 5-10% and will do it in future. |
|
|
|
First I want to say, great miner -- Nicely done Claymore.
Been reading about this for a few weeks and just fired it off on my rig last night so version 4.0 is the first version I have used.
4.0 mined all night then for whatever reason this morning, just stopped mining but GPU loads and Miner reported hash rate remained unchanged.
I noticed after 2 hours the pool indicated the effective hash rate was 0 but the miner was still reporting an unchanged hash rate to the pool.
I quit/relaunched the miner and didn't see a change within a few minutes, so I switched to a different miner (without rebooting) and it started up just fine.
----Note: I may not have waited long enough for the pool to update its reporting before I switched miners.
Don't know if this information helps you or the community but I figured I would share it.
System specs as of right now
Windows 10 X64
2x R9 380X
Crimson 15.12 Drivers
happened to me also, 2 times for more than 3 hours at a time win7 64bit 15.12 crimson 8gb ram 24gb virtual memory 2x r7 370 (4gb) Send me the log file as soon as you see such behaviour. I set "-dbg 0" by default exactly for such cases. Right now I don't have even single log related to this issue. |
|
|
|
First I want to say, great miner -- Nicely done Claymore.
Been reading about this for a few weeks and just fired it off on my rig last night so version 4.0 is the first version I have used.
4.0 mined all night then for whatever reason this morning, just stopped mining but GPU loads and Miner reported hash rate remained unchanged.
I noticed after 2 hours the pool indicated the effective hash rate was 0 but the miner was still reporting an unchanged hash rate to the pool.
I quit/relaunched the miner and didn't see a change within a few minutes, so I switched to a different miner (without rebooting) and it started up just fine.
----Note: I may not have waited long enough for the pool to update its reporting before I switched miners.
Don't know if this information helps you or the community but I figured I would share it.
System specs as of right now
Windows 10 X64
2x R9 380X
Crimson 15.12 Drivers
Miner shows goot hashrate, so it must send shares, but pool shows zero rate? PM me log file and command line that you use. |
|
|
|
Another issue at the pool.mn We are investingating issues in the backend. Your shares and hashrate are safe and we will fix things ASAP.
Findblocks disabled, new blocks will currently not show up in the frontend
Blockupdate disabled, blocks and transactions confirmations are delayed
Payouts disabled, you will not receive any coins to your offline wallet for the time being
Claymore, when the SOLO VERSION is ARRIVE ? Btw, it will be only ETH solo mode/DCR-pools or we can choose the both SOLO? I spent a lot of time for removing DAG files. So it will be a couple of days later than I planned. But I'm working on it. Not sure about DCR yet, probably first solo version will mine ETH solo and DCR on pools. |
|
|
|
|
v4.0 Beta2 - bug fix related to "-allpools 1" and "-allcoins 1" options, download this update if you use v4.0 and use any of these options.
Skip this update if you don't use these options or you don't use v4.0.
|
|
|
|
Hi, will this work with ETH suprnova? Or with sammys eth proxy with suprnova? https://github.com/sammy007/ether-proxy/If yes, could someone post a running config for the proxy and for the dual miner. If no. OK than i'm not to stupid to get it run...  regards Marcus It does not work with ETH suprnova because they do not support Stratum for ETH. Hi, ocminer says they support stratum... Stratum Port online: http://eth.suprnova.cc:4000But ok right now i'm mining on coinmine... thanks. regards Stratum addresses cannot begin with "http://". They have own understanding of "stratum" I think. |
|
|
|
As the miner is using OpenCL ... whats the reason not to work at all on NV hardware?
The reason is missed optimizations. It would work very slowly on nvidia. |
|
|
|
Hi, will this work with ETH suprnova? Or with sammys eth proxy with suprnova? https://github.com/sammy007/ether-proxy/If yes, could someone post a running config for the proxy and for the dual miner. If no. OK than i'm not to stupid to get it run... regards Marcus It does not work with ETH suprnova because they do not support Stratum for ETH. |
|
|
|
By the way, Claymore - nice turnaround time on the idea. From the time I gave it to you to you having it finished was fast - took me longer when I did it cause I was passing the GPU a broken cache at first to my GPU DAG generation kernel, lol.
You are right, it's better to solve problems with DAGs completely, instead of spending time for workarounds. Though it took me whole day and now I have to postpone other features a bit. |
|
|
|
@Claymore in my command line i use ethermine with eth-proxy: EthDcrMiner64.exe -epool eu1.ethermine.org:4444 -ewal 0x8d5ad572f59fbc5bb********266d3083ea9290.RigName -epsw x -esm 0 -mode 1 -wd 1 -r 1 -dbg -1 -etha 1 Because there is no way to check if my failover is set properly does it suppose to look like that: POOL: us1.ethermine.org:4444, WALLET: 0x8d5ad572f59fbc5bb********266d3083ea9290, PSW: x, WORKER:RigName , ESM: 0, ALLPOOLS: 0
POOL: eth-eu.dwarfpool.com:8008, WALLET: 0x8d5ad572f59fbc5bb********266d3083ea9290, PSW: x, WORKER:RigName , ESM: 0, ALLPOOLS: 0 or should i put the name of the worker after the wallet separated wit dot? I'd recommend: POOL: us1.ethermine.org:4444, WALLET: 0x8d5ad572f59fbc5bb********266d3083ea9290.RigName, PSW: x, ESM: 1 |
|
|
|
on my 270 rigs i get slower hrate
v3.2 ~ 57.2
v4.0 with ethi 16 ~ 55.9
cards are 5-10c hotter that on v3.2
will test it on 380
edit: on 380 everything is ok
At this moment I have a few reports about slower hashrate. And after checking all they are not true. Two reports were about previous epoch #46 for v3.2 and epoch #47 for v4.0, that's the reason. Two reports were about "-ethi 8" that is used in 3.3 and v4.0 that uses "-ethi 8" by default. And one report was related to both reasons at once If you are still sure that v4.0 is slower with "-ethi 16" option on epoch #47 than previous versions on same epoch - PM me logs for both versions so I can check the reason. |
|
|
|
4.0 installed and working great. Only .5 MH less on the speed.
It must have same speed. If you are sure that v3.3 works faster for current epoch #47 - PM me the log files for both v4.0 and v3.3 so I can check it. I was still on 3.2, never upgraded to 3.3 v3.2 uses "-ethi 16" by default, v3.3 and v4.0 use "-ethi 8" by default, so add "-ethi 16" to command line to use same settings. If you still have different speeds with "-ethi 16", PM logs for both versions. |
|
|
|
4.0 installed and working great. Only .5 MH less on the speed.
It must have same speed. If you are sure that v3.3 works faster for current epoch #47 - PM me the log files for both v4.0 and v3.3 so I can check it. |
|
|
|
|
Solo mining support and Linux version are planned, I'm working on it.
|
|
|
|
|
Show Posts
