Re: PhoenixMiner 3.5d: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)

Quote from: sandbagger on September 30, 2018, 01:38:00 AM

Phoenix

Any idea why with going from 3.5C to D that my 13 1070 cards went from 420.7 to 420.4?
I havent plugged my wattmeter in to see what if any change to the power consumption has changed yet.
I am using the same bat file with no changes since 3.0
I thought the new more efficient kernel was for AMD only

Yes, the green kernels are for AMD only. There were no changes that would affect the Nvidia hashrate between 3.5c and 3.5d releases, so this is probably a minor fluctuation (such a small change can be caused by virtually anything). Our internal tests show nearly identical hashrate between 3.5 versions for Nvidia cards.

Quote from: habitat412 on September 30, 2018, 07:38:17 AM

I don't know if it has been mentioned on this thread since it's over 129 pages long, but is there a expected dual mining feature coming out anytime soon?

There is high probability that in the next version (3.6), there will be support for dual-mining Blake2s.

Quote from: mag106 on September 30, 2018, 01:42:23 PM

@PhoenixMiner,Hello, pool does not confirm acceptance of share, claymore 11.9 works fine, but I want to use phoenix

Code:

[spoiler]2018.09.30:16:18:51.677: main Phoenix Miner 3.5d Windows/msvc - Release build
...
2018.09.30:16:20:08.590: GPU3 Eth: GPU3: ETH share found!
2018.09.30:16:20:08.591: eths Eth: Send: {"id":4,"jsonrpc":"2.0","method":"eth_submitWork","params":["0x87f704af718559b0","0xd247280f4694d0c254bd8b9c21b2791eee2ced6073541a2fd1a727714b19e097","0xf598fd30b62a82b35d99c9dd6153d784dfaa7a78876083c537959fdf2fea6309"]}

2018.09.30:16:20:08.591: eths Eth: Share actual difficulty: 260.7 GH (!)
2018.09.30:16:20:08.671: eths Eth: Received: {"jsonrpc":"2.0","id":0,"result":["0xd247280f4694d0c254bd8b9c21b2791eee2ced6073541a2fd1a727714b19e097","0x185bb34ccb2fa3c9cf41cb20429e92c96102573d3c8ed27d820dba10b5e2b962","0x000000006df37f675ef6eadf5ab9a2072d44268d97df837e6748956e5c6c2116"]}
2018.09.30:16:20:08.671: eths Eth: Received: {"jsonrpc":"2.0","id":0,"result":["0xd247280f4694d0c254bd8b9c21b2791eee2ced6073541a2fd1a727714b19e097","0x185bb34ccb2fa3c9cf41cb20429e92c96102573d3c8ed27d820dba10b5e2b962","0x000000006df37f675ef6eadf5ab9a2072d44268d97df837e6748956e5c6c2116"]}
2018.09.30:16:20:08.943: eths Eth: Received: {"jsonrpc":"2.0","id":72379,"result":true}
....
[/spoiler]

Thank you for the log! The reason for the problem is the partially broken pool stratum implementation, which uses random IDs for the JSON-RPC responses (like 72379 above), which won't allow the miner to match them to the IDs of the requests. Anyway, we have added a workaround for this issue, which will assume that any response with strange ID out of range is for the last submitted share. The workaround will be included in the next release of PhoenixMiner.

Quote from: camando on October 01, 2018, 08:37:51 AM

GTX 1060 3GB How to seting?

Quote from: AZuley on October 01, 2018, 10:19:27 AM

The same question. Does not work on 1060 3Gb Ubuntu 16-18

Kernel: 4.13.16
Drivers: N 396.54

Thank you for the system information. We have successfully ran 1060 3GB and 6GB under HiveOS 0.5-76 so we are really not sure why is this happening. Probably it is somehow connected to the number of the GPUs as all reports so far are with a lot of GPUs. Please try to add -gpus 123 command-line parameter in your custom miner settings in order to use only the first three GPUs and see if this fixes the problem. Obviously this isn't a workable solution but it will help us reproduce it.

Quote from: Aurren on October 01, 2018, 03:45:19 PM

Quote from: PhoenixMiner on September 29, 2018, 03:06:22 PM

Quote from: Aurren on September 27, 2018, 09:24:10 PM

On HiveOS as well, was getting the same problem, and then I tried -gser 2, and that was able to initialize the first 5 cards until the miner detected that my other 3 cards (all NVIDIA 1060 3gb) was unresponsive and it restarted the miner again, then it just keeps going in that loop of creating the DAG for 5 cards and restarting the miner. Is there a way to delay the miner from checking the cards until the -gser 2 has a chance to create the DAG for all the cards?

EDIT: I also want to add that the current HiveOS startup for claymore can load the DAG for all 8 cards all at once.

Please try using the -gser 1 option, or turn off the watchdog with -wdog 0 and see if this fixes the problem. We will make changes in the next release but it is important to know what is happening to avoid the problem in the future.

I can report that -gser 1 doesn't work, it tries to generate DAG for the first three cards but stuck at 0%. I can also report that -wdog 0 works and the miner runs fine, it took about 2-3 minutes to fully generate DAG for all 8 cards. I really don't want the watchdog to be disabled though, but I can at least report it works in HiveOS with -gser 2 and -wdog 0, on 8 1060 3GB cards.

EDIT: Also, new problem is that Hive doesn't see the current hashrate. My current miner options are: "-nvidia -leaveoc -gser 2 -wdog 0". It reports to the pool just fine, but in HiveOS it sees temperature and fan speed but not hashrate.

Thank you this is useful information. If you are able it would be very helpful if you send us the log from the first few minutes (up to the point where the DAGs are created and the miner is already working) from a successful run with "-nvidia -leaveoc -gser 2 -wdog 0". We need to know if the problem is with slow creation of the light cache, or with some kind of DAG buffer allocation problems with the GPUs themselves.

As for the HiveOS not reporting the hashrate - this seems to be intermittent problem with HiveOS itself, it worked fine most of the time but sometimes it wouldn't refresh the hashrate by itself (on the stats graph) but it would show as numbers on the top of the miner status page.

Quote from: cidman on October 01, 2018, 07:34:43 PM

bing is hiding ur miner from searches
searching bing for "phoenix miner" brings up the phoenix btc miner both the original and 2
and on the first page nothing about ur miner
not saying they are hiding ur miner in particular maybe alt miners or something, but just thought it was interesting
google and this btctalk thread is number 1
guaranteed more organic searches on bing and google are for ur miner in the particular search "phoenix miner"

We doubt that this is deliberate. If anything, this shows just how outdated the bing search results are.