Hi, can you update with an argument to make the fee act every 12 or 24hours? You can enable the dev fee as soon as the miner starts for the equivalent time and then the miner run the specified hours without have to change DAG.. If you make it as argument, people can use it if want or not  The DAG switches of the devfee can be avoided if you mine one of the supported coins (see the documentation of the -coin option in the first post). We will add a lot more ethash based coins in the next release. If the coin you want to mine is not supported yet, you can use -coin to choose a coin with smaller DAG for devfee. Hello team,
Fast questions:
Is there a reason for this option to always be "0" ??
setx GPU_FORCE_64BIT_PTR 0
Are there any advantages if we set it to "1" instead?
Thank you for this excellent miner!
In most cases this doesn't have any effect as the miner sets it internally to the optimal value. So, you don't even have to specify it any more in the .bat file. There is no harm in specifying it though and there might be cases where it can help. Dr. PhoenixMiner,
Could you add the a little bit options to ur miner for Nvidia cards? Such as:
-fanmin
-fanmax
-tmax
-powlim
-cclock
-mclock
And one great option for AMD cards - enable compute mod by adding option -y into the bat? Not only typing key "y".
Claymore recently added these options. Next step is yours. I love ur miner for stability and hashrate. But I believe that these options can improve miner's positions.
We are working on OC settings for Nvidia cards but they won't be ready for the next version. As for the -y option - it will probably be ready for the next version. Hello Developer, Great miner I/we really appreciate the work you have put into it. With that said, I have been using PM since 2.2 I think, although I do like the auto -dcri feature Claymore uses now, so I do cheat every now and then and sneak back to Claymore, it's like an old dirty whore, you know, anyways end up going back, well maybe not, anyways, I digress... I would like to request an expansion of a current feature. Your -coin feature is great but I only solo mine to geth and with that said I typically solo mine the lower difficulty coins I think might have a shot of increasing in price, someday. With that said, you do include a few good coins in your -coin feature but if you could include ALL coins on the Minerpool.net splash screen, that would be great! https://minerpool.net/This would provide a much greater DAG coverage for that feature, I know its pretty miner (pun intended) request but maybe someday, it would be nice to have more coverage. Thanks again! The auto-tune functionality will be ready for PhoenixMiner 3.0, so we hope you'll have one less reason to ... umm, cheat As for the direct support for new ethash-based coins, yes, we will add support for pretty much everything from minerpool.net. When 3.0 ?
Not too soon because we have some big changes for this one. |
|
|
|
I'm having an issue with OC/UV settings not sticking for a few minutes, ie: Mhs will go from 30 to 25 for a couple of minutes then bounce back to 30.
I think I saw something about this being mentioned in another post (2.9d release) but can't seem to find a permanent fix, this doesn't happen with claymore's miner.
Here is my setup:
- 4 Rx 580 4Gb and 4 Rx 580 8Gb
- latest Adrenalin March 23rd drivers
- only timing strap bios mod applied to cards
- OC/UV applied via Phoenix settings
This has a direct impact on the effective speeds, is anyone else experiencing this issue?
Thanks in advance!
BTW, love the Phoenix miner!!! Keep up the great work, cheers!
Most probably the OC settings are OK even during these hash-rate dips. Please note if the hash-rate drops happen on the same GPU(s) or on different GPU(s), then try the following things to fix them: 1. Try using -clf 2 or -clf 0. 2. Try to change the -gt parameter (you can do this interactively with the + and - keys) 3. Try using the alternative kenrles: -clkernel 2. Note that you will have to select the optimal -gt again as it will be different with these kernels 4. If nothing else helps, lower the mining intensity ( -mi). The default is 12. Note that you may be better off with the occasional hashrate drops instead of permanent hashrate drop because of the lower mining intensity. Thank you for the logs. It appears that ADL is actually working correctly even on the Strix cards. The messages for applying OC settings are missing because the cards are already at these settings (PhoenixMiner first checks if the settings are the same before applying them). We will add -resetoc option in the next version to reset all OC settings when the miner starts to start from "clean sheet" so to speak. However the root cause of the problem that you are experiencing seems to be that the Strix cards are reporting too high minimal FAN rpms (1722 rpm), which are probably exactly these 41% that you are seeing. We will make some changes in the next release to avoid abiding by these limits if they are too low or too high. @PhoenixMiner
The Readme states:
-fanmin <n> Set fan control min speed in % (-1 for default)
-fanmax <n> Set fan control max speed in % (-1 for default)
This creates an error if I actually set the -fanmin -1 or -fanmax -1
Miner will not load
Miner Dispalys
Out of range -fanmin value: -1 (must be between 0 and 100)
Invalid value in -fanmin option: -1
Out of range -fanmax value: -1 (must be between 0 and 100)
Invalid value in -fanmax option: -1
Thank you, this will be fixed in the next release. Yesterday I changed all of my riser cards, usb cables, etc. and I increased the fan speed for all cards and lowered the mem clock to 700 as well. The rig is now running stable for about 19 hours. 1900 shares and ZERO stales!!! very nice!!! good job!! thanks for your help!!!!! ...but I have another 2 questions: 1st: what is the correct command line for the reboot.bat and the command line for the miner, if I choose the -rmode 2 option? - The first function should be, when not enough shares can be found, the miner should restart - if the miner crashes "normal", the miner should restart - if the crash happens again, the miner should restart the rig -- is this possible?! --- miner: "PhoenixMiner.exe -nvNew 1 -stales 1 -rmode 2 -wdog 1 -pool etc-eu1.nanopool.org:19999 -pool2 etc-eu2.nanopool.org:19999 -wal wallet.worker/email -pass x -ftime 10" --- reboot.bat: "shutdown /r /t 1 /f"? 2nd: is it possible to show some kind of hardware monitor for nvidia cards? especially the watts of each gpu within the miner. I really really would love to have this function!! --- or is it the -qswin (i.e. 15) option? 1. What is the correct command line for reboot.bat? It depends on what you want but generally, you want to reboot your rig, so shutdown /r /t 1 /f is OK. Unfortunately there is no way to do different things if the restart reason is different - you decide what to do when the miner is restarted for any reason via the -rmode parameter. 2. is it possible to show some kind of hardware monitor for nvidia cards? We will add more HW monitoring for both Nvidia and AMD cards (and possibly some OC controls for Nvidia cards) in the future, however the power consumption that is reported by the cards can only be taken as a relative value because in reality the power is quite different. who knows what the performance of -qswin 30 or -qswin 15 or a gteal between 1 and 30 at -qswin effect is on the Nvidia GPU?
would like a clear explanation of what extras this brings to the NVidia GPU. I myself have placed -gswin 15 or 30 on the start.bat but no extra information on the miner screen. Thank you phoenix dev.
The -gswin option doesn't affect performance in any way. It just specifies how "smooth" you want your reported hashrate speed. The speed is calculated with a moving average window with size from 5 to 30 seconds (this is what is specified by -gswin). So for example, if you specify -gswin 30 the speed you see will be the average speed of the card for the last 30 seconds. You can also specify 0, which will turn off the moving average calculation and will show momentary values (for the last couple of seconds only). Note that the actual hashrate (and the average hashrate over time) is not affected at all by this option. Please add pause after the PhoenixMiner.exe in your start_miner.bat file to see any eventual error messages shown by PhoenixMiner before exiting: timeout/t 50
PhoenixMiner.exe
pause
If you can't make sense of the error message, send them to us and we will try to help. still getting the random CUDA crashing on one of my nvidia rigs with anything newer than 2.8c. PM doesnt restart properly and just hangs with a windows error.
manual restart is possible, but hashrates on certain cards gets severly reduced.
only proper fix is full reboot.
works perfectly and will run hundreds of hours on 2.8c without an issue.
Is there any difference in the behavior if you specify -nvnew 0 (i.e. using the old kernels) on PhoenixMiner 2.9e? Hi. I also have error "unspecified launch failure (719)". I have never seen that before. 2018.04.22:18:14:02.410: main Eth speed: 192.457 MH/s, shares: 9720/9/1, time: 143:42
2018.04.22:18:14:02.410: main GPUs: 1: 32.082 MH/s (1634) 2: 32.079 MH/s (1632/1) 3: 32.071 MH/s (1621) 4: 32.079 MH/s (1616) 5: 32.079 MH/s (1629) 6: 32.067 MH/s (1597)
2018.04.22:18:14:07.511: main Eth speed: 192.456 MH/s, shares: 9720/9/1, time: 143:42
2018.04.22:18:14:07.511: main GPUs: 1: 32.082 MH/s (1634) 2: 32.080 MH/s (1632/1) 3: 32.071 MH/s (1621) 4: 32.079 MH/s (1616) 5: 32.078 MH/s (1629) 6: 32.067 MH/s (1597)
2018.04.22:18:14:07.714: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2018.04.22:18:14:07.750: GPU3 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.22:18:14:07.769: eths Eth: Received: {"jsonrpc":"2.0","id":0,"result":["0xfeea3f97d27b908fa7b3322ae0f78c59b58a2c719acfcfb9a808c481d318a843","0x5683748fa7f53897f1e1a80a8a321d3693761838135be37d1d132c0cd3d7d937","0x000000006df37f675ef6eadf5ab9a2072d44268d97df837e6748956e5c6c2116"]}
2018.04.22:18:14:07.791: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.22:18:14:07.801: GPU3 GPU3 search error: unspecified launch failure
2018.04.22:18:14:07.801: GPU1 GPU1 search error: unspecified launch failure
2018.04.22:18:14:07.807: GPU4 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.22:18:14:07.807: GPU4 GPU4 search error: unspecified launch failure
2018.04.22:18:14:07.807: GPU5 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.22:18:14:07.807: GPU5 GPU5 search error: unspecified launch failure
2018.04.22:18:14:07.855: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.22:18:14:07.855: GPU2 GPU2 search error: unspecified launch failure
2018.04.22:18:14:07.855: GPU6 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.22:18:14:07.856: GPU6 GPU6 search error: unspecified launch failure
2018.04.22:18:14:08.275: wdog Thread(s) not responding. Restarting.
I use PM 2.9e with the following params set miner_params=-nvidia -cdm 2 -cdmport 3333 -cdmpass 123 -minRigSpeed 188 -rmode 2 -tstop 65 -tstart 40 -logsmaxsize 0 I have done one small change some days ago: changed power limit from 65% to 64%. May be it is a problem. Probably has nothing to do with the power limit, especially if it is lower. Thank you for the log, we are trying to reproduce this here but without success so far. We will continue to work on this issue as it seems that it is recurrent on some rigs. since updating to 2.9E I have gotten a random CUDA error on my nvidia 1070 rig, doesnt restart properly and just hangs with a windows error.
I didnt have time this morning to look hard at the log file but a close of the window and relaunch was all it needed
it had been running about 4days(lost power due to storms) with no issues and seems that a few people have had the same problem.
If you can, please send us the end of the log before the crash (the last few pages are enough). These are two separate issues: the error itself, which is probably because the new kernels are more demanding than the old ones, and the miner not restarting. We believed that the second one is solved but apparently not, so we will definitely benefit for some more logs with this problem occurring. Love this miner but the -tt setting doesn't work to well. it will not keep the gpus at the temp I set. This is the only problem I have had with this miner.
Anyway to fix this or ideas?
Thanks
Please tell us what GPUs you have and what AMD drivers you are using? Also, how much is the temperature above the specified temperature (1-2 degrees or more)? A log would be helpful too if you can send it to us. Need some help with this error. PhoenixMiner 2.9e main Available GPUs for mining: main GPU1: Radeon RX 570 Series (pcie 1), OpenCL 2.0, 8 GB VRAM, 32 CUs main GPU2: Radeon RX 570 Series (pcie 2), OpenCL 2.0, 8 GB VRAM, 32 CUs main GPU3: Radeon RX 570 Series (pcie 3), OpenCL 2.0, 8 GB VRAM, 32 CUs main GPU4: Radeon (TM) RX 470 Graphics (pcie  , OpenCL 2.0, 4 GB VRAM, 32 CUs main ADL library initialized Fattal ERROR: Debugger detected I have a rig with 6 MSI RX470...my driver is beta blockchain version. I have error "debugger detected" when I uses Phoenix (claymore is ok). Please fix it. Here is my content of file config.txt
-pool ssl://asia1.ethermine.org:5555 -pool2 asia1.ethermine.org:4444
-wal 0xabcdxcxxxxxxxxxxxxxxxxxxxxxxx.RX470MSI
-proto 2
-coin eth
-cdm 1
-amd
Thanks you and god!
Hopefully, this will be solved in the next version. @PhoenixMiner
Hi, is it possible to implement a command "-retrydelay"? Claymore/ethminer and other miners support this. Thanks.
Yes, we will implement it in the next release. Had the miner run for one day, and towards the end it lost connection to the pool and it tried to reconnect over and over again, and after some time it did manage to reconnect, but once it was connected again my hashrate got very low 2018.04.23:10:16:11.290: main Eth speed: 147.276 MH/s, shares: 2643/0/0, time: 20:38
2018.04.23:10:16:11.290: main GPUs: 1: 29.325 MH/s (549) 2: 29.489 MH/s (497) 3: 29.486 MH/s (537) 4: 29.488 MH/s (516) 5: 29.487 MH/s (544)
2018.04.23:10:16:16.368: main Eth speed: 147.435 MH/s, shares: 2643/0/0, time: 20:38
2018.04.23:10:16:16.368: main GPUs: 1: 29.484 MH/s (549) 2: 29.489 MH/s (497) 3: 29.486 MH/s (537) 4: 29.488 MH/s (516) 5: 29.488 MH/s (544)
2018.04.23:10:16:19.759: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2018.04.23:10:16:19.759: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x8c73706","0x930e7ab371861647a7fe1d91f42d4ec0a63adaa7cdb6b1f93bb0c7e7dfdc1d47"]}
2018.04.23:10:16:21.385: eths Eth: Unable to read pool response: The semaphore timeout period has expired
2018.04.23:10:16:21.385: eths Eth: Reconnecting in 20 seconds...
2018.04.23:10:16:24.494: main GPU1: 59C 23%, GPU2: 59C 28%, GPU3: 59C 36%, GPU4: 59C 30%, GPU5: 59C 35%
2018.04.23:10:16:41.390: unkn Eth: Connecting to ethash pool ssl://eu1.ethermine.org:5555 (proto: EthProxy)
2018.04.23:10:16:41.390: unkn Eth: Can't resolve host ssl://eu1.ethermine.org:5555 - No such host is known
2018.04.23:10:16:41.390: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:16:49.076: GPU3 Unable to submit share - pool disconnected
2018.04.23:10:16:52.372: main GPU1: 59C 23%, GPU2: 59C 28%, GPU3: 59C 35%, GPU4: 60C 30%, GPU5: 59C 35%
2018.04.23:10:17:01.407: unkn Eth: Connecting to ethash pool ssl://eu1.ethermine.org:5555 (proto: EthProxy)
2018.04.23:10:17:01.408: unkn Eth: Can't resolve host ssl://eu1.ethermine.org:5555 - No such host is known
2018.04.23:10:17:01.408: unkn Eth: Giving up after 3 retries, switching to next pool
2018.04.23:10:17:01.408: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:17:14.889: GPU5 Unable to submit share - pool disconnected
2018.04.23:10:17:20.407: main GPU1: 59C 23%, GPU2: 59C 29%, GPU3: 59C 35%, GPU4: 59C 30%, GPU5: 59C 36%
2018.04.23:10:17:21.422: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:17:21.423: unkn Eth: Can't resolve host eu1.ethermine.org:4444 - No such host is known
2018.04.23:10:17:21.423: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:17:23.799: GPU2 Unable to submit share - pool disconnected
2018.04.23:10:17:27.703: GPU3 Unable to submit share - pool disconnected
2018.04.23:10:17:39.574: GPU4 Unable to submit share - pool disconnected
2018.04.23:10:17:41.425: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:17:41.425: unkn Eth: Can't resolve host eu1.ethermine.org:4444 - No such host is known
2018.04.23:10:17:41.425: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:17:48.472: main GPU1: 59C 22%, GPU2: 59C 28%, GPU3: 59C 35%, GPU4: 59C 31%, GPU5: 59C 36%
2018.04.23:10:18:01.427: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:18:01.467: GPU4 Unable to submit share - pool disconnected
2018.04.23:10:18:12.459: unkn Eth: Can't resolve host eu1.ethermine.org:4444 - No such host is known
2018.04.23:10:18:12.459: unkn Eth: Giving up after 3 retries, switching to next pool
2018.04.23:10:18:12.459: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:18:16.506: main GPU1: 59C 22%, GPU2: 59C 29%, GPU3: 59C 35%, GPU4: 59C 30%, GPU5: 59C 36%
2018.04.23:10:18:32.461: unkn Eth: Connecting to ethash pool us1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:18:43.494: unkn Eth: Can't resolve host us1.ethermine.org:4444 - No such host is known
2018.04.23:10:18:43.494: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:18:44.572: main GPU1: 59C 23%, GPU2: 59C 29%, GPU3: 59C 35%, GPU4: 59C 30%, GPU5: 59C 36%
2018.04.23:10:19:03.496: unkn Eth: Connecting to ethash pool us1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:19:12.606: main GPU1: 59C 23%, GPU2: 59C 29%, GPU3: 59C 35%, GPU4: 59C 30%, GPU5: 59C 36%
2018.04.23:10:19:14.528: unkn Eth: Can't resolve host us1.ethermine.org:4444 - No such host is known
2018.04.23:10:19:14.528: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:19:34.530: unkn Eth: Connecting to ethash pool us1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:19:37.353: GPU4 Unable to submit share - pool disconnected
2018.04.23:10:19:39.940: GPU2 Unable to submit share - pool disconnected
2018.04.23:10:19:40.671: main GPU1: 59C 23%, GPU2: 59C 29%, GPU3: 59C 35%, GPU4: 59C 30%, GPU5: 59C 36%
2018.04.23:10:19:45.563: unkn Eth: Can't resolve host us1.ethermine.org:4444 - No such host is known
2018.04.23:10:19:47.875: unkn Eth: Giving up after 3 retries, switching to next pool
2018.04.23:10:19:47.875: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:20:07.880: unkn Eth: Connecting to ethash pool ssl://eu1.ethermine.org:5555 (proto: EthProxy)
2018.04.23:10:20:08.706: main GPU1: 48C 19%, GPU2: 48C 25%, GPU3: 49C 30%, GPU4: 49C 27%, GPU5: 49C 32%
2018.04.23:10:20:18.910: unkn Eth: Can't resolve host ssl://eu1.ethermine.org:5555 - No such host is known
2018.04.23:10:20:18.910: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:20:36.568: main GPU1: 45C 0%, GPU2: 44C 19%, GPU3: 44C 24%, GPU4: 45C 21%, GPU5: 45C 26%
2018.04.23:10:20:38.915: unkn Eth: Connecting to ethash pool ssl://eu1.ethermine.org:5555 (proto: EthProxy)
2018.04.23:10:20:38.915: unkn Eth: Can't resolve host ssl://eu1.ethermine.org:5555 - No such host is known
2018.04.23:10:20:38.915: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:20:58.933: unkn Eth: Connecting to ethash pool ssl://eu1.ethermine.org:5555 (proto: EthProxy)
2018.04.23:10:21:04.602: main GPU1: 46C 0%, GPU2: 43C 0%, GPU3: 42C 19%, GPU4: 43C 0%, GPU5: 42C 20%
2018.04.23:10:21:09.962: unkn Eth: Can't resolve host ssl://eu1.ethermine.org:5555 - No such host is known
2018.04.23:10:21:09.962: unkn Eth: Giving up after 3 retries, switching to next pool
2018.04.23:10:21:09.962: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:21:29.965: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:21:29.965: unkn Eth: Can't resolve host eu1.ethermine.org:4444 - No such host is known
2018.04.23:10:21:29.965: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:21:32.668: main GPU1: 47C 0%, GPU2: 44C 0%, GPU3: 42C 0%, GPU4: 44C 0%, GPU5: 41C 0%
2018.04.23:10:21:49.967: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:22:00.704: main GPU1: 48C 0%, GPU2: 45C 0%, GPU3: 43C 0%, GPU4: 45C 0%, GPU5: 42C 0%
2018.04.23:10:22:00.999: unkn Eth: Can't resolve host eu1.ethermine.org:4444 - No such host is known
2018.04.23:10:22:00.999: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:22:21.001: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:22:21.002: unkn Eth: Can't resolve host eu1.ethermine.org:4444 - No such host is known
2018.04.23:10:22:21.002: unkn Eth: Giving up after 3 retries, switching to next pool
2018.04.23:10:22:21.002: unkn Eth: Reconnecting in 20 seconds...
2018.04.23:10:22:28.767: main GPU1: 49C 0%, GPU2: 46C 0%, GPU3: 44C 0%, GPU4: 46C 0%, GPU5: 43C 0%
2018.04.23:10:22:41.003: unkn Eth: Connecting to ethash pool us1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:22:48.201: eths Eth: Connected to ethash pool us1.ethermine.org:4444 (18.219.59.155)
2018.04.23:10:22:48.201: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_submitLogin","worker":"eth1.0","params":["YourWallet.DESKTOP-RVF2V8O"]}
2018.04.23:10:22:48.330: eths Eth: Received: {"id":999,"jsonrpc": "2.0","result": false,"error": "Invalid user provided"}
2018.04.23:10:22:56.802: main GPU1: 49C 0%, GPU2: 47C 0%, GPU3: 45C 0%, GPU4: 47C 0%, GPU5: 44C 0%
2018.04.23:10:23:24.836: main GPU1: 50C 0%, GPU2: 47C 0%, GPU3: 46C 0%, GPU4: 47C 0%, GPU5: 45C 0%
2018.04.23:10:23:52.698: main GPU1: 50C 0%, GPU2: 48C 0%, GPU3: 47C 0%, GPU4: 48C 0%, GPU5: 46C 0%
2018.04.23:10:24:20.733: main GPU1: 51C 0%, GPU2: 48C 0%, GPU3: 47C 0%, GPU4: 49C 0%, GPU5: 47C 0%
2018.04.23:10:24:28.331: eths Eth: Connection closed by the pool
2018.04.23:10:24:28.331: eths Eth: Reconnecting in 20 seconds...
2018.04.23:10:24:48.338: unkn Eth: Connecting to ethash pool us1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:24:48.527: eths Eth: Connected to ethash pool us1.ethermine.org:4444 (18.219.59.155)
2018.04.23:10:24:48.527: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_submitLogin","worker":"eth1.0","params":["YourWallet.DESKTOP-RVF2V8O"]}
2018.04.23:10:24:48.657: eths Eth: Received: {"id":999,"jsonrpc": "2.0","result": false,"error": "Invalid user provided"}
2018.04.23:10:24:48.806: main GPU1: 51C 0%, GPU2: 49C 0%, GPU3: 48C 0%, GPU4: 49C 0%, GPU5: 47C 0%
2018.04.23:10:25:16.842: main GPU1: 51C 0%, GPU2: 49C 0%, GPU3: 48C 0%, GPU4: 49C 0%, GPU5: 48C 0%
2018.04.23:10:25:44.909: main GPU1: 52C 0%, GPU2: 49C 0%, GPU3: 49C 0%, GPU4: 49C 0%, GPU5: 49C 0%
2018.04.23:10:26:12.944: main GPU1: 52C 0%, GPU2: 50C 0%, GPU3: 49C 0%, GPU4: 50C 0%, GPU5: 49C 0%
2018.04.23:10:26:28.658: eths Eth: Connection closed by the pool
2018.04.23:10:26:28.658: eths Eth: Reconnecting in 20 seconds...
2018.04.23:10:26:40.809: main GPU1: 52C 0%, GPU2: 50C 0%, GPU3: 49C 0%, GPU4: 50C 0%, GPU5: 49C 0%
2018.04.23:10:26:48.669: unkn Eth: Connecting to ethash pool us1.ethermine.org:4444 (proto: EthProxy)
2018.04.23:10:26:48.850: eths Eth: Connected to ethash pool us1.ethermine.org:4444 (18.219.59.155)
2018.04.23:10:26:48.850: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_submitLogin","worker":"eth1.0","params":["YourWallet.DESKTOP-RVF2V8O"]}
2018.04.23:10:26:48.984: eths Eth: Received: {"id":999,"jsonrpc": "2.0","result": false,"error": "Invalid user provided"}
2018.04.23:10:27:08.844: main GPU1: 52C 19%, GPU2: 51C 0%, GPU3: 50C 0%, GPU4: 50C 0%, GPU5: 50C 0%
2018.04.23:10:27:36.912: main GPU1: 46C 17%, GPU2: 51C 0%, GPU3: 50C 0%, GPU4: 50C 0%, GPU5: 50C 0%
2018.04.23:10:28:04.948: main GPU1: 46C 0%, GPU2: 51C 0%, GPU3: 50C 0%, GPU4: 51C 0%, GPU5: 51C 0%
2018.04.23:10:28:28.985: eths Eth: Connection closed by the pool
2018.04.23:10:28:28.985: eths Eth: Giving up after 3 retries, switching to next pool
2018.04.23:10:28:28.985: eths Eth: Reconnecting in 20 seconds...
2018.04.23:10:28:33.015: main GPU1: 46C 0%, GPU2: 51C 0%, GPU3: 50C 0%, GPU4: 51C 0%, GPU5: 50C 0%
2018.04.23:10:28:48.989: unkn Eth: Connecting to ethash pool ssl://eu1.ethermine.org:5555 (proto: EthProxy)
2018.04.23:10:28:49.072: eths Eth: Connected to SSL ethash pool eu1.ethermine.org:5555 (188.165.239.100)
2018.04.23:10:28:49.154: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_submitLogin","worker":"eth1.0","params":["0x8c5797Dcf773E84Cc89B21B5A679864b48588c1D.RT01"]}
2018.04.23:10:28:49.194: eths Eth: Received: {"id":1,"jsonrpc":"2.0","result":true}
2018.04.23:10:28:49.194: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2018.04.23:10:28:49.234: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0xb9fc39ed84eb76af1c19e3a593fe90fe100ae4ef020498e4478e7cf260fd9107","0x3ffd591ffcc97fb5e4150c521510e446bb11563ff632ea15845332648cabc086","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x53c83b"]}
2018.04.23:10:28:49.234: eths Eth: New job #b9fc39ed from ssl://eu1.ethermine.org:5555; diff: 4000MH
2018.04.23:10:28:51.515: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x4aeb047a6538c1133d80078e5c31823ccd9141aa65c747ba910e8e40fd351ac4","0x3ffd591ffcc97fb5e4150c521510e446bb11563ff632ea15845332648cabc086","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x53c83c"]}
2018.04.23:10:28:51.515: eths Eth: New job #4aeb047a from ssl://eu1.ethermine.org:5555; diff: 4000MH
2018.04.23:10:28:53.533: main Eth speed: 121.243 MH/s, shares: 2643/0/0, time: 20:51
2018.04.23:10:28:53.533: main GPUs: 1: 16.083 MH/s (549) 2: 26.284 MH/s (497) 3: 26.301 MH/s (537) 4: 26.286 MH/s (516) 5: 26.290 MH/s (544)
2018.04.23:10:28:58.612: main Eth speed: 121.881 MH/s, shares: 2643/0/0, time: 20:51
2018.04.23:10:28:58.612: main GPUs: 1: 16.224 MH/s (549) 2: 26.410 MH/s (497) 3: 26.418 MH/s (537) 4: 26.413 MH/s (516) 5: 26.416 MH/s (544)
2018.04.23:10:28:59.159: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2018.04.23:10:28:59.199: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x4aeb047a6538c1133d80078e5c31823ccd9141aa65c747ba910e8e40fd351ac4","0x3ffd591ffcc97fb5e4150c521510e446bb11563ff632ea15845332648cabc086","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x53c83c"]}
2018.04.23:10:29:01.050: main GPU1: 51C 0%, GPU2: 55C 23%, GPU3: 55C 23%, GPU4: 56C 23%, GPU5: 55C 23%
2018.04.23:10:29:03.691: main Eth speed: 121.890 MH/s, shares: 2643/0/0, time: 20:51
2018.04.23:10:29:03.691: main GPUs: 1: 16.240 MH/s (549) 2: 26.444 MH/s (497) 3: 26.451 MH/s (537) 4: 26.449 MH/s (516) 5: 26.306 MH/s (544)
2018.04.23:10:29:08.769: main Eth speed: 122.084 MH/s, shares: 2643/0/0, time: 20:51
2018.04.23:10:29:08.769: main GPUs: 1: 16.268 MH/s (549) 2: 26.486 MH/s (497) 3: 26.490 MH/s (537) 4: 26.490 MH/s (516) 5: 26.350 MH/s (544)
2018.04.23:10:29:09.160: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2018.04.23:10:29:09.160: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x74537bd","0x930e7ab371861647a7fe1d91f42d4ec0a63adaa7cdb6b1f93bb0c7e7dfdc1d47"]}
2018.04.23:10:29:09.199: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x4aeb047a6538c1133d80078e5c31823ccd9141aa65c747ba910e8e40fd351ac4","0x3ffd591ffcc97fb5e4150c521510e446bb11563ff632ea15845332648cabc086","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x53c83c"]}
2018.04.23:10:29:09.707: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x263c91b1879b664571e9e8a6019515a64793372393625b990341c2504baf5ff6","0x3ffd591ffcc97fb5e4150c521510e446bb11563ff632ea15845332648cabc086","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x53c83d"]}
2018.04.23:10:29:09.707: eths Eth: New job #263c91b1 from ssl://eu1.ethermine.org:5555; diff: 4000MH
2018.04.23:10:29:10.907: GPU1 Eth: GPU1: ETH share found!
2018.04.23:10:29:10.907: eths Eth: Send: {"id":4,"jsonrpc":"2.0","method":"eth_submitWork","params":["0x15afa8c9719510af","0x263c91b1879b664571e9e8a6019515a64793372393625b990341c2504baf5ff6","0xcb03956db887a1778b735d61a4297714483e2f7ed14d9bc170048d5dd703ce01"]}
2018.04.23:10:29:10.907: eths Eth: Share actual difficulty: 15.6 GH (!)
2018.04.23:10:29:10.947: eths Eth: Received: {"id":6,"jsonrpc":"2.0","result":true}
2018.04.23:10:29:10.947: eths Eth: Received: {"id":4,"jsonrpc":"2.0","result":true}
2018.04.23:10:29:10.947: eths Eth: Share accepted in 40 ms
2018.04.23:10:29:13.848: main Eth speed: 122.072 MH/s, shares: 2644/0/0, time: 20:51
2018.04.23:10:29:13.848: main GPUs: 1: 16.268 MH/s (550) 2: 26.489 MH/s (497) 3: 26.491 MH/s (537) 4: 26.491 MH/s (516) 5: 26.333 MH/s (544)
As you can see the avg. hashrate before the miner lost connection was 147, and after it ended up around 122 mh/s, anyone know why? Of course I only had to restart the miner and it was back to normal again. No big problem, but hoping it won't happen again. You had connectivity issues for a few minutes - your Internet connection was down. However after it was restored, the first few attempts to connect to the next pool failed because you haven't specified your wallet address in the epools.txt file. Open the epools.txt file and change YourWalletAddress to your actual wallet address. The second problem - the lower hashrate after the connection was finally restored - is a driver problem that we can't fix in the miner. However you can use the -minrigspeed parameter to specify a minimal 5 min average speed. For example if you add -minrigspeed 140, PhoenixMiner will restart if the 5 min average speed is not >= 140 Mh/s. |
|
|
|
1063 problem is dag file for ETH on windows10. Claymore fixed this problem for few next epochs. So my question: is it possible to mine eth on 2.9e with 1063 on windows 10 or no?  No, there are no "tricks" in 2.9 for 1060 3GB under Windows 10. We decided that there is no point because you will hit the same memory "wall" in a few weeks. The only real solution is to install Window 7, which will give you almost a year more of ETH mining. Obviously this may not be an option if the GPU is not used exclusively for mining but in that case you can mine an alternative ethash based coin like pirl, exp, etc. (or dual-boot between Win7 and Win 10). Still having issue with 2.9e with Nvidia 1070 not rebooting with reboot .bat when miner crashes 2018.04.18:12:26:33.440: gps0 CUDA error in CudaProgram.cu:168 : unknown error (999)
2018.04.18:12:26:33.440: GPU1 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.446: GPU1 GPU1 search error: unknown error
2018.04.18:12:26:33.462: GPU8 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.462: GPU8 GPU8 search error: unknown error
2018.04.18:12:26:33.462: GPU7 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.462: GPU7 GPU7 search error: unknown error
2018.04.18:12:26:33.468: GPU9 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.468: GPU9 GPU9 search error: unknown error
2018.04.18:12:26:33.482: GPU3 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.482: GPU3 GPU3 search error: unknown error
2018.04.18:12:26:33.482: GPU6 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.482: GPU6 GPU6 search error: unknown error
2018.04.18:12:26:33.494: GPU5 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.494: GPU5 GPU5 search error: unknown error
2018.04.18:12:26:33.495: GPU2 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.495: GPU2 GPU2 search error: unknown error
2018.04.18:12:26:33.535: GPU4 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.535: GPU4 GPU4 search error: unknown error
2018.04.18:12:26:34.158: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2018.04.18:12:26:34.204: wdog Thread(s) not responding. Restarting.
2018.04.18:12:26:34.296: eths Eth: Received: {"jsonrpc":"2.0","id":0,"result":["0x8cc4101785c8e5f40e72a0abf5651c3711a3cafd57475f8ba5c2059146633adc","0x5683748fa7f53897f1e1a80a8a321d3693761838135be37d1d132c0cd3d7d937","0x000000006df37f675ef6eadf5ab9a2072d44268d97df837e6748956e5c6c2116"]}
Thank you for the log, we will try to reproduce it here and fix it for the next release. It would be helpful if you tell us what happens after the program crashes - do you see a Windows error dialog or it just disappears without any messages. Hi Guys, can someone of you please assist? My rig doesn't run stable at all. sys: win 10 pro 8x GTX 1070 from msi, evga and palit 2x PSU - 1000W and 850W page file is set to min. 17000MB and max to 57000MB. Thanks a lot in advance!! thats my command line: :restart
setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
PhoenixMiner.exe -nvidia -rmode 1 -wdog 1 -pool eth-eu1.nanopool.org:9999 -pool2 eth-eu2.nanopool.org:9999 -wal wallet.worker/email -pass x -ftime 10
goto :restart --- Error message: 2018.04.18:22:35:18.778: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0xfb36ccc","0x833075af975ab8559540aabf67696685bcb2ef98724ba75a312e1b545c049307"]}
2018.04.18:22:35:18.815: eths Eth: Received: {"jsonrpc":"2.0","id":0,"result":["0xaadf04a2431360f4228b2d28ab2fec416f0f508c514f75a095dc22e41a5aa0d3","0x5683748fa7f53897f1e1a80a8a321d3693761838135be37d1d132c0cd3d7d937","0x000000006df37f675ef6eadf5ab9a2072d44268d97df837e6748956e5c6c2116"]}
2018.04.18:22:35:19.387: main Eth speed: 263.421 MH/s, shares: 17/0/0, time: 0:06
2018.04.18:22:35:19.387: main GPUs: 1: 32.685 MH/s (3) 2: 32.685 MH/s (3) 3: 32.677 MH/s (2) 4: 32.686 MH/s (1) 5: 32.684 MH/s (0) 6: 32.676 MH/s (3) 7: 34.652 MH/s (1) 8: 32.677 MH/s (4)
2018.04.18:22:35:24.466: main Eth speed: 263.422 MH/s, shares: 17/0/0, time: 0:06
2018.04.18:22:35:24.466: main GPUs: 1: 32.685 MH/s (3) 2: 32.687 MH/s (3) 3: 32.676 MH/s (2) 4: 32.686 MH/s (1) 5: 32.685 MH/s (0) 6: 32.676 MH/s (3) 7: 34.651 MH/s (1) 8: 32.677 MH/s (4)
2018.04.18:22:35:25.426: eths Eth: Received: {"jsonrpc":"2.0","id":0,"result":["0x169cf1c7d1e89f771cc626178603a4c89647bdd91bf2c762b63cce1cf1e0eca4","0x5683748fa7f53897f1e1a80a8a321d3693761838135be37d1d132c0cd3d7d937","0x000000006df37f675ef6eadf5ab9a2072d44268d97df837e6748956e5c6c2116"]}
2018.04.18:22:35:25.426: eths Eth: New job #169cf1c7 from eth-eu1.nanopool.org:9999; diff: 10000MH
2018.04.18:22:35:26.163: GPU3 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.18:22:35:26.173: GPU3 GPU3 search error: unspecified launch failure
2018.04.18:22:35:26.185: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.18:22:35:26.185: GPU1 GPU1 search error: unspecified launch failure
2018.04.18:22:35:26.200: GPU7 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.18:22:35:26.200: GPU7 GPU7 search error: unspecified launch failure
2018.04.18:22:35:26.201: GPU5 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.18:22:35:26.201: GPU5 GPU5 search error: unspecified launch failure
2018.04.18:22:35:26.216: GPU4 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.18:22:35:26.216: GPU4 GPU4 search error: unspecified launch failure
2018.04.18:22:35:26.216: GPU6 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.18:22:35:26.216: GPU6 GPU6 search error: unspecified launch failure
2018.04.18:22:35:26.232: GPU8 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.18:22:35:26.232: GPU8 GPU8 search error: unspecified launch failure
2018.04.18:22:35:26.263: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.18:22:35:26.263: GPU2 GPU2 search error: unspecified launch failure
2018.04.18:22:35:26.404: wdog Thread(s) not responding. Restarting.
2018.04.18:22:35:28.779: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]} First, if the first GPU to fail is (almost) always the same, lower its memory overclock (your hasrates are pretty high for 1070). Also, the restart loop your .bat file is not a good idea when using anything else than -rmode 0 because if PhoenixMiner.exe restarts by itself, your .bat file will start another instance of the miner and you will have two instances of PhoenixMiner trying to mine using the same GPUs, which obviously will lead to problems. So, either remove goto :restart or use -rmode 0 in your .bat file. Hi first time i try to switch from claymore for mining CLO (Callisto) (Ethash algorythm) and impossible to connected to the pool apparently... Here's my logs : 2018.04.18:22:54:36.527: main Phoenix Miner 2.9e Windows/msvc - Release
2018.04.18:22:54:36.527: main Cmd line:
2018.04.18:22:54:36.527: main config.txt: -pool clo.2miners.com:3030 -wal 0x4C79A838Eb620E22218A77a2bDc5651b549ea77e.RX480
2018.04.18:22:54:36.527: main No CUDA driver found
2018.04.18:22:54:38.593: main Available GPUs for mining:
2018.04.18:22:54:38.593: main GPU1: Radeon (TM) RX 480 Graphics (pcie 1), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.593: main GPU2: Radeon (TM) RX 480 Graphics (pcie 3), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.593: main GPU3: Radeon (TM) RX 480 Graphics (pcie 4), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.593: main GPU4: Radeon (TM) RX 480 Graphics (pcie 5), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.593: main GPU5: Radeon (TM) RX 480 Graphics (pcie 6), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.593: main GPU6: Radeon (TM) RX 480 Graphics (pcie 7), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.681: main ADL library initialized
2018.04.18:22:54:39.035: main Listening for CDM remote manager at port 3333 in read-only mode
2018.04.18:22:54:39.035: main Eth: the pool list contains 2 pools
2018.04.18:22:54:39.035: main Eth: primary pool: clo.2miners.com:3030
2018.04.18:22:54:39.035: main Starting GPU mining
2018.04.18:22:54:39.035: main Matched GPU1 to ADL adapter index 64 (method 1)
2018.04.18:22:54:39.262: main GPU1: Created ADL monitor for adapter 64; overdrive version: 7
2018.04.18:22:54:39.262: main GPU1: using AMD driver ver 18.3.4
2018.04.18:22:54:39.262: main Matched GPU2 to ADL adapter index 16 (method 1)
2018.04.18:22:54:39.431: main GPU2: Created ADL monitor for adapter 16; overdrive version: 7
2018.04.18:22:54:39.431: main GPU2: using AMD driver ver 18.3.4
2018.04.18:22:54:39.431: main Matched GPU3 to ADL adapter index 32 (method 1)
2018.04.18:22:54:39.528: main GPU3: Created ADL monitor for adapter 32; overdrive version: 7
2018.04.18:22:54:39.528: main GPU3: using AMD driver ver 18.3.4
2018.04.18:22:54:39.529: main Matched GPU4 to ADL adapter index 48 (method 1)
2018.04.18:22:54:39.615: main GPU4: Created ADL monitor for adapter 48; overdrive version: 7
2018.04.18:22:54:39.615: main GPU4: using AMD driver ver 18.3.4
2018.04.18:22:54:39.615: main Matched GPU5 to ADL adapter index 80 (method 1)
2018.04.18:22:54:39.692: main GPU5: Created ADL monitor for adapter 80; overdrive version: 7
2018.04.18:22:54:39.692: main GPU5: using AMD driver ver 18.3.4
2018.04.18:22:54:39.692: main Matched GPU6 to ADL adapter index 0 (method 1)
2018.04.18:22:54:39.785: main GPU6: Created ADL monitor for adapter 0; overdrive version: 7
2018.04.18:22:54:39.785: main GPU6: using AMD driver ver 18.3.4
2018.04.18:22:54:39.786: wdog Starting watchdog thread
2018.04.18:22:54:39.786: main Eth: Connecting to ethash pool clo.2miners.com:3030 (proto: EthProxy)
2018.04.18:22:54:39.872: eths Eth: Connected to ethash pool clo.2miners.com:3030 (95.213.255.168)
2018.04.18:22:54:39.872: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_submitLogin","worker":"eth1.0","params":["0x4C79A838Eb620E22218A77a2bDc5651b549ea77e.RX480"]}
2018.04.18:22:54:39.940: eths Eth: Received: {"id":1,"jsonrpc":"2.0","result":null,"error":{"code":-1,"message":"Invalid login"}}
2018.04.18:22:54:39.940: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2018.04.18:22:54:39.940: eths Eth: Connection closed by the pool
2018.04.18:22:54:39.940: eths Eth: Reconnecting in 20 seconds...
2018.04.18:22:54:39.987: main GPU1: 31C 66%, GPU2: 32C 66%, GPU3: 40C 73%, GPU4: 30C 66%, GPU5: 34C 66%, GPU6: 32C 66% And this is my BAT start file : setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
PhoenixMiner.exe -pool clo.2miners.com:3030 -wal 0x4C79A838Eb620E22218A77a2bDc5651b549ea77e.RX480 -pass x -coin etc
Any help would be appreciated Thanks. The pool doesn't like your wallet address. Remove the worker name from the wallet address and use the same command line: PhoenixMiner.exe -pool clo.2miners.com:3030 -wal 0x4C79A838Eb620E22218A77a2bDc5651b549ea77e -worker RX480 -pass x -coin ubq Note that the worker name is specified separately in -worker, and the -coin is changed to ubq because it has much smaller DAG than ETC. Hi all, have rig with x6 RX580 8GB(x3 XFX GTS and x3 STRIX TOP Gaming), when i start miner with parameter -tt 64, miner set only for 3 cards XFX (Claymore work fine for all gpu). Help pls( Screen: https://i.imgur.com/LPRmrWq.png Please send us the log file (the first few minutes after starting are enough). Obviously there is some problem when initializing ADL on your STRIX cards. We had similar problem with an MSI card that wouldn't accept any overclocking settings via ADL calls but we have to see to log to be sure. Defect Description: reboot.bat fails to load config file
Command Output:
GPU7 not responding
Thread(s) not responding. Restarting.
Eth speed: 215.464 MH/s, shares: 216/0/0, time: 1:00
GPUs: 1: 31.246 MH/s (24) 2: 30.626 MH/s (34) 3: 30.510 MH/s (34) 4: 31.255 MH/s (33) 5: 30.694 MH/s (27) 6: 31.212 MH/s (21) 7: 0.000 MH/s (24) 8: 29.920 MH/s (19)
C:\dev\Ethereum\PhoenixMiner_2.9e>PhoenixMiner.exe config-ms05.bat
Phoenix Miner 2.9e Windows/msvc - Release
-----------------------------------------
Unable to open configuration file config-ms05.bat
C:\dev\Ethereum\PhoenixMiner_2.9e>pause
Press any key to continue . . .
reboot.bat:
----
PhoenixMiner.exe config-ms05.bat
pause
----
The initial startup of the miner is started using the same command: PhoenixMiner.exe config-ms05.bat
Workaround: Updated reboot.bat to:
----
echo Last miner reboot at: %DATE% %TIME% >>reboot.log
copy config-ms05.txt config-ms05-reboot.txt
PhoenixMiner.exe config-ms05-reboot.txt
pause
----
Thank you for the report. We will try to reproduce it and fix it for the next release. |
|
|
|
Hi. What about Linux version?
Coming in the near future. seems ok, but I encountered a problem, I use the remote manager of claymore, and works on everything, but with version 2.9e and only sees the AMD, the gtx says that they are not connected, instead turn quietly, you happen?  Check if the port you are using for remote monitoring is free - you can't have more than one program on the same rig using the same port for remote management. What are we still happy with phoenixminer 2.9.e the stale shares are back again, while it was with the 2.9 .d away the joy is so short-lived unfortunately.
There are no changes that affect stale shares at 2.9e, so it must be bad luck (or pool issues). The internal stale shares in 2.9 are close to zero (less than 0.1% to be exact) and practically all stale shares are because of a) latency of your connection to the pool, and b) latency of the pool itself. i'm back to 2.8C , i had better hashrate with that ! RX580 8Gb MSI Gameing X
You may need to try -clkernel 2 and/or different -gt values to achieve optimal hashrate with the new kernels. Otherwise, you can go back to using the old kernels with -clnew 0. Unfortunately still crashes after CUDA errors with Nvidia gtx 1070 cards. The last one that restart well after CUDa errors is 2.7c for me.
It would be very helpful if you could send as a log file of one of the crashes that doesn't restart the miner. 2.9e should catch all types of error and exceptions in the GPU threads and reboot instead of crashing. Perhaps one of the other threads has crashed but we can't know for sure without a log (just the last few pages before the crash). Hi developers, is it possible to provide information about power usage? By rig and by a separate card. Or at least bu rig?
Theoretically, the GPUs report some kind of power usage but we have observed that it is very far from the actual numbers (even when taking into account the efficiency of the PSUs). So, while we can report them, they are at best grossly incorrect, and at worst - misleading. Hi guys, I would like to know, if you run two or more instances of Phoenix Miner, will the mining speed of those instances be reduced compared to running only on one instance? I am planning on running at least two instances of Phoenix Miner. Lastly, when running another instance of Phoenix Miner, what is the best practice, should I just create another batch file in the same folder or create a new folder with a another executable file of Phoenix Miner? I am currently using two batch files with one executable file in a single folder and it is working fine. Thank you in advance for any replies. There shouldn't be any noticeable performance decrease from running few instances but the memory usage will be higher and the chance for stale shares may be elevated slightly due to all instances receiving new job(s) at about the same time. It is best to copy the program at two different folders (if nothing else, at least you will be able to clearly separate the log files this way) and use different config.txt and epools.txt files. You can place the options in the config.txt and the pools in epools.txt. Then the bat files will contain just: Looks like 2.9e on 6 GTX-1070 is less profitable then 2.8c. My params are the following -nvidia -cdm 2 -cdmport 3333 -cdmpass <password> -minRigSpeed 188 -rmode 2 -tstop 65 -tstart 40 PM 2.8c gives me 191.65MH and costs 750W (1MH costs 3.913W) PM 2.9e gives me 192.5MH and costs 760W (1MH costs 3.948W) It is not critical, of course, but... Good news: PM 2.9e provides more stable hashrate then PM 2.8c or any Claymore or any Ethminer. I have 0 stale shares during 1:25 (1 hour, 25 minutes). The deceased stale shares alone should be more than enough to offset the power difference. You can still use -nvnew 0 to revert to the old CUDA kernels but this will increase stale shares significantly. Tested 2.9e for one day and here's my results:
x6 RX 580 4GB Sapphire (Stable 188mh/s - same hashrate as 2.8c)
x6 RX 570 4GB Armor (Very unstable 185mh/s - lower hashrate than 2.8c and it was more stable compared to 2.9e)
x6 RX 570 8GB Sapphire (Stable 193mh/s - lower hashrate than 2.8c)
Experiencing high stale shares on my RX 570 Armor Rig which wasn't the case in version 2.8c
Hopefully next update will be better.
The lower hashrates are probably because you have to use different -gt values with the new kernles (or try -clkernel 2). The higher stale shares are definitely caused by something outside the miner, as in 2.9 the internal stale shares are practically eliminated. My phoenixminer 2.9e always freeze when the miner trying to connect ethermine for dev fee mining. Anyone else experiencing the same?
What coin you are mining? Most probably the miner can't determine it automatically and then it defaults to ETH for devfee. If you GPU(s) don't have enough memory for ETH DAG, the miner can crash. To avoid this, use the -coin command-line option to specify the coin that you are mining and PhoenixMiner will use it for devfee, avoiding the expensive DAG regeneration. Help Me! I have a 1060 6gb card running with 2.8c then it's normal. MSI: Pow 65 core -400 mem 700. But when using 2.9e with MSI as above it error: 2018.04.17:03:23:55.234: GPU5 CUDA error in CudaProgram.cu:264 : an illegal instruction was encountered (715)
2018.04.17:03:23:55.243: GPU5 GPU5 search error: an illegal instruction was encountered
2018.04.17:03:23:55.254: GPU6 CUDA error in CudaProgram.cu:124 : an illegal instruction was encountered (715)
2018.04.17:03:23:55.254: GPU6 GPU6: Failed to initialize search buffers: an illegal instruction was encountered
2018.04.17:03:23:55.254: GPU6 GPU6 initMiner error: Unable to initialize CUDA miner
2018.04.17:03:23:55.271: GPU4 CUDART error in CudaProgram.cu:127 : an illegal instruction was encountered (73)
2018.04.17:03:23:55.271: GPU3 CUDART error in CudaProgram.cu:127 : an illegal instruction was encountered (73)
2018.04.17:03:23:55.271: GPU3 GPU3 initMiner error: an illegal instruction was encountered
2018.04.17:03:23:55.271: GPU4 GPU4 initMiner error: an illegal instruction was encountered
2018.04.17:03:23:55.271: GPU1 CUDART error in CudaProgram.cu:127 : an illegal instruction was encountered (73)
2018.04.17:03:23:55.271: GPU1 GPU1 initMiner error: an illegal instruction was encountered
2018.04.17:03:23:55.272: GPU2 CUDART error in CudaProgram.cu:127 : an illegal instruction was encountered (73)
2018.04.17:03:23:55.272: GPU2 GPU2 initMiner error: an illegal instruction was encountered
2018.04.17:03:23:55.518: wdog Thread(s) not responding. Restarting. Please help me adjust the MSI so that I get the highest productivity on the 2.9e. Thanks very much! You may need to decrease the memory overclock. The new CUDA kernels are utilizing the GPU more fully, which may lead to such problems when the overclocks are on the edge of stability. Another possible remedy is to try and force the cards to be in P0 performance state instead of P2, which by some accounts makes them more stable at high overclocks. |
|
|
|
The -logsmaxsize option defines the max size of all log files, not a single file, so 200 MB should be adequate if you want to keep a history for the last few weeks (or months). We don't have a limit of the size of a single logfile but it may be added in the future. Strange solution. Never seen that. For example in java there is RollingFileAppender ( https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/RollingFileAppender.html) which creates new log file when current file has reached limit size. I waited to have the same functionality, and I think that not only me. If the current behaviour is like you have described, then can you please to use parameter 0 as recomendation do not delete logs (so limit is absent). It already works like that: -logsmaxsize 0 turns off the automatic removal of oldest log files on startup. As for the limit on the size of individual log files - this is good idea and may be implemented in the future versions of the miner. After running PM 2.9d for few days yes it "SHOWS" higher hash rate but the time it takes to CLEAR a block for me INCREASED as apposed to running CL some would say difficulty increased Id have to run it for 2 weeks to collect data and then switch back to CL and collect more data to eliminate that theory As we stated many times, the best way to compare is to see the shares (assuming the same share difficulty!) over some time period (not too short to avoid luck being too much of a factor). Note that PhoenixMiner already does these calculations for you and shows you the effective hashrate, even if you switch to pools with different difficulty. 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. Anyone else got monitoring scripts working with Phoenix? Any idea what could be going wrong? You have to add new line (\n) after the end of your JSON request. |
|
|
|
PhoenixMiner 2.9e is officially released. Note that there are changes since 2.9d, so if you are running 2.9d, you should upgrade to this version. Here is the list of changes since the last beta version 2.9e (the full list of changes since the last official release can be seen in the first post of this thread): - Added detection of AMD Compute mode in the supported drivers and GPUs. The detection is performed when the miner starts and if the Compute mode is off on some of the GPUs, you will get warning messages.
- Added console command 'y' to turn on the AMD Compute mode if it is not turned on on some of the cards.
- Small improvement in the -logfile option: now you can insert $ chararcter in the name, which will be removed from the name but will force the miner to overwrite the log file on each startup, instead of appending to it.
- Fixed a problem with miner restart on some CUDA errors with Nvidia cards when the miner crashes instead of restarting.
- Some other small fixes and changes
You can download 2.9e from here: (MEGA links are no longer active) Checksums to verify your download: File: PhoenixMiner_2.9e.zip
SHA-1: e2b9c72e561ac0fdb4e3c9ebddd7d703a35da36c
SHA-256: 9817c89623025cf392a4e800a41cff96a87eee02e241d9f08d62dc43e0975e96
SHA-512: 33c78a73a53791c01bbfff2ad830ffd40d4007f69ca329300815ab1c189f744aafdc6683033cfcb0315db7f322e6dee44181b9dff2922b1fb408b0f04dba163b We are now working on 3.0, which will include auto-tuning capabilities and more.
|
|
|
|
What is the best version for nVidia driver to run PhoenixMiner 2.8c or 2.9d?
I open multiple instances to run claymore on RX580 and Phoenix on GTX1070/1060 on the same rig, right?
Frankly, we just install the latest Nvidia drivers whenever we set up a new mining rig. Some of our test rigs run quite old driver versions too, and we don't see much difference. As always, YMMV so if you may find that one driver works better for you. In any case the speed difference won't be anything to write home about but there may be difference in stability. Yes, you can use multiple instances of both Claymore and PhoenixMiner on the same rig. Just use the -di (in claymore) and -gpus (in PhoenixMiner) to force them to use different GPUs. Also you may want to change the remote management port from the default 3333 as only one of the instances will be able to use it. Update and comparison
2.9d is actually a bit of a loss in hashrate. vega 64 virtually no change from 2.8c. fury x are lower than 2.8c 34.5 avg now
the best speed was 2.8b but stales now are virtually nil.
Regards
You can try higher -gt values with the Fury cards with the new kernels. We found optimal performance in some of our Fury cards at about -gt 150. To the Developer: For some reason phoenixminer will NOT AUTO RUN using regedit but Claymore does ? what gives I set up all my rigs to auto log on auto mine - in case power loss or windows update or some other bulsh*t etc......... works fine with claymore. If I input phoenixminer.exe absolutely NOTHING HAPPENS AFTER REBOOT ..................... WTF....................................... PhoenixMiner looks for config.txt and epools.txt in the current folder, which may not be the folder where the PhoenixMiner.exe is placed. In your case probably you are running PhoenixMiner.exe but the current folder is not the folder where your config.txt and epools.txt files are placed so it just exits. We will make changes in the next release and if the program is started without any options, it will look for config.txt not only in the current folder but also in the folder where the PhoenixMiner.exe is placed. Alternatively, if a full path to config.txt is specified, we will look for epools.txt in the same folder. To fix the problem with the current release, create a small .bat file with the following content: REM If PhoenixMiner is on other drive than C:, change the drive bellow
C:
REM Change the folder bellow to the FULL PATH (i.e. starting from the root directory) where PhonixMiner.exe is placed
cd C:\MiningSoftware\PhoenixMiner2.9d\
PhoenixMiner.exe
pause
Then you put this .bat file in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run instead of directly running PhoenixMiner.exe. Phoenixminer is possible stale shares which GPU - >> total ?? and gpu 1 /? gpu2 /? gpu3 /? etc. It is easier to change settings of the GPU that causes the most stales. http://www.resimag.com/p1/e9d607fe24.jpeg We can show stales by GPU but it is not really a meaningful statistic (as opposed to incorrect shares which are shown by GPU). In the latest version the internal stale shares should be very low (less than 0.1% in the long run) so only the external stales remain, which are completely outside the control of (and completely undetectable by) the miner. The screen output for each line of the GPU summary you have a list of all GPUs and the shares found for each.(If and when a stale is found then beside each count you would have a secondary total.)
GPU 1 - (105/3) in this case the 105 is found shares, the 3 are the stales)
Make sense now?
Actually, these are the incorrect shares, not the stales. As stated above, the stales are not shown for each GPU (only as total number). The connection issue still persist.
if you reboot router with dynamid ip
the miner cant connect to ethermine.org pool
you need to manual close and relaunch the program to connect
70-80% of rigs have this problem occur
while some can connect after router reboot
We will try to reproduce this. At the first glance this shouldn't happen as each connection attempt is done independently for the previous one - new DNS lookup, new TCP socket, etc., so the changed IP shouldn't be of any importance. Report of first 24hrs on PhoenixMiner 2.9d (migrated from 2.8c). Environment: 52 GPU (45x RX580/8GB, 7x 1070/8GB) in four rigs of 13 cards each. Results: - Hashing rate: Increased a bit: Before: 1.630 GH/s, now 1.633 GH/s ~ 0.12% increase. The increase is most notable on Nvidia cards. - Power Consumption: Decreased for few watts: e.g. on one rig from 1630 to 1620W on average, measured on the wall. A slight temperature drop in line with power consumption. - Stale share: Increased a bit as reported by the ethermine.org pool, before 3-4%, now 4-5% with drops to 2% occasionally. Was < 3% on Claymore 11.5 - Stability: Stable, occasional hashing drops on some cards e.g. form 31MH/s to 24 for a 10-20 sec, then recovering back to normal 31 MH/s. Did not observe that before. Comments: - In my opinion the "-logsmaxsize <n> Maximum size of the logfiles in MB. The default is 200 MM"; The default value of 200Mb is to high and cannot be normally edited by most editors. The default should be no more than e.g. 10MB or if you must, 50Mb. - Missing a feature: Auto tune of the GPU tuning parameter /-gt/; Similar to Claymore -dcri auto tune). - The 2.9d is officially released as an unofficial version with full support. Really Why not just stick to the usual sw naming convention like calling it "alpha"; a limited test version that might get new functionalities until released as final. Verdict: Works like a charm out of the box. Thumbs up! Thank you for sharing your results. The -logsmaxsize option defines the max size of all log files, not a single file, so 200 MB should be adequate if you want to keep a history for the last few weeks (or months). We don't have a limit of the size of a single logfile but it may be added in the future. We will add auto-tuning in the next version (3.0). Well, it is more like a beta in that it should be stable enough for normal usage.  However it is not recommended for deployment on large farms as it is not tested enough. But you are quite right that the naming convention is not ideal. We will probably switch to two channels: stable and beta, and each version will be clearly marked to avoid any confusion if it is stable or beta version. So, no love for Baffin at all?
Please try to use -clkernel 2 for Baffin or try to change the -gt values. We will add auto-tuning in the next version (3.0), which will make the fining of optimal parameters easier. |
|
|
|
Hi, just downloaded 2.9b and copied over my startup.bat but for some reason i am getting ID "0" in the mining pool overview instead of the worker name specified in the command. http://beta-pirl.pool.sexy/#/account/0x7D7764c9D0EC722e246E1b717A7e11Aad08ACe9fmy start.bat file setx GPU_FORCE_64BIT_PTR 0 setx GPU_MAX_HEAP_SIZE 100 setx GPU_USE_SYNC_OBJECTS 1 setx GPU_MAX_ALLOC_PERCENT 100 setx GPU_SINGLE_ALLOC_PERCENT 100 PhoenixMiner.exe -pool beta-pirl.pool.sexy:10052 -wal 0x7D7764c9D0EC722e246E1b717A7e11Aad08ACe9f -worker miner1 -coin pirl -nvidia -minRigSpeed 120 -log 0 -cdm 1 -cdmport 3333 -rmode 2 -mi 14 pause Thank you for reporting this, the problem is fixed and an updated beta (2.9d) has now replaced 2.9b. You can find it at the same location (see this post: https://bitcointalk.org/index.php?topic=2647654.msg34449237#msg34449237). Could performance on Baffin (RX 460/560) be improved?
I have a system with a Baffin card and got around 11 Mh/s while Claymore's gives 14 Mh/s.
Try to change the -gt parameter (the default is 15), or try using the command line option -clkernel 2 (only works with the latest beta version few posts above). |
|
|
|
I really like this miner. It uses slightly more power then Claymore, but the interface is much better. Maybe a noob question or maybe it has been asked before, but what are the 'degrees' with the exclamation marks ( !!! ). Is it like GH = ( ! ) and TH = ( !!! )?
This is just a visual indicator of how big is the share difficulty. One exclamation mark is used when the share is between 10 GH and 10 TH. Three exclamation marks are used when the share is difficulty 10 TH or more. For comparison, the current difficulty of ETH network is about 3100 TH. seems to be just the miner 2.8c version. been stable since the switch back to 2.8b
There are big changes in CUDA code in 2.9b so it will hopefully solve the problem. If not, we are planning to introduce a -nvf parameter for CUDA similar to the new -clf for AMD cards, that may help some GPUs to be stable. |
|
|
|
EDIT: Replaced 2.8b with 2.8d, the only difference being the fix for the worker problem on some pools.First beta of 2.9 branch is here - PhoenixMiner 2.9d. It can be downloaded from: (MEGA links are no longer active) Here are the checksums to verify the download: File: PhoenixMiner_2.9d.zip
SHA-1: 60c87b5015607e6f23b05b6220e2abf79eb7b8de
SHA-256: fa32a6694c1eeff8e3f543a878fff1996da781b6a445aeeae532d07ab1c3d71e
SHA-512: a3347c67616ada2add364adb34b4ca6a0fe973fc8406942b4d51123c454b0d608557360343b6ccfc1d2a88df2a6be126f7e9b1995bbd10dd9858a1559fb78bf7
Note that this is not an official release. The changes are: - Substantial improvements in the kernels for AMD GPUs, providing higher hashrate, lower percentage of stale shares, and slightly lower power consumption. The new kernels are used by default for AMD GPUs. You can still revert to using the old kernels with -clnew 0
- Note that the optimal -gt values for the new kernels may be different than before (but should be in the same ballpark)
- Added optimized kernels for AMD RX550, based on the Baffin kernels (but we can't test them as our RX550 turned out to use Baffin cores, so please let us know if they work for you)
- Alternative (-clkernel 2) kernels for AMD RX550, RX460/560, and 285/380. Just like the alternative kernels for Polaris (RX470/480/570/580), sometimes these can give you higher hashrate than then default (-clkernel 1) optimized kernels.
- New Nvidia kernels, providing higher hashrate and much lower percentage of stale shares. You can still revert to using the old CUDA kernels with -nvnew 0. The mining intensity (-mi) is by default 12 when using the new Nvidia kernels and 10 for the old kernels
- New -clf parameter to control how often the OpenCL (AMD) kernels will sync (0 - never, 1 - sometimes (default), 2 - always). Try this if you have unstable hashrate on AMD GPU but in general, it is best to leave it alone
- Added -logfile parameter to be able to set the name of the logfile. If you place an asterisk (*) in the logfile name, it will be replaced by the current date/time to create a unique name every time PhoenixMiner is started. If there is no asterisk in the logfile name, the new log entries will be added to the same file
- Added -logdir parameter to specify different folder for the logfiles
- Added -logsmaxsize parameter to specify the max size of the log files (200 MB by default)
- Many small fixes and changes
Let us know if you have any stability or other problems with the new release as it has big changes in many important areas.
|
|
|
|
Can anybody tell me why phoenix.exe above 2.7c crashes in 5 seconds when starting on one rig and on my other rig it runs perfect also with latest version.
Both rigs are identical with 6 gtx1070 8gb cards each and windows 10.
I didn’t read anything here about this problem.
Please send us the log file and check if the miner shows "Debugger detected" error before crashing (the "Debugger detected" error will not be printed in the log file). If the console window closes fast after the program crashes, please put a pause command after the line that starts PhoenixMiner in your .bat file (or use the start_miner.bat file that is in the PhoenixMiner .zip file, which already has a pause command). If the error is "Debugger detected" try to add -nvidia to your command line. Thanks for helping me what to do! I hope the information below can help. My bat file: PhoenixMiner.exe -pool ssl://eu1.ethermine.org:5555 -wal WALLET.Rig1 -proto 3 -nvidia -mi 10 pause My log file: 17629:08:48:59.095: main Phoneix Miner 2.8c Windows/msvc - Release
17629:08:48:59.095: main Cmd line: -pool ssl://eu1.ethermine.org:5555 -wal 0x71378f9Ddf59B762CcA6F6E072266fB543ACc26E.Rig1 -proto 3 -nvidia -mi 10
17629:08:48:59.684: main Available GPUs for mining:
17629:08:48:59.684: main GPU1: GeForce GTX 1070 (pcie 1), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17629:08:48:59.684: main GPU2: GeForce GTX 1070 (pcie 3), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17629:08:48:59.684: main GPU3: GeForce GTX 1070 (pcie 4), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17629:08:48:59.684: main GPU4: GeForce GTX 1070 (pcie 5), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17629:08:48:59.684: main GPU5: GeForce GTX 1070 (pcie 6), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17629:08:48:59.684: main GPU6: GeForce GTX 1070 (pcie 7), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17629:08:48:59.687: main NVML library initialized
17629:08:48:59.963: main Listening for CDM remote manager at port 3333 in read-only mode
17629:08:48:59.963: main Eth: the pool list contains 3 pools
17629:08:48:59.963: main Eth: primary pool: ssl://eu1.ethermine.org:5555
17629:08:48:59.963: main Starting GPU mining
17629:08:48:59.964: wdog Starting watchdog thread
17629:08:49:00.134: main Eth: Connecting to ethash pool ssl://eu1.ethermine.org:5555 (proto: QtMiner)
17629:08:49:00.192: eths Eth: Connected to SSL ethash pool eu1.ethermine.org:5555 (46.105.121.53)
17629:08:49:00.277: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_login","params":["0x71378f9Ddf59B762CcA6F6E072266fB543ACc26E.Rig1"]}
17629:08:49:00.310: eths Eth: Received: {"id":1,"jsonrpc":"2.0","result":true}
17629:08:49:00.311: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
17629:08:49:00.343: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0xfb9bd11be49c953953040d441c85cc39d486c692c11881300ec0c263f449df0c","0xf14c514effe89b62170940fc9de2265eb7e0d18aae7c8198ee5788b20b90e2af","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x526cbc"]}
17629:08:49:00.343: eths Eth: New job #fb9bd11b from ssl://eu1.ethermine.org:5555; diff: 4000MH
17629:08:49:00.343: GPU1 GPU1: Starting up... (0)
17629:08:49:00.344: GPU1 Eth: Generating light cache for epoch #180
17629:08:49:00.344: main GPU1: 50C 45%, GPU2: 47C 44%, GPU3: 46C 43%, GPU4: 49C 44%, GPU5: 46C 43%, GPU6: 43C 41%
17629:08:49:00.360: GPU2 GPU2: Starting up... (0)
17629:08:49:00.376: GPU3 GPU3: Starting up... (0)
17629:08:49:00.391: GPU4 GPU4: Starting up... (0)
17629:08:49:00.408: GPU5 GPU5: Starting up... (0)
17629:08:49:00.423: GPU6 GPU6: Starting up... (0)
17629:08:49:02.450: GPU3 GPU3: Allocating DAG (2.42) GB; good for epoch up to #182
17629:08:49:02.566: GPU3 GPU3: Allocating light cache buffer (38.7) MB; good for epoch up to #182
17629:08:49:02.693: GPU3 GPU3: Generating DAG for epoch #180
17629:08:49:02.828: GPU5 GPU5: Allocating DAG (2.42) GB; good for epoch up to #182
17629:08:49:02.835: GPU1 GPU1: Allocating DAG (2.42) GB; good for epoch up to #182
17629:08:49:02.839: GPU2 GPU2: Allocating DAG (2.42) GB; good for epoch up to #182
17629:08:49:02.922: GPU1 GPU1: Allocating light cache buffer (38.7) MB; good for epoch up to #182
17629:08:49:02.955: GPU5 GPU5: Allocating light cache buffer (38.7) MB; good for epoch up to #182
17629:08:49:02.960: GPU2 GPU2: Allocating light cache buffer (38.7) MB; good for epoch up to #182
17629:08:49:02.978: GPU4 GPU4: Allocating DAG (2.42) GB; good for epoch up to #182
17629:08:49:02.994: GPU6 GPU6: Allocating DAG (2.42) GB; good for epoch up to #182
17629:08:49:03.049: GPU1 GPU1: Generating DAG for epoch #180
17629:08:49:03.055: GPU4 GPU4: Allocating light cache buffer (38.7) MB; good for epoch up to #182
17629:08:49:03.065: GPU5 GPU5: Generating DAG for epoch #180
17629:08:49:03.069: GPU2 GPU2: Generating DAG for epoch #180
17629:08:49:03.077: GPU6 GPU6: Allocating light cache buffer (38.7) MB; good for epoch up to #182
17629:08:49:03.167: GPU4 GPU4: Generating DAG for epoch #180
17629:08:49:03.184: GPU6 CUDA error in CudaProgram.cu:220 : unspecified launch failure (719)
17629:08:49:03.184: GPU1 CUDART error in CudaProgram.cu:123 : unspecified launch failure (4)
17629:08:49:03.184: GPU6 GPU6 initMiner error: unspecified launch failure
17629:08:49:03.184: GPU1 GPU1 initMiner error: unspecified launch failure
17629:08:49:03.220: GPU4 CUDART error in CudaProgram.cu:123 : unspecified launch failure (4)
17629:08:49:03.220: GPU4 GPU4 initMiner error: unspecified launch failure
17629:08:49:03.266: GPU2 CUDART error in CudaProgram.cu:123 : unspecified launch failure (4)
17629:08:49:03.266: GPU5 CUDART error in CudaProgram.cu:123 : unspecified launch failure (4)
17629:08:49:03.266: GPU3 CUDART error in CudaProgram.cu:123 : unspecified launch failure (4)
17629:08:49:03.266: GPU2 GPU2 initMiner error: unspecified launch failure
17629:08:49:03.267: GPU5 GPU5 initMiner error: unspecified launch failure
17629:08:49:03.267: GPU3 GPU3 initMiner error: unspecified launch failure
17629:08:49:05.283: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
17629:08:49:05.283: main GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0) 3: 0.000 MH/s (0) 4: 0.000 MH/s (0) 5: 0.000 MH/s (0) 6: 0.000 MH/s (0) [/quote] It seem that when all six cards start generating the DAG buffer, the last of them crashes. First, try to increase the virtual memory (page file) size to 32 GB temporarily to be sure that this is not causing the problem. If this doesn't help check the power consumption during the DAG generation. If it is close to the power rating of your PSU, you will have to lower the core clock on (some of) the cards to avoid overloading the PSU during DAG generation. The shutdown of the miner is also from the start, even with a cold card. My cards never get hotter than 58 degrees. (49-58)
The problem with shuting down appears with and without overclocking.
I will try to re-install the rig soon and see what happens.
Hmm, than this could be a power issue - they usually manifest themselves during DAG generation. How much is the power rating of your PSU (esp. 12V lines)? Other thing to try is to lower the power limit of the cards in Afterburner (or whatever OC software you prefer to use). i think my one nvidia based rig is having a similar issue. it's running 2.8c.
it will run fine for 5-50+hrs, then suddenly it crashes, gets the "unspecified launch failure" error, and doesnt auto-restart. i can see that the watchdog triggered, but then the pheonixminer.exe crashes in windows and it hangs until i manually close it. i usually just reboot the system and it's fine. i run all default parameters except only running the -coin eth command, everything else is defaults.
my AMD based system on 2.8c is rock steady. runs for 300+ hrs and never crashes.
This does seem quite similar but this happens during normal mining and not during DAG generation so it is less likely to be a power issue. Still, could you try to lower the power limit of your cards and see if this fixes the problem? On our test rigs the PSUs are over-provisioned by at least 50-60% so we never see such problems. Even if the PSU(s) should be enough on theory, some GPUs have momentary peaks in their power consumption which can drop the voltage enough to cause a crash. We will also investigate why the program doesn't restart as it should (and as it does in many other cases). |
|
|
|
...
appreciate the time comparing and clear justification, i am looking forward to see 2.9 outperform Claymore.
what i like about PM is that it could maximize my GPU's capability to hash up to 31.2Mhs for 580's which has a difference of .5 Mhs from Claymore.
having 1-2% of stale share is reasonable enough to shift to PM, i am still trying out other settings using PM though.
thanks and appreciate your feedback.
PhoenixMiner 2.9 should be released withing a few days (the internal test results for AMD cards are quite good but we are still tuning up the CUDA kernels). PhoenixMiner I owe you a beer, my mistake in the comment where I suspected that there was a bag in your miner, and it was a MITM attack. Sorry ser.
Thanks a lot, we will drink a Heineken (or three) in your honor The SSL will get rid of these attacks, it's a pity that only ehtermine supports it yet - if fact, if it weren't for their initiative, the SSL support wouldn't happen for a long time. Any plans for CryptoNote miner or integration or a seperate miner?
Already answered here (sorry but we don't have more specific answer for now): Any plans for CryptoNote miner or integration, would be great?
Not in the immediate future but in a few months a lot could and probably would change.  Hi Guys,
Can I specify the logfile name and maximum size (i.e. 75MB)?
Unfortunately not yet, but we will try to add this in 2.9 as it is overdue (it is sitting in our TODO list for at least a month). I have question regarding to stale share:
I located in US, would my stale rate be higher if I connect to EU server than connect to US server?
I've been tested this many times with Claymore in a 24-hour continue mining period.
Connecting to US or EU, I forgot to record all the stale rate, but eth/hour stay nearly identical.
Theoretically, yes because the network latency will be higher. However, these things should be put in perspective. The average time between jobs on ethermine is about 12 seconds, so every 50 ms two-way round trip time increase would increase your stale shares by about 0.4% (50/12000). If you are mining a coin with bigger block time, the stale shares decrease proportionally. Also I have another question regarding using -cclock 1150 -mclock 2100 -cvddc 900 -mvddc 900 arguements on RX 580.
I used to be able to use them on claymore prior to blockchain beta driver. But ever since I upgrade to blockchain beta, the setting will no long stay very long. It is able to set them correctly via claymore, after mining for awhile, it will reset to default some the hashrate will drop, power usuage and temperature will go up as result.
Some people mention 18.3.4 driver fix the problem so I can use claymore 11.6 to control OC setting again like before. But I still haven't apply the new AMD driver yet because: 1) It took a lot of time to get driver correctly installed (2~3 hours, most times longer) 2) not sure the new driver is as stable as the old one (My rigs have been running for a month now w/o hang, so I don't really need to do anything to interrupt that streak unil something is broken)
Anyway, can I use -cclock 1150 -mclock 2100 -cvddc 900 -mvddc 900 arguements on RX 580 with Phoenix 2.8c on Blockchain beta driver?
Yes but they will probably be unstable. The ADL support (which is responsible for the overclocking and voltage control) in the beta blockchain drivers is quite broken. Only the 18.x.x drivers fixed most of its problems. If you want to remain with the blockchain drivers the best way is to use MSI Afterburner or something similar to control the clocks and voltages. Hi Phoenix, FWIW, here's a small "potential bug" I found: I use Monitorig to keep track of all my rigs: https://bitcointalk.org/index.php?topic=1448855.0Everything goes fine, except for single GPU rig, where for some weird reason Monitorig won't pick it up. I'd be inclined to 'blame' Monitorig, but here's the catch: I switched all single GPU rigs back to Claymore, and they worked fine! My guess: it has something to do with your log file format, because that's how Monitorig output the information. ***If you could please change/mimic Claymore's in your future updates, that'd be great!*** Thanks and keep up the good work! I have to switch back to Claymore for now for single GPU rigs though  Unfortunately, this is quite unlikely to happen because: a) we would be unable to add new statistics and information and we have such plans; and b) a lot of users actually like our console output better, so we would be giving up one of our advantages. Hopefully, in time most remote control and monitoring applications will support PhoenixMiner fully (there are a lot that support us already but not all). Hi there
I added one more Ellesmere card to my rig (4 now) and Phoenix Miner stopped controlling fan speeds.
-tt and -fanmin stopped working.
I tried to use only one value or assigning a value to each card, but it won't work.
Claymore's works as usual.
Any ideas?
If you are using the blockchain drivers, all bets are off. If you are using 18.x.x drivers, please tell us the model of the card that is giving you problems (and the version of the driver). HI Dev,
can you put genom coin to the devfee list to avoid dag switch?
Will try to add it in the next release. Can someone help to resolve this error? I had internet connection problem and after connetion went up again, the miner did not connect again.. I had to restart miner. Is there any resolve for this issue? Why is phoenix connection to port 4444 nad not 5555 ssl? 17628:09:32:51.214: unkn Eth: Can't resolve host ssl://eu1.ethermine.org:5555
17628:09:32:51.214: unkn Eth: Giving up after 3 retries, switching to next pool
17628:09:32:51.214: unkn Eth: Reconnecting in 20 seconds...
17628:09:32:55.514: GPU2 Unable to submit share - pool disconnected
17628:09:33:04.989: GPU3 Unable to submit share - pool disconnected
17628:09:33:09.973: GPU4 Unable to submit share - pool disconnected
17628:09:33:11.222: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
17628:09:33:11.256: eths Eth: Connected to ethash pool eu1.ethermine.org:4444 (188.165.239.100)
17628:09:33:11.256: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_submitLogin","worker":"eth1.0","params":["YourWallet.DESKTOP-O8QC2F8"]}
17628:09:33:11.277: eths Eth: Received: {"id":999,"jsonrpc": "2.0","result": false,"error": "Invalid user provided"}
17628:09:33:18.794: main GPU1: 54C 72%, GPU2: 54C 56%, GPU3: 49C 49%, GPU4: 54C 64%, GPU5: 57C 64%, GPU6: 43C 70%
17628:09:33:21.952: GPU2 Unable to submit share - pool disconnected
17628:09:33:43.568: GPU5 Unable to submit share - pool disconnected
17628:09:33:46.704: main GPU1: 55C 73%, GPU2: 54C 56%, GPU3: 49C 48%, GPU4: 54C 64%, GPU5: 58C 64%, GPU6: 43C 70%
17628:09:33:55.839: GPU4 Unable to submit share - pool disconnected
17628:09:34:04.807: GPU4 Unable to submit share - pool disconnected
17628:09:34:09.682: GPU5 Unable to submit share - pool disconnected
17628:09:34:11.873: GPU5 Unable to submit share - pool disconnected
17628:09:34:14.941: main GPU1: 54C 73%, GPU2: 54C 56%, GPU3: 49C 48%, GPU4: 55C 64%, GPU5: 58C 64%, GPU6: 42C 70%
17628:09:34:30.878: GPU3 Unable to submit share - pool disconnected
17628:09:34:42.992: main GPU1: 54C 73%, GPU2: 54C 56%, GPU3: 49C 47%, GPU4: 54C 64%, GPU5: 58C 64%, GPU6: 42C 70%
17628:09:34:48.490: GPU3 Unable to submit share - pool disconnected
17628:09:34:51.279: eths Eth: Connection closed by the pool
17628:09:34:51.279: eths Eth: Reconnecting in 20 seconds...
17628:09:35:11.097: main GPU1: 55C 73%, GPU2: 54C 56%, GPU3: 49C 47%, GPU4: 54C 64%, GPU5: 58C 64%, GPU6: 42C 70%
17628:09:35:11.285: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: EthProxy)
17628:09:35:11.308: eths Eth: Connected to ethash pool eu1.ethermine.org:4444 (188.165.226.213)
17628:09:35:11.308: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_submitLogin","worker":"eth1.0","params":["YourWallet.DESKTOP-O8QC2F8"]}
17628:09:35:11.329: eths Eth: Received: {"id":999,"jsonrpc": "2.0","result": false,"error": "Invalid user provided"}
17628:09:35:22.780: GPU6 Unable to submit share - pool disconnected
17628:09:35:39.343: main GPU1: 54C 73%, GPU2: 54C 57%, GPU3: 49C 47%, GPU4: 54C 64%, GPU5: 57C 64%, GPU6: 42C 70%
17628:09:36:02.016: GPU4 Unable to submit share - pool disconnected You have forgotten to change the wallet address from the default YourWallet in the example command lines. Ethermine doesn't like the invalid ethash address (obviously YourWallet is not a valid ethash address) and disconnects with error "Invalid user provided". After three unsuccessful attempts, the miner switches to the next pool, which is not using SSL. To fix the problem, paste your real ethash address into the command line (or in the epools.txt file). not sure if already mentioned but there is an typo when starting your miner
Oops, thanks for catching this  I found a bug: if I start Claymore CryptoNight with some card and then start PhoenixMiner with all the other card then Phoenix crash... I tried then to start first Phoenix and then Claymore and I saw the problem: I was using the same port (3333)... opsss I forgot to change it!  So if the port 3333 is busy PhoenixMiner crash. I have also a request: can you add to the line of server name also the time when the connection occurred (or a counter)? I ask it because some time my internet connection go down and then up and I need to search on the log if this happened
*** 0:50 ***************************************************
Eth: Mining ETH on eth-eu1.nanopool.org:9999 from 13:00:00 07/04/2018
Eth speed: 183.484 MH/s, shares: 57/0/0, time: 0:50
I'm using your software from a few months and I'm very happy... I'm waiting for version 2.9!  Thank you for using PhoenixMiner! We will add the time and date as requested. As for the second problem, we have tested in such scenario and it shouldn't crash but print an error message. We will investigate further and fix the problem in the next release. 17617:12:22:59.708: main Phoneix Miner 2.8b Windows/msvc - Release
17617:12:22:59.708: main Cmd line:
17617:12:22:59.708: main config.txt: -pool eu1-etc.ethermine.org:4444 -pool2 us1-etc.ethermine.org:4444 -wal 0xd07e049700388d961068b92e28a9a86064b67986.letjen2 -clkernel 2 -amd
17617:12:23:00.302: main Available GPUs for mining:
17617:12:23:00.302: main GPU1: Radeon RX 570 Series (pcie 1), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.302: main GPU2: Radeon RX 570 Series (pcie 2), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.302: main GPU3: Radeon RX 570 Series (pcie 3), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.302: main GPU4: Radeon RX 570 Series (pcie 4), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.302: main GPU5: Radeon RX 570 Series (pcie 5), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.302: main GPU6: Radeon RX 570 Series (pcie 6), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.330: main ADL library initialized
always stuck like that. From v6 to v8b, how to fix it? Let me know, tk u
I still have the same problem when i install a new windows version i have 7 rigs 3 of them don't want to work with phoenix after a new windows instalation and the other 4 works fine tell me please where is the exactly problem and how to bypass it and if it need install some package tell me please Waiting for your reply devs Is this by any chance the "Debugger detected" problem? If the console window closes fast after the program crashes, please put a pause command after the line that starts PhoenixMiner in your .bat file (or use the start_miner.bat file that is in the PhoenixMiner .zip file, which already has a pause command). PhoenixMiner we are waiting 2.9, any news? Will be ready in a few days. We want to be sure that everything works fine as there are a lot of changes in the kernels. Can anybody tell me why phoenix.exe above 2.7c crashes in 5 seconds when starting on one rig and on my other rig it runs perfect also with latest version.
Both rigs are identical with 6 gtx1070 8gb cards each and windows 10.
I didn’t read anything here about this problem.
Please send us the log file and check if the miner shows "Debugger detected" error before crashing (the "Debugger detected" error will not be printed in the log file). If the console window closes fast after the program crashes, please put a pause command after the line that starts PhoenixMiner in your .bat file (or use the start_miner.bat file that is in the PhoenixMiner .zip file, which already has a pause command). If the error is "Debugger detected" try to add -nvidia to your command line. |
|
|
|
Any plans for CryptoNote miner or integration, would be great?
Not in the immediate future but in a few months a lot could and probably would change. This is my hashrate and stale share percentage in Claymore 11.6 https://image.ibb.co/iz6vBc/ETC.pngPhoenix can tap my RIG up to 395Mhs (13GPU) however, it gives me 5-6% stale share.. i like the hashrate spike from PhoenixMiner, but i guess effeciency goes to Claymore 11.6 - hope that PhoenixMiner could catch up soon.. This problem seems to impact a fair share of users so we tested like crazy but the results are really puzzling. For example, in the most pure form of testing - with a test network proxy that eliminates all latencies, the difference is less than 1% (as it should be) and virtually zero when using the new 2.9 branch which lowers the internal stale shares to about 0.1%. Also, when checking out one of the many devfee addresses of Claymore, we get the following on ethermine, ethpool and ethermine-etc at the moment of this writing (this is a great way of comparison as represents the average stale shares of many rigs): Now, compare this to our devfee wallet (we have three on ethermine, and one on ethpool and ethermine.etc): The difference is way smaller than what is observed by a lot of users (and confirmed by our own tests when we use a single mining rig or small group of rigs). As we said, in version 2.9, the internal stale shares are almost zero (the job change latency from the moment the new job is received from the pool to the moment first hash is computed is less than 30 ms), so if this doesn't solve the problem, it would be very strange indeed. Glad to be able to try Phoenix Miner, I'm mainly an AMD miner across 3 rigs. I did notice that Phoenix miner on a 9 card AMD rig mixed of rx 570/580 pulled an extra 20 watts (from the wall) compared to the 1180 (from the wall) of Claymore 11.4, not a biggie because it's so small but I'm just a bit curious.
Hashrate is the same between both.
my other rig which is a smorgasboard of different brands of cards is about 4-5 MH/s lower using phoenix.
Is it possible to customize the GT/DCRI for each individual card?
I like the output and format of Phoenix way better but at this moment only using it on 2 of my rigs (the other Nvidia).
Thanks for the miner!
Thank you for trying our miner. We are preparing a new version that will be released soon with substantial improvements in the AMD kernels in both speed and latency (which should decrease stale shares). Yes, you can specify different -gt (or -dcri) for each GPU by using - gt 15,18,15,15 for example for 4 GPU rig. Hi Phoenix, can you change time logging in the next release to be more user friendly? Now you use format 17625:02:43:37.171 But for me 17625 looks strange. I really do not know what is it. Can you log date instead of 17625? Another point. I use -minRigSpeed 188 option. It should do restart if avg hashrate is less then 188 during last 5 minutes. But this is not true. Please look at log. Only 1 minute I had hashrate less then 188. Not 5 minutes, but rig was rebooted 17625:12:05:42.811: main *** 36:37 ***************************************************
17625:12:05:42.811: main Eth: Mining ETH on eth-eu1.nanopool.org:9999
17625:12:05:42.811: main Eth speed: 173.852 MH/s, shares: 2541/0/2, time: 36:37
17625:12:05:42.811: main GPUs: 1: 29.437 MH/s (390) 2: 28.839 MH/s (437/1) 3: 29.572 MH/s (445/1) 4: 28.203 MH/s (451) 5: 29.520 MH/s (396) 6: 28.282 MH/s (422)
17625:12:05:42.811: main Eth: Accepted shares 2541 (27 stales), rejected shares 0 (0 stales)
17625:12:05:42.811: main Eth: Incorrect shares 2 (0.08%), est. stales percentage 1.06%
17625:12:05:42.811: main Eth: Maximum difficulty of found share: 46.1 TH (!!!)
17625:12:05:42.811: main Eth: Average speed (5 min): 184.180 MH/s
17625:12:05:42.811: main Eth: Effective speed: 192.72 MH/s; at pool: 192.72 MH/s
17625:12:05:42.811: main
17625:12:05:42.811: main Average ethash speed for 5 min is below minimum of 188 MH/s. Restarting! Yes, you are quite right, 17265 is not something that is meaningful in the real life (it is the number of days since the Unix epoch - Jan 1st, 1970). This was done to save a bit of CPU time to avoid converting to the local time but it is nothing really, so we will change it to a more understandable format in the future releases. As for your second question: -mirRigSpeed tracks the 5 minute average speed (the same which is shown every 40 seconds or when you press the key s), which is using five minute floating window (i.e. it is the average speed for the last five minutes). For example if the speeds was 200 MH/s but dropped to 100 MH/s two minutes ago, the 5 min average will be 160 MH/s (computed as ((200 * 3) + (100 * 2)) / 5). In your case you can see that the speed has dropped to 174 MH/s for some time so the average speed has also dropped to 184 Mh/s. Hi Phoenix,
Can you think about new option in miner to switch to next pool from epools if average (for 5 minutes, for example) share accepting time is more then configured? It will require to define for each pool its own time. Also may be some conditions should be used to back to previous pool. I think if you will like this idea, you will find the best solution for this issue.
This is actually a pretty good idea. We are planning to add detailed pool statistics (share acceptance time, job change time, rejected shares rate, etc.) and this would be a nice way of using the statistics for more than just information. We will probably implement this in the near future. Do this have the same autotune function as claymore?
Not yet, will be added soon. Anybody knows why invalid shares is present? I'm in mining about 3 months, but only yesterday I had two invalid shares (on different cards). I use Phoenix miner now and use it about a week. Before that I used Claymore. And only yesterday I had caught 2 invalid shares. Can it be result of overclocking or no? Is it normal or no?
As long as the incorrect shares are just a few there is nothing to worry about. If they are on different cards, the most probable reason is that the pool is changing the jobs like crazy (two or more changes for less than two seconds) and the computed share was valid but too old (i.e. more than one generation older than the current one). If the incorrect shares become more (more than 0.2-0.5%) and are on the same GPU, then you may have problem with too much overclock. Hello guys! I have been using this miner for a long time now, but I just cannot understand something:
17625:13:20:17.214: main GPUs: 1: 31.507 MH/s (1) 2: 31.487 MH/s (5) 3: 31.485 MH/s (2) 4: 31.484 MH/s (6) 5: 30.601 MH/s (1)
17625:13:20:17.415: main GPU1: 50C 48%, GPU2: 52C 58%, GPU3: 50C 47%, GPU4: 46C 49%, GPU5: 49C 39%
All of my cards are the same, with the same BIOS modifications and setups! Why are some generating more heat than the others? I have tried to read the log file, but it's just not giving any infromation about that.
In HWINFO all stats are the same.
One possible reason is the card location (first one with open fans that suck cold air is usually the coolest), another is the difference between the chips themselves, VRMs, etc. Even on the same voltage, some chips/VRMs just consume more power than the others, which translates to more heat. PhoenixMiner 2.8c tested on AMD and NVIDIA rig, my observations are:
Nvidia rig works 3-5Mhs more then Claymore 11.5 P106 runs 25.7-26.1, GTX1070 33.2 GTX1060 24.1
AMD rig on RX570 8GB have 2Mhs less around 29, claymore have 31+ and little less on RX 470 around 32.6, claymore 11.6 have 32.8
On awesomeminer dont see Progress on Nvidia card how many accepted, Rejected...
I have problems on NVIDIA P106 cards, with fan controls, does not show a percentage, got error after few minuts
with some fixes, the program will be really good
We are preparing a new version with faster AMD kernels. If you are getting error 999 on the Nvidia card, you should lower the memory clock a little. Something weird happened tonight on one of my two rigs. Early this morning I noticed on ethermine.org that one rig with 8xRX 480 cards did not work for about 5 hours. https://imgur.com/a/dASLCI approached the rig and, surprisingly, noticed that he worked steadily since the last restart I did about 8 hours before. https://imgur.com/a/bLLTPI checked the log file and I realized that there was no errors or restart in it. I reviewed the Task Manager and found that PhoenixMiner.exe on this rig uses about 887 MB of memory, which is roughly 441 MB more compared to the 8xRX 580 cards running steadily on ethermine.org, practically twice as much memory. https://imgur.com/a/vL3r8I restarted the rig and he reappeared at ethermine.org, but I noticed that after 5 minutes of work PhoenixMiner.exe used 558 MB of memory and after 8 minutes 887 MB of memory again. I do not know how the Phoenix miner could work permanently, and that ethermine org shows it does not work. This is not about any kind of hacking on the side, I think the problem is in the miner itself, maybe it's a bag in the miner. I'd like to hear your suggestions. You have fallen victim of the MITM scamers (so called IP hijack attack). The IP address of the ethermine server was hijacked by hackers (this happens in your ISP, so it is not your rig's fault but the result is still the same. You can see the telltale sign of the 10000 MH difficulty, which is never used by ethermine (their jobs are always with 4000MH difficulty). Fortunately, there is quick and easy fix the prevent similar problems in the future: use the encrypted (SSL) address of ethermine like this: -pool ssl://eu1.ethermine.org:5555. Note that the address starts with ssl:// and the port is 5555. |
|
|
|
What's this: PhoenixMiner 2.9c: fastest Ethereum/Ethash miner with lowest devfee (Windows)?
Fake release, probably packed with malware. All official or beta (or whatever) releases of PhoenixMiner will be done here, in this thread. Running 2.8c now, One of my GPU's still drops to 0.0mh. I have two models of this card, same memory, both with stable overclock. Runs fine with 2.7b. Have tried to lower significantly its memory clock from 2200 to 2100, 2075 and 2050, does not fix the problem, left the core at 1150. With version 2.8c I have tried to use the -clnew 0 flag for that particular GPU while designating the other cards in the system -clnew 1 yet it does not fix the problem. I run the card with -mi 12 on 2.7b so I also tried to lower that to -mi 10 on 2.8c with no difference in result. Only way that card remains hashing is by running it separately with 2.7b. I have also tried claymore 11.6 version with the same conclusion, hashes for a minute or two and drops out to 0.0mh.
Has anyone else experienced this particular problem? Its not a major issue for me running two versions but it is the idea that I cannot solve this problem has me twisted atm.
While we were unable to reproduce the problem, we have an idea what may be the cause although it doesn't make much sense. Still, we will fix this in the next release where -clnew 0 should be able to completely replicate the behavior from 2.7. Just gave a chance to PM2.8c today on Windows 10. Sharing my first expression, observations, problems and results:
Copied the Claymore config file over. It fails out of the box. Requires a migration of configuration.
After a bit of tweaking a successful configuration file migration was in place. Got the PM2.8c running in less than 3 minutes.
The following discrepancies were observed:
PM2.8c vs CL11.5
1. config file with spaces listing multiple single option values, for example: "-cvddc 835, 835, 850, 900, 835, 835" reports an issue with invalid option 835. CL allows spaces. Some use spaces with a line above as comment with list of GPUs; GPU1 GPU2 GPU3 ... - spaces are for alignment.
2. Order of GPUs is different, this leads to incompatibility with CL existing configuration. CL lists AMD cards then adds NVidia cards. On PH2.8c all are mixed as discovered at system level The migration requires redo of the config file and custom settings for all options with individual values per GPU. For example: -cclock 0,0,0,0,1170,0,0,1160,1160,1160,1180,0,1120 - the 0 for NVIDIA cards. Migrated from -cclock 1170,1160,1160,1160,1180,1120.
3. -ethi default is different 8 vs 12.
Results/comparison as reported by miners (13 GPUs rig: 5x AMD RX580, 7x NVidia 1070):
CL11.5: Average speed (as observed in logs): 400.309 - ranging: 400.151 MH/s - 400.706 MH/s @ wall wattage: 1620W
PH2.8c: Average speed (5 min): 402.817 MH/s - ranging: 400.926 MH/s - 404.945 MH/s @ wall wattage: 1630W
Observations:
1. Can confirm increased hash rate of 0.62%. (Same settings as CL).
2. The reporting API works as advertised out of the box. Using Claymore's Monitor on Android it just works, reporting the version as: PM2.8c-ETH compared to 11.5-ETH (Claymore).
3. It appears stale shares value is at a similar level to CL. The PH reported % of stale shares is not in sync with pool report (ethermine.org): 1.26% vs 3%
4. Log file entries are detailed and easy to understand.
6. The on-screen run log/report is on a higher level compared to CL. Way more informative and rich with data. Not sure about the (!) next to Share actual difficulty when diff is in GH.
7. As a software engineer I do start counting my GPUs with 0, 1 ... but on the other hand some other SWs such as HWinfo64 are also listing GPUs from 1, 2, 3... Not sure yet how annoying if at all this is.
Will keep this rig running for a while to gather more data on stability and performance. Will report back.
Would be nice for miners to add a migration section (from other miner apps) to PH.
Definitely would be interested to buy a licensed version with devfee 0.
All in all a great alternative miner with better performance and a lower devfee. A solid ****. Excellent job.
Thank you for reporting your findings. We will fix the errors caused by the additional spaces in config.txt in the next release. The GPUs should be ordered in increasing PCIe bus number, which in turn should be roughly the same as the order of the PCIe slots starting from the CPU socket (and also the same order as most hardware control and monitoring programs). We will consider adding an option for alternative GPU ordering but for now this seems the most sensible approach. We are also preparing another improvement that will lower the number of stale shares even further. Added PhoenixMiner 2.8c to official EthControl software list, great work.
Thank you! We are happy that the fixes in PM 2.8c are working. I noticed that PM constantly uses 1.5-2% of CPU power during mining. Why? Can it be reduced?
Hmm, this is too much. What CPU you have and what version of PhoenixMiner you are using? In PhoenixMiner 2.8c and with very slow CPU like Athlon II x2 we are seeing about 0.2-0.5% CPU load. what is the best gpu for your miner? (ROI)
It's hard to give a definitive answer because it depends too much on the difficulty, ETH price, etc. It is better to maybe use metrics like hashrate per USD (GPU price) and hashrate per watt (power consumption). In these so far the AMD Polaris cards are still the best but if you already have paid back the GPU initial price, the power efficiency of GTX1070 is the best. So, if you are buying GPUs right now - AMD Polaris (RX570 4 or 8 GB because the hashrate is the same as 580; 8 GB if you want to be as future-proof as possible). I noticed that PM constantly uses 1.5-2% of CPU power during mining. Why? Can it be reduced?
Oh, increased CPU usage is only with -gpow parameter. Without it or with -li option CPU usage is norm - 0-0,5%. I think that it -gpow bug... Ah, this explains it. -gpow and -li both work by adding some "sleep" time after each kernel dispatch. -li uses fixed amount of time, which makes it difficult to be sure how much it will decrease the hash-rate but -gpow dynamically recalculates the length of the sleep period. This is both too CPU intensive and too inaccurate if the mining intensity (-mi) is already low (under 5 or 6). So if you want to use low -mi, it is better to use the -li option which is "dumb" but uses less CPU. Dev Request:
Can you include a feature that "force" or change the seeting for the card(s) to turn on compute mode?
perhaps a command at run time or a flag "-compute 1"
I use blockchain drivers, but switching to newest driver would definitely make it extremely useful!
Thanks.
Yes, it will be included in the next full release. i use 2.8.c bu what can i do for this error help
gpu: 2 or 4 on more rigs cannot get fan speed, error 999
Lower the memory overclock of the cards that give this error a little (20-40 MHz) and it should go away. |
|
|
|
In help file of 2.8c -tstop and -start are placed inside section "for AMD cards only". I hope it is by mistake? Will it work on NVIDIA cards or no?
-tstop and -tstart work with Nvidia cards too. It was an oversight and was corrected, thank you for noticing. PhoenixMiner 2.8c doesn't report Hashrate when I'm mining with HTTP GetWork through local eth-proxy.exe I tried to set -rate 1 param but no effect. Here is my cmd-line: PhoenixMiner.exe -amd -coin eth -gwtime 50 -rate 1 -pool http://192.168.10.12:8090/rig1 We couldn't reproduce the problem here. Could you tell us what proxy you are using (a download link perhaps)? PhoenixMiner 2.8c: fastest Ethereum/Ethash miner works Great thanks.
in my case dont forget for Nvidia cards (-mi 10) with this code on the bat file.
Please add more auto functions
If you haven't specified any -mi, the default value for Nvidia cards is still 10. Even if you have mixed Nvidia/Amd rig, you don't need to specify -mi if you are happy with 12 for AMD cards and 10 for Nvidia. However, if you want to use for example 14 for the AMD cards, you will have to specify -mi value for each card, e.g. -mi 14,14,14,10,10,10 if you have three AMD and three Nvidia cards. Appeal to the developers. Can you cancel devfee for coins that are not currently listed? Switching dag files can lead to a crash and change of settings -eres / -lidag this problem is not solved (
Unfortunately there is no good way to detect the coin. We use some heuristics but they aren't 100% accurate (if they were, we wouldn't have the -coin command line option). Also such feature will be easy for abuse in the future. Phoenixminer I have a question, when you start phoenixminer and ethminer-0.9.41-genoil-1.x.x? the screen and the operation are very similar, is the basis of phoenixminer software the same as ethminer-0.9.41-genoil-1.x.x? .
==================================================================================
Phoenixminer 2.8.c works very well less stale shares, I use nvdia gpu so far I was very satisfied with version 2.6 which gave higher stale shares. thank you for this good miner software.
No, but we liked some of the ideas in the original ethminer like showing the progress of DAG generation and the internal (visible to the miner) stale shares, so we implemented them in our miner too. 2.8c has all but removed all stales i get reported on screen.
vega 64 impact, no difference in terms of speed mh wise from 2.8b.(ratio of found shares does seem to be lower though when looking at all shares found across all gpus in rig)
fury x the reported hash rates are more level but spikes to higher hashrates are gone. I was getting an avg 35.2 mh on them with spikes to 40.(2.8b) now avg is 34.5 with no spikes. 2.8c
thanks for PM
More AMD kernel improvements are coming shortly in the first beta of 2.9. |
|
|
|
Hardware control options (AMD cards only; use comma to specify different values for each GPU):
-tt <n> Set fan control target temperature (special values: 0 - no HW monitoring on ALL cards,
1-4 - only monitoring on all cards with 30-120 seconds interval, negative - fixed fan speed at n %)
Setting -tt 4 as per the quote above, only shows the GPU Temp and fan speed line every 120 seconds. Is the same possible for the GPU hashrate stats lines? No, the speeds are shown every 5 seconds or so. If there is enough requests for such feature, we can add it. Running 2.8b, One of my GPU's after finding a share its hashrate drops to 0.0mh, it starts at >30mh then as soon as a share is submitted with that particular card it drops out. I have two models of this card, same memory, both with stable overclock. One runs fine with 2.8b, the other has the issue. I have tried changing my -mi for that specific card lower and the problem persists. Running previous PM versions the card runs fine. Is there a way within the same prompt to individually designate which kernal a specific card runs on? If so is there an example config for my bat?
You can use the -clnew 0 to revert to the old kernels. If you want to use the old kernels on specific GPUs only, use -clnew 1,1,0,1,1 for example to use the old kernels on the third GPU on a five GPU rig. Note that there are some changes in the new kernels in 2.8c, which may solve the problem with the hashrate drop after found share. Also note that -clnew is only available in 2.8c (not in 2.8b). "-eres 0" no work.. cuda error persist (same on claymore) for gtx 1060 3gb.....any solution?
-eres 0 was always going to be just a temporary solution. The real solution is to switch to Windows 7, which reserves less than 5% of the GPU memory unlike Windows 10. This is a long-standing problem with Windows 10 and despite the numerous requests from users, it is unlikely that Microsoft will resolve it. Note that some miners report success with Windows Server but we haven't tested this personally. Hi. Excellent miner! The very good work. I used Claymore before, but new versions of Claymore beginning from 11.0 work not fine on my NVIDIA rig (some people say the same). Las good worked version is 10.6, but even this one sometime works bad I tried to use PhoenixMiner and I like what I can see for now. It is very strange, but hashrate in PhoenixMiner is more then in Claymore! I need some time to see the result in pool statistics. Can you add some little feature? I use good android app Claymore's Monitor https://play.google.com/store/apps/details?id=com.clay.ua to see how my rig work and some information is absent in PhoenixMiner which is present in Claymore. Can you provide information by which card share was found? Something like what claymore does in log: ETH: 03/14/18-14:13:14 - SHARE FOUND - (GPU 0) Thank you! We print the GPU which finds the share in the log and in the console like this (in this instance GPU1 has found the share): Eth: GPU1: ETH share found!
Eth: Share actual difficulty: 2364 MH
Eth: Share accepted in 52 ms hey dev, i suggest you not to follow claymore's path such as increasing intensity, lowering cpu load or whatever he makes in his miner.
its getting unstable.
The new kernels should be more stable as this was one of our design goals. You can use -mi 10 to get the same intensity as before, or revert back to old kernels with -clnew 0 Perhaps folks can possibly help me as I'm stumped: Few months back, I was getting an average of 240-250mhs with my 8 card rig. Same Bios and setup at the time. As of recently though I'm averaging about 18-19 per card with one random gpu showing 30ish. I've tried to reinstall windows, turn off auto updates (heard that fall creators update can slow the hashes down). I tried the blockchain drivers, was pushing 150mhs for the same 8 card rig, and installed the new adrenaline drivers and enabled compute (that's where I got that extra 10mhs with the one random card). I thought the difficulty went up and that's why they were running worse, but I'm reading people are still pulling about 30mhs with their Powercolor Red Devil RX580's 8GB models. (I have 16 with hynix memory and 12 with micron memory. Both groups have modded bios, which before allowed them to each run around 28-30mhs each). Any insight as to why they would've dropped? I picked Phoenix Miner because I've heard good things about them, and the lower dev fee. Here is a pic of one of the 8 rigs for example: https://www.dropbox.com/s/dlavivnwdfy7fkj/MHS.PNG?dl=0 Have you turned on Compute mode on all cards? It is on card-by-card basis, unfortunately there is no way to turn on the compute mode for all cards at once, so you have to do it one by one. The difficulty has nothing to do with your hashrate, so this is not the reason for the slower speed. When this happens, what do you guys do?  Check the overclock settings on GPU2 as it seems that the problems start from there. |
|
|
|
PhoenixMiner 2.8c is officially released. Note that there are changes since 2.8b, so if you are running 2.8b, you should upgrade to this version. Here is the full list of changes since 2.7c (the last official release): - New kernels for all supported AMD GPUs, providing higher hashrate and lower percentage of stale shares. The new kernels are used by default for AMD GPUs. You can also revert to using the old kernels with -clnew 0
- When using the new kernels, the mining intensity is 12 by default instead of 10
- The mining intensity range is now up to 14. Use high -mi only with the new AMD kernels as for the other kernels the stale shares will increase too much
- Small CUDA kernel stability improvements that also may (very) slightly increase the speed of Nvidia cards
- CPU utilization during normal operation is lowered by about a factor of 10 regardless of the number of GPUs
- Added support for -tstop and -tstart options to stop mining on given GPU if the temperature rise above specified value and restart it after it cools down below -tstart temperature
- Fixed the problem with console window freezing after scrolling
- Implemented new -gpow n option to lower the GPU utilization (default: 100, the value is the desired GPU utilization in percent)
- Implemented the -li option to lower the intensity (use this instead of -gpow if you are already using -mi with low values)
- Improved GPU speed statistics, using moving average window for each GPU. You can change the size of the window with the -gswin option (5-30 seconds; default 15; use 0 to revert to the old way of using 5 second "quants" which are independent of each other)
- Specify GPU number above 9 by typing three-digit sequence at the console (e.g. type 011 to pause or resume GPU11)
- Other small improvements and changes
- Added support for the miner_getstat2 remote monitoring request
We are now working on 2.9, which will include new CUDA kernels for Nvidia GPUs and other improvements.
|
|
|
|
17617:12:22:59.708: main Phoneix Miner 2.8b Windows/msvc - Release
17617:12:22:59.708: main Cmd line:
17617:12:22:59.708: main config.txt: -pool eu1-etc.ethermine.org:4444 -pool2 us1-etc.ethermine.org:4444 -wal 0xd07e049700388d961068b92e28a9a86064b67986.letjen2 -clkernel 2 -amd
17617:12:23:00.302: main Available GPUs for mining:
17617:12:23:00.302: main GPU1: Radeon RX 570 Series (pcie 1), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.302: main GPU2: Radeon RX 570 Series (pcie 2), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.302: main GPU3: Radeon RX 570 Series (pcie 3), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.302: main GPU4: Radeon RX 570 Series (pcie 4), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.302: main GPU5: Radeon RX 570 Series (pcie 5), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.302: main GPU6: Radeon RX 570 Series (pcie 6), OpenCL 2.0, 8 GB VRAM, 32 CUs
17617:12:23:00.330: main ADL library initialized
always stuck like that. From v6 to v8b, how to fix it? Let me know, tk u
So, version 2.6 was working properly or it had the same problem? Also, does the miner just freezes or crashes (exits)? |
|
|
|
Hi.
There is no way to. make afterburner work after 3 gpu with new amd adrenalin driver. I tried ddu and i installed from lower version of 18.xxxx to higher but no luck. it works with 1 or 2 rx570 when you installed 3rd card it doesn't allow me to OC my gpu cards.Rx 570 cards are there but all cards are Gray out. so you cannot change anything there. Anybody has got idea or advice? Many thanks in advance.
We don't know why is this happening but it probably has nothing to do with PhoenixMiner. You can try using the built-in hardware overclocking options in PhoenixMiner, they should work fine with the latest drivers. The new version improve the hashrate for rx580 8gb. But for my Rx 470/570 4gb is better Kernel 2 and more low than claymore
We will provide new alternative kernel for Polaris (the one that is activated with -clkernel 2 in the current version) in the final release of 2.8. 2.8b is very good!
One wish in comparing with Claymore:
1. Claymore have intensity from 0 to 16. 8 is default. If I use GPU for other purposes during mining (video, small games) Claymore miner just lower the speed and other 3D app runs good.
2. Phoenix miner have intensity from 0 to 14. 12 is default. Speed a bit higher than Claymore with default intensity in PM (12) and in CM (8 ). But Phoenix miner during mining and playing even weak games drops speed of mining even more than Claymore but gives less power to D3D app.
Lowering intensity to 9 in PM lower the speed but nearly not increase D3D power for apps.
Can you add in miner auto detection of D3D usage by other app and auto lower intensity for it? I just use my 1st GPU not only for mining...
Sorry if it too hard but Claymore can do that... I hope that you also can do that!
And another one question:
What about GPU tuning parameter in new kernels? Does it the same as in 2.7 or maybe 15 is not optimal now?
You can specify different mining intensity for the first GPU and the rest by using -mi 0,12,12,12 for example if you have 4 GPUs and the display is connected to the first of them. Our range of mining intensity is in fact wider as it is logarithmic instead of linear, so there is no direct equivalence. You can try -mi 0, which should provide virtually no lowering of the speed of your 3D games but of course the hash-rate will be lower. The idea of detecting 3D load is interesting but we can't promise when (or even if) it will be implemented. We have some other potential solutions for this kind of mixed type usage but they will have to wait for the future versions. The GPU tuning parameter should be about the same. Hey PM, thanks for the update, Quick question: The text "You can also revert to using the old kernels with -clkernel 1" it sounds to me like a typo, on the readme.txt file, it states that 0: generic, 1: optimized, 2: alternative But in your update you're saying that with option 1 you're reverting back to old kernels, so, which one to use for 580's? 0 or 1 option? Thanks Yes, sorry, this wasn't clear enough. If you want to use the new kernels, don't specify any -clkernel option - the new kernels are turned on by default on the supported GPUs. If you want to mix the kernel types on the same rig, you can use -clkernel 3 for the new kernels and -clkernel 1 or 2 for the old kernels. In the final 2.8 we will provide new version of the -clkernel 2 kernels too, and the old kernels will be retired for good as the options are becoming too complex without any benefit for the end user. About 0.5-0.75% stale shares still there.
Yes, we don't aim for 0% stale shares as this isn't helpful for the overall hashrate, and this is all that matters in the end. We aim to extract the best effective hashrate, including the stale shares. switched my AMD rig from 2.7c to 2.8b
6x rx570 4gb
2x rx580 4gb
2.7c - 228.3MH
2.8b - 229.8MH
0.65% speed increase. power consumption is the same about 1090W from the wall. good stuff.
PM: is it worth it to move an nvidia rig from 2.7c to 2.8b? i'm guessing no?
It is, as there were small changes in CUDA kernels in 2.8a (which are also included in 2.8b), which may slightly increase your hashrate (and certainly won't decrease it). We are preparing new CUDA kernels as well but they will be ready for 2.9 and will provide another small speed increase. Phoenix do wrong calculate of stale shares percentage.
Total shares - 200. Stales - 2. Est. stale percentage - 1.10%.
But 2/200*100 = 1.0%
Does PM pessimist?
Note that we take the share difficulty in consideration when calculating the stale share percentage - so this is probably not wrong but either your pool changes the difficulty of the shares and the stale shares happened to be with higher difficulty than the average difficulty of the accepted shares, or the pools have switched and the stale shares are from the pool with the higher difficulty. For example if you have 200 shares with average difficulty 3150MH and 2 stale shares with average difficulty 4000MH, the stale shares percentage is shown as 1.1% even though 2/200 = 1%. This is the best way to do it as it won't invalidate your stats if you switch from a pool with difficulty 4000MH to a pool with difficulty 10000MH. @PhoenixMiner
I guess congratulations are in order for successfully duping the general population
that are trying to use your miner that the fake number you display in the miner is
actually the real stale share rate.
I actually thought you were honest. You've let them believe it without continuing
to specify that that is not a honest representation of stale shares.
Luckily for you most people don't mine in a pool that shows them the actual stale shares.
I can't use your miner any longer. I know that number is false and now I don't think
I can trust you.
I know I'll catch crap from people who think I'm wrong, but you know I'm not.
5x to 10x more stale share from your miner than Claymore. ( AT THE POOL )
The first post of this thread (as well the Readme.txt that is shipped with the miner) state clearly that the stale shares shown by PhoenixMiner are always less than or at most equal to the stale shares of the pool. The was repeatedly explained during the course of this thread (you can search back if you want). The reason why this "internal" stale share percentage is important and will be shown by PhoenixMiner was also stated a few times - it allows you to see what you are losing if you increase the mining intensity too much. The other stale shares that are result of pool's latency (and not only in your connection to the pool but also the delay in the pool notification that there is a new job) are completely outside the miner's control and can't be affected by any of your settings. Furthermore, we can't know when the pool actually has switched the jobs, so there is no way to show the number of these shares with the information that the miner has. Finally, as already explained, we try to optimize the overall effective hashrate, including the stale shares, instead of just minimizing the stale shares. Hi Phoenix,
FYI the readme.txt that comes with 2.8b still says the -mi paramaters is up to 12, with 10 being default i.e. the old values.
Thanks for catching this, it will be fixed in the new Readme.txt. @Phoenixminer
Good job with the 2.8b, its running pretty good.
Question, can we use a proxy with your miner ?
If yes, which one do you recommend ?
Thank you
Yes, you can. If it uses the HTTP getwork protocol, you will need to add the http:// prefix in front of the proxy address like this: -pool http://192.168.0.45. Frankly, we don't know which proxy to recommend. |
|
|
|
|
Show Posts
