Topic: PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux) - page 350. (Read 784965 times)

why you would use pm with newest drivers ? you will have the same results in hashrate ... ffs

Phoenix, allready 19.2.3 driver realeased and I sure AMD release 19.3.1 version soon. When we can use new version of your miner with support of new drivers versions?

Thanks, but still no.

Geth is truly ready to mine.  I'm using ethminer against it and successfully mining blocks.  In fact, PhoenixMiner starts mining with it before it craps out due to the stratum thread error - so it's not an issue with being able to get work with eth_getwork (refer to log posted above)

Had previously tried -gwtime - no change

-G is invalid option for PhoenixMiner

-mode 1 - no change

PhoenixMiner is not an option currently.

In a command line see if geth is truly set to mine:

geth --rpc --rpcapi eth --rpcaddr IPADDR --rpcport YOURPORT --mine --miner.etherbase console


Ok so it is supposed to be supported protocal so try one of these 3 things:

ADD -G see if it will trigger the getwork method.

Claymore command:
-mode 1

Phoenix command:
-gwtime 200 (Recheck period for Solo/GetWork mining default: 200 ms)

see if any of these help.

geth is on a different machine.

-v only prints version and exits - doesn't enable verbose.  -log 2 is supposed to enable debug messages, but doesn't really appear any different.  Here's a full log with -log 2

So same thing here - why is it monitoring a stratum thread and rebooting because of it if we are not using stratum.  Seems like a pretty clear bug to me.

My gpu is 48C and fan is 0%  according to phoenix miner program. (I have set target temp 50C).
 
But I also have set minimum rpm. Is the fan completely shut off when my  mining program shows that the fan is 0%? Or is it 0% compared to what  minimum fan speed is. That it is actually 500rpm (0%) and max is 2400rpm  (100%) ?
I cant look at the gpus because they are boxed in and safe outside.

hello,

i would like to ask some questions:
- when i start to mine, how long it takes to start dev mining?
- when i start stop miner, does it reset counter for dev mining? for example im mining with another miner, then it starts with claymore, after couple hours, it switch back and then after couple hours again with claymore, so does it reset dev mining counter? or another example, im fine tunning and i left miner run for half hour or less, does the counter reset all the time?

thank you

is geth running on same machine?

can you add -v 3 to the command line its for more verbose output.

For AMD


For Nvidia

what is your command line startup?

Now if there is a hidden trick for enabling Stratum in geth, I'd love to hear it.  Of if there's a quick & easy way to have a proxy that talks rpc to geth and then talks stratum to miner - without having to setup a whole pool software for myself.  That would be fine, but there still appears to be a bug in PhoenixMiner's support for local rpc.

I'm having the same issue.  I'm mining Callisto (CLO).  I had been using Parity with its built-in stratum support, but since they have not updated their Parity client (rust-callisto) for last week's hard fork, I tried to switch to Geth, which doesn't have stratum - thus needing to switch to the RPC interface for get_work.  This is where the issue comes in.

I am setting the coin on the commandline.

I tried setting a "password' in commandline as suggested above, but that doesn't make a difference.  Over the past few days, I've also tried as many other options as I can.  It appears that the issue is it's connecting on RPC for get_work, but there's still a watchdog for a Stratum thread - but since we're not using Stratum, it sees no activity and bombs out.

See here - you can see that the coin is properly set, has connected to geth successfully, and has started mining, but at 51s, it kills itself because of the stratum thread.

Take a look at post 1. Your startup isnt defining coin corrrectly.

See examples match them as they will still need local user  and password as well.

lesjokolat

yes geth local connection PhoenixMiner.exe -pool http://192.168.1.12:8545
Other miners are working fine, what could be wrong?

Have you enabled stratum connections in GETH locally?

if not then you should be connecting via getwork then.

GLTU

http://c.radikal.ru/c04/1903/76/c9209898ff0b.jpg


PhoenixMiner_4.1c

guys what's the problem? he doesn't connect to solo mining through my geth
------------------------------------------------------------------------
 and this version works fine  - PhoenixMiner_4.0b_Windows

Hi - yep...  Keeping tabs on a lot of different forums/channels...   Looks like you've got your Vegas all figured out

You said you have tried both things. Have you tried all the values for -ethi parameter (not only -8192 and -7680)? Have you tried -ethi -1 ? This definitely should solve your problem. Beware all the values after -ethi must be negative.

Im still getting errors having tried both things

2019.02.27:00:33:31.230: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x8d6e471fdc9247b282c1a03359c3e11822dc90727f5c7887637b50eb9d08ec7a","0xd5c0f3c36d0a543d1ec6363fda4c51ba4ab00e7a5fbfa7d81ebb3ba46fd25dcb","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x6efce6"]}
2019.02.27:00:33:31.230: eths Eth: New job #8d6e471f from eu1.ethermine.org:4444; diff: 4000MH
2019.02.27:00:33:31.230: GPU1 GPU1: Starting up... (0)
2019.02.27:00:33:31.231: GPU1 GPU1: Generating ethash light cache for epoch #242
2019.02.27:00:33:33.521: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xe9db1b591366ad0acc9b507d8d9ec73720160598d6bf03eaa81045c209dc5c79","0xd5c0f3c36d0a543d1ec6363fda4c51ba4ab00e7a5fbfa7d81ebb3ba46fd25dcb","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x6efce6"]}
2019.02.27:00:33:33.521: eths Eth: New job #e9db1b59 from eu1.ethermine.org:4444; diff: 4000MH
2019.02.27:00:33:33.927: GPU1 Light cache generated in 2.7 s (17.2 MB/s)
2019.02.27:00:33:34.181: GPU1 GPU1: Allocating DAG (2.91) GB; good for epoch up to #244
2019.02.27:00:33:34.414: GPU1 GPU1: Allocating light cache buffer (46.5) MB; good for epoch up to #244
2019.02.27:00:33:34.429: GPU1 GPU1: Generating DAG for epoch #242
2019.02.27:00:33:35.959: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
2019.02.27:00:33:36.127: GPU1 GPU1: DAG  19%
2019.02.27:00:33:37.480: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x75271779bb5876e73379db9913752435f2e6f4794d577b141bd3a9a9f30deb09","0xd5c0f3c36d0a543d1ec6363fda4c51ba4ab00e7a5fbfa7d81ebb3ba46fd25dcb","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x6efce6"]}
2019.02.27:00:33:37.480: eths Eth: New job #75271779 from eu1.ethermine.org:4444; diff: 4000MH
2019.02.27:00:33:37.823: GPU1 GPU1: DAG  41%
2019.02.27:00:33:39.521: GPU1 GPU1: DAG  63%
2019.02.27:00:33:40.797: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

2019.02.27:00:33:40.944: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x75271779bb5876e73379db9913752435f2e6f4794d577b141bd3a9a9f30deb09","0xd5c0f3c36d0a543d1ec6363fda4c51ba4ab00e7a5fbfa7d81ebb3ba46fd25dcb","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x6efce6"]}
2019.02.27:00:33:41.158: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
2019.02.27:00:33:41.220: GPU1 GPU1: DAG  84%
2019.02.27:00:33:42.195: GPU1 GPU1: DAG generated in 7.8 s (381.1 MB/s)
2019.02.27:00:33:45.445: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x088daa6feef69fb37650e0bc4c08a8702b30d9abf866bf6c91a57f24d321a922","0xd5c0f3c36d0a543d1ec6363fda4c51ba4ab00e7a5fbfa7d81ebb3ba46fd25dcb","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x6efce7"]}
2019.02.27:00:33:45.445: eths Eth: New job #088daa6f from eu1.ethermine.org:4444; diff: 4000MH
2019.02.27:00:33:46.358: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
2019.02.27:00:33:48.410: GPU1 CUDA error in CudaProgram.cu:329 : the launch timed out and was terminated (702)
2019.02.27:00:33:48.410: GPU1 GPU1 search error: the launch timed out and was terminated
2019.02.27:00:33:48.767: wdog Thread(s) not responding. Restarting.
2019.02.27:00:33:49.328: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x145d316cf4fd44334068b66e2e11d34a52d48d919efd79040d36eb94327dcbad","0xd5c0f3c36d0a543d1ec6363fda4c51ba4ab00e7a5fbfa7d81ebb3ba46fd25dcb","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x6efce7"]}
2019.02.27:00:33:49.328: eths Eth: New job #145d316c from eu1.ethermine.org:4444; diff: 4000MH
2019.02.27:00:33:49.332: GPU1 GPU1: Starting up... (0)
2019.02.27:00:33:49.333: GPU1 CUDART error in CudaProgram.cu:57 : all CUDA-capable devices are busy or unavailable (46)
2019.02.27:00:33:49.333: GPU1 GPU1 initMiner error: all CUDA-capable devices are busy or unavailable
2019.02.27:00:33:50.798: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

2019.02.27:00:33:50.798: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x0","0xca71179b40260fd81878ea028613152eb33f20ebe40146e2faf22ca8e9b2e69b"]}

2019.02.27:00:33:50.946: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x145d316cf4fd44334068b66e2e11d34a52d48d919efd79040d36eb94327dcbad","0xd5c0f3c36d0a543d1ec6363fda4c51ba4ab00e7a5fbfa7d81ebb3ba46fd25dcb","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x6efce7"]}
2019.02.27:00:33:50.946: eths Eth: Received: {"id":6,"jsonrpc":"2.0","result":true}
2019.02.27:00:33:51.529: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
2019.02.27:00:33:53.252: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x54b35c4eb7d356a4087a1650131958897e90d7fcbca4e7134db96193a064818f","0xd5c0f3c36d0a543d1ec6363fda4c51ba4ab00e7a5fbfa7d81ebb3ba46fd25dcb","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x6efce7"]}
2019.02.27:00:33:53.252: eths Eth: New job #54b35c4e from eu1.ethermine.org:4444; diff: 4000MH
2019.02.27:00:33:53.261: GPU1 GPU1: Starting up... (0)
2019.02.27:00:33:53.261: GPU1 CUDART error in CudaProgram.cu:57 : all CUDA-capable devices are busy or unavailable (46)
2019.02.27:00:33:53.261: GPU1 GPU1 initMiner error: all CUDA-capable devices are busy or unavailable

I cant find how to use default system GPU indexing so it start from GPU0 and not GPU1

We need this option for our latest nvOC to enable/disable GPUs and multi instance mining.

I know Claymore has the "-altnum" argument, does Phoenix use the same?