Search content
Sort by
Showing 5 of 5 results by drgrog
Re: PhoenixMiner 2.9e: fastest Ethereum/Ethash miner with lowest devfee (Windows)
Uh ..
Max share difficulty of 33000? So 10x the network difficulty of 3200 TH?
There is a very very very slim chance that rig found a block, but 33297 seems more like a software calculation error :/
Eth: Accepted shares 49778 (276 stales), rejected shares 3 (0 stales)
Eth: Incorrect shares 4 (0.01%), est. stales percentage 0.55%
Eth: Maximum difficulty of found share: 33297.4 TH (!!!)
Max share difficulty of 33000? So 10x the network difficulty of 3200 TH?
There is a very very very slim chance that rig found a block, but 33297 seems more like a software calculation error :/
Re: PhoenixMiner 2.8c: fastest Ethereum/Ethash miner with lowest devfee (Windows)
Add a newline character at the end of the request
You have to add new line (\n) after the end of your JSON request.
Thanks, that did the trick, and now kicking myself for not spotting it.
And makes sense given how JSON streams normally use line-delimiting framing.
Not sure why it ever worked in claymore, guess it's doing something funky.
Re: PhoenixMiner 2.8c: fastest Ethereum/Ethash miner with lowest devfee (Windows)
Tried Phoenix 2.8c today. Mostly good, but have a problem with the remote monitoring.
I have a basic python script using sockets to monitor all rigs and send me alerts if things go wrong.
This works with claymore, which says it uses raw TCP/IP connections (not HTTP) for remote management.
This same script does not work with Phoenix, and hangs when waiting for data from the miner.
It sends the request JSON as per the claymore API {"id":0,"jsonrpc":"2.0","method":"miner_getstat1"}
It then waits for the response, expecting {"result": ["9.3 - ETH" ... data, but it never gets any data.
It uses the socket.recv(1024) method which blocks until there is some data to be read.
The remote monitoring is enabled, and responds to HTTP requests on 3333, showing a html version of the console.
Interestingly claymore's EthMan.exe does work and can see the rigs using Phoenix.
The devs say "Phoenix miner is fully compatible with Claymore's dual miner protocol for remote monitoring and
management.", so am I correct to assume that phoenix should support the raw TCP/IP requests in JSON format?
It's a pretty simple script, that works with claymore, perhaps someone can see if I'm doing something wrong, here is a stripped down version that hangs when waiting for data from the miner.
It hangs because socket.recv blocks when there is no data. If you Ctrl+C you get
Anyone else got monitoring scripts working with Phoenix? Any idea what could be going wrong?
I have a basic python script using sockets to monitor all rigs and send me alerts if things go wrong.
This works with claymore, which says it uses raw TCP/IP connections (not HTTP) for remote management.
This same script does not work with Phoenix, and hangs when waiting for data from the miner.
It sends the request JSON as per the claymore API {"id":0,"jsonrpc":"2.0","method":"miner_getstat1"}
It then waits for the response, expecting {"result": ["9.3 - ETH" ... data, but it never gets any data.
It uses the socket.recv(1024) method which blocks until there is some data to be read.
The remote monitoring is enabled, and responds to HTTP requests on 3333, showing a html version of the console.
Interestingly claymore's EthMan.exe does work and can see the rigs using Phoenix.
The devs say "Phoenix miner is fully compatible with Claymore's dual miner protocol for remote monitoring and
management.", so am I correct to assume that phoenix should support the raw TCP/IP requests in JSON format?
It's a pretty simple script, that works with claymore, perhaps someone can see if I'm doing something wrong, here is a stripped down version that hangs when waiting for data from the miner.
Code:
#!/usr/bin/python3
import socket
import json
def contact_miner(ip,port):
request = b'{"id":0,"jsonrpc":"2.0","method":"miner_getstat1"}'
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
try:
s.connect((ip, port))
except Exception:
return None
s.sendall(request)
data = s.recv(1024)
if data != b'':
return(json.loads(data.decode('utf-8'))['result'])
answer = contact_miner('192.168.1.198', 3333)
print(answer)
import socket
import json
def contact_miner(ip,port):
request = b'{"id":0,"jsonrpc":"2.0","method":"miner_getstat1"}'
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
try:
s.connect((ip, port))
except Exception:
return None
s.sendall(request)
data = s.recv(1024)
if data != b'':
return(json.loads(data.decode('utf-8'))['result'])
answer = contact_miner('192.168.1.198', 3333)
print(answer)
It hangs because socket.recv blocks when there is no data. If you Ctrl+C you get
Code:
user@server:~/bin$ ./checkPhoenix.py
^CTraceback (most recent call last):
File "./checkPhoenix.py", line 19, in
answer = contact_miner('192.168.1.198', 3333)
File "./checkPhoenix.py", line 14, in contact_miner
data = s.recv(1024)
KeyboardInterrupt
^CTraceback (most recent call last):
File "./checkPhoenix.py", line 19, in
answer = contact_miner('192.168.1.198', 3333)
File "./checkPhoenix.py", line 14, in contact_miner
data = s.recv(1024)
KeyboardInterrupt
Anyone else got monitoring scripts working with Phoenix? Any idea what could be going wrong?
And what are your clocks? That's not a bios problem probably. Your memory OC is too high I would say.
You can use my guide for bios mod: https://bitcointalk.org/index.php?topic=1954245.0
You can use my guide for bios mod: https://bitcointalk.org/index.php?topic=1954245.0
Thanks Mattthev, I was getting errors with the stock clocks at 1284/1750, so not a case of mem OC too high.
The errors have gone away after a windows update of all things. According to the update history, it included driver updates for "Intel - SYSTEM" and "Intel - Other hardware", which I'm guessing was chipset or mobo related.
Haven't looked any further into it, as I'm happy it's been running without errors for a couple of days now.
EthDcrMiner64.exe is showing the "GPU #1 got incorrect share" warning on an RX570.
I understand this can be from OC, but I'm still getting it after reverting to original BIOS, and can't figure out why.
Some details/history:
- It's a Sapphire RX570 4G PULSE OC, 1 of 2 in the rig.
- Card is new. Got 23.5 MHp/s with stock bios (1284/1750, ~110W), no errors in 12hrs.
- Copied 1500 straps up, undervolt to 900, 1320/2020, got 27.3 MH/s ~90W, no errors but not 100% stable.
- Undervolt to 950, 1280/2000, got 27.0 MH/s ~95W, more stable, no errors.
- Removed GPU, installed other one to flash and optimise it, it's all good at 27MH/s with no errors.
- Mining with both cards installed, I started seeing "got incorrect share" whilst playing with voltages and getting things stable
- I get about 10 errors per hour, only on that card.
- GPU does find shares, about 10/hr, so ~50% good 50% incorrect.
- There are zero (0) GPU memory errors in HWiNFO64, which I thought was the cause of incorrect shares.
I've tried:
- Re-flashing original BIOS from backup, (so back to original straps and clocks etc.), still get 'incorrect share' errors (and low hash rate with high power
- Using original bios with minimal mods: copy 1625 straps upwards, 1280/1850 clocks, still get 'incorrect share' errors.
- Tried card solo or as part of a pair in rig, still errors only on this card.
- Tried plugging a monitor into that GPU.
- Tried playing with the -dcri value, hard to tell but MAYBE more errors at lower dcri values (eg. 1)
Other info:
- Pool shows my effective hash rate much less than my reported hash rate.
- Temperatures are in 60-70 range, fan 20-30%, so all good there.
- Double checked that CrossFire is disabled.
- Claymore v9.8, Windows 10 x64, Radeon 17.5.1 (No Afterburner or TRIXX installed)
- EthDcrMiner64.exe -epool us1.ethermine.org:4444 -ewal 0xWALLET.name -epsw x -allpools 1 -dcri 10
- Only mining ETH, so don't know if it affects other coins.
I'm a bit new to this, so what am I missing?
Could I have damaged the card when lowering voltage?
I understand this can be from OC, but I'm still getting it after reverting to original BIOS, and can't figure out why.
Some details/history:
- It's a Sapphire RX570 4G PULSE OC, 1 of 2 in the rig.
- Card is new. Got 23.5 MHp/s with stock bios (1284/1750, ~110W), no errors in 12hrs.
- Copied 1500 straps up, undervolt to 900, 1320/2020, got 27.3 MH/s ~90W, no errors but not 100% stable.
- Undervolt to 950, 1280/2000, got 27.0 MH/s ~95W, more stable, no errors.
- Removed GPU, installed other one to flash and optimise it, it's all good at 27MH/s with no errors.
- Mining with both cards installed, I started seeing "got incorrect share" whilst playing with voltages and getting things stable
- I get about 10 errors per hour, only on that card.
- GPU does find shares, about 10/hr, so ~50% good 50% incorrect.
- There are zero (0) GPU memory errors in HWiNFO64, which I thought was the cause of incorrect shares.
I've tried:
- Re-flashing original BIOS from backup, (so back to original straps and clocks etc.), still get 'incorrect share' errors (and low hash rate with high power
- Using original bios with minimal mods: copy 1625 straps upwards, 1280/1850 clocks, still get 'incorrect share' errors.
- Tried card solo or as part of a pair in rig, still errors only on this card.
- Tried plugging a monitor into that GPU.
- Tried playing with the -dcri value, hard to tell but MAYBE more errors at lower dcri values (eg. 1)
Other info:
- Pool shows my effective hash rate much less than my reported hash rate.
- Temperatures are in 60-70 range, fan 20-30%, so all good there.
- Double checked that CrossFire is disabled.
- Claymore v9.8, Windows 10 x64, Radeon 17.5.1 (No Afterburner or TRIXX installed)
- EthDcrMiner64.exe -epool us1.ethermine.org:4444 -ewal 0xWALLET.name -epsw x -allpools 1 -dcri 10
- Only mining ETH, so don't know if it affects other coins.
I'm a bit new to this, so what am I missing?
Could I have damaged the card when lowering voltage?