|
301
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.6: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: February 04, 2018, 03:53:26 PM
|
|
PhoenixMiner 2.6 is officially released. In addition to what was included in 2.6b, we have added monitoring of the main thread by the watchdog to catch some rare cases when the main thread freezes but the GPU threads continue.
We are switching our attention to 2.7, which should include the initial support for hardware control, direct support for mining some new coins (Akroma, VIC, and Whalecoin), as well as some other new features. We are also working on a completely new share processing code path that aims to lower the probability for stale shares even more but as it uses completely different approach than the current code, it may not be stable enough to be included in 2.7.
|
|
|
|
|
302
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.5d: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: February 03, 2018, 04:48:00 PM
|
Please use a batch file to start the miner with the following contents (the important part are the setx statements to set the environment variables): Code:
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 -clKernel 1 -pool eu1.ethermine.org:4444 -pool2 us1.ethermine.org:4444 -wal 0x36fd6ca7b320c46189bb9e78f5390573cace4745.Rig003 -proto 3
pause Still the same problem. Occurs on different GPU, sometimes on 2 simultaneously. Check the size of your Windows page file, it should be at least 16 GB. If not, raise the minimum size to 16 GB. Please try using the command line option -mi with different values (for example 8, or 9 instead of the default value of 10). You can change it only for the RX560s by using it like this: In the above example the first two cards will run with mining intensity 8, and the other three - with mining intensity 10. This assumes that the RX560s are the first and the second card and you have five cards in the rig. The order of the cards must be the same that is listed by PhoenixMiner when starting up. Didn't change much, still dropping hashrate. We'll check it further, but we have only one RX560 and it doesn't behave this way. Could you tell us what version of Windows you are using and which drivers? It probably isn't worth pushing back the linux version for dual mining capability. The Chinese released ASIC for Lbry, Pascal, Sia, and Decred so there isn't any point in dual mining anymore. If someone develops algos that play well with ethash in the future you'd probably need to start building from scratch anyways. The other tweaks are pretty sweet but once you get that linux version up an running talk to the ethOS guys an get them to incorporate your miner in their OS. I got 2 rigs on ethOS linux with 10 cards an 12 cards cuz windows don't play well with a lot of gpus on a single rig.. given the new mining boards coming out that can house 12+ gpus i think windows mining is going to be getting phased out by people running larger farms which i'm guessing is more your bread an butter target market. I'm running your miner on my desktop with 4 gpus an already wish the linux version was available for my other rigs. Faster hash rate, less fees, no dag switches. I get what you're saying about the dag switches I haven't watched enough to see the dev mining fee to see if my cards still have to spin up an i'm only running this on my small system anyways so even if i could see it it wouldn't be nearly as obvious as my other systems with 3x-4x as many cards. I skimmed the commands an i don't recall seeing a feature similar to -powlim from claymore. That would be a good feature to have so you can tweak power consumption. I'm not a pro or anything but I noticed that my cards will run at say 30mh/s with powerlimit 20.. but if I lower powerlimit it will drop total power consumption without decreasing hashrate or stability so the cards will just use whatever power they can for the most part. It would be nice to have the feature incorporated in the miner so we don't have to go around reflashing cards to find the sweet spot using powerlimit % / tdp in bios.
We'll try to release the dual mining as fast as we can because we are already invested a lot of time in it. The Linux support definitely is very important but given that there isn't one "true" Linux and a multitude of (AMD) drivers, it would take even more resources than the dual mining. The (probably flawed) rationale is that the dual mining window is closing fast, so if we don't release it soon, it becomes pointless. The Linux support will be useful a lot longer. We are going to implement all (or at least most) of the hardware control features that are present in Claymore dual miner. They will gradually start to appear from version 2.7. Right now we are chasing a few elusive bugs that some of the miners are experiencing. So sad, almost want to cry...
So 2.5 came and went, 2.6 is here but no solo geth|parity mining.../frowny face & upset tummy.
I think I am the only person asking for it, so not surprised. But will I be surprised with 2.7b?!?
The good news is that there are other requests for solo mining  No promises but there might be an experimental support for it in 2.7. A question to the DEV - How may I undervolt with this miner? It's drawing 200W more than the Claymore's? I am scared to use undervolting from TRIXX, because my rig freezes if I touch something there  I am using it only to set my fans speed. Are you planning on implementing the -cclock -mclock -cvddc etc etc? Really happy with the miner so far! There is no support for hardware control (fan speed, clocks, voltages) in the current version. We are going to add them gradually over the next few versions. For now use whatever over-clocking tool you feel most comfortable with - MSI Afterburner, OverdriveNTool, Wattman, etc. |
|
|
|
|
303
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.5d: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: February 02, 2018, 05:56:34 PM
|
Been using this miner for like 6 hours now and it's amazing. 4-5 MH/s more than Claymore, which is great!
But I'm having this weird problem right now, I have 2x RX560's which are getting 14.7 MH/s each, but every ~10 seconds they both drop to ~12 MH/s for 2 seconds and then it goes back to 14.7 MH/s. My RX580's are not doing this and are keeping strong on the 30.5 MH/s mark. With Claymore I do not have this issue, I also tested this with Ethminer and the RX560's do not drop in hashrate at all.
Would be great if you could get that fixed somehow, other than that, this miner simply amazes me, keep up the good work!
Please try using the command line option -mi with different values (for example 8, or 9 instead of the default value of 10). You can change it only for the RX560s by using it like this: In the above example the first two cards will run with mining intensity 8, and the other three - with mining intensity 10. This assumes that the RX560s are the first and the second card and you have five cards in the rig. The order of the cards must be the same that is listed by PhoenixMiner when starting up. Any plan for Linux version?
Yes, but it was pushed back in order to implement hardware control (fan speed, clocks, voltages) and dual mining for decred first. Also, it would require more testing because there are a lot of Linux distributions that are used for mining. We are planning to release it in about two months now. If you really want to make your fee lower than claymore and increase the fees you receive i'd suggest running your dev fee less often but for longer. Claymore runs his every hour.. it takes a minute for a system with a lot of gpus to spin them all up making that 30-70 seconds less effective because 10+ seconds its spinning the cards up.. then when it cuts off i have to wait for my cards to spin up to start mining again. It makes his 1% fee a lot larger than 1% an produces less for him. If you ran your fee like once every 4-6 hours instead of every 90 minutes but you ran it for an equivalent time relative to the 90 min dev fee.. we'd all make more long term. You might end up with some of the gamer miners trying to cut the fee but the people running a lot of cards 24/7 won't. Since you're not spinning up all the large farms over n over again for a short burst an instead mined for a 1-2 minutes you'd probably pull more in fees and we'd pay less due to downtime switching to dev pools. Win win for everyone.
The devfee period by itself is not the problem but the switching of DAG epochs. If you are mining any of directly supported coins (Ethereum, Ethereum Classic, Expanse, Musicoin, UBIQ, Pirl, Ellaism, Metaverse ETP, or Pegascoin), the miner will try to detect it and use the same coin for devfee, thus eliminating the DAG switch. If you mine any of these coins and PhoenixMiner fails to detect the coin correctly, use the -coin command-line option as described in the Reamde.txt file (or the first post in this thread) to force the usage of this coin for devfee and eliminate the DAG switches for devfee completely. Also, if you are mining other ethash-based coins, we will be adding support for new coins soon. Hello, 17564:12:26:44.968: main Phoneix Miner 2.5d Windows/msvc - Release
17564:12:26:44.968: main Cmd line: -pool eu1.ethermine.org:4444 -wal 0x36fd6ca7b320c46189bb9e78f5390573cace4745.Rig003 -proto 3
17564:12:26:47.093: main Available GPUs for mining:
17564:12:26:47.170: main GPU1: GeForce GTX 1070 (pcie 1), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17564:12:26:47.170: main GPU2: GeForce GTX 1070 (pcie 2), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17564:12:26:47.170: main GPU3: GeForce GTX 1070 (pcie 3), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
17564:12:26:47.210: main NVML library initialized
17564:12:26:51.887: main Listening for CDM remote manager at port 3333 in read-only mode
17564:12:26:51.887: main Eth: the pool list contains 3 pools
17564:12:26:51.887: main Eth: primary pool: eu1.ethermine.org:4444
17564:12:26:51.888: main Eth: Connecting to ethash pool eu1.ethermine.org:4444
17564:12:26:52.171: eths Eth: Connected to ethash pool eu1.ethermine.org:4444
17564:12:26:52.171: eths Eth: Starting GPU mining
17564:12:26:52.238: wdog Starting watchdog thread
17564:12:26:52.239: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_login","params":["0x36fd6ca7b320c4g07cab9e78f5390573cace4745.Rig003"]}
17564:12:26:52.294: eths Eth: Received: {"id":1,"jsonrpc":"2.0","result":true}
17564:12:26:52.295: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
17564:12:26:52.355: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0xf4b2522add423224a6cb7b8f6388076fcc9d2b37ef4576e8ee8ed4f2f1bf4242","0xb683d2a97f567602a1931b76b9fb447dd5563f0e4ab5dd69250556e7c1c94783","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4c8da2"]}
17564:12:26:52.355: eths Eth: New job #f4b2522a from eu1.ethermine.org:4444; diff: 4000MH
17564:12:26:52.360: GPU1 GPU1: Starting up...
17564:12:26:52.360: GPU1 Eth: Generating light cache for epoch #167
17564:12:26:52.381: GPU2 GPU2: Starting up...
17564:12:26:54.430: GPU3 GPU3: Starting up...
17564:12:26:55.306: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x29db229bbcc8f6acc243be972de280ed12e2a302b18c1a00eeeda7bc7b2f9fbb","0xb683d2a971567602a1931b76b9fb447dd5563f0e4ab5dd69250556e7c1c94783","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4c8da3"]}
17564:12:26:55.306: eths Eth: New job #29db229b from eu1.ethermine.org:4444; diff: 4000MH
17564:12:26:56.977: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
17564:12:26:56.977: main GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0) 3: 0.000 MH/s (0)
17564:12:26:59.874: GPU2 GPU2: Allocating DAG (2.32) GB; good for epoch up to #169
17564:12:26:59.984: GPU2 CUDA error in CudaProgram.cu:282 : out of memory (2)
17564:12:26:59.987: GPU1 GPU1: Allocating DAG (2.32) GB; good for epoch up to #169
17564:12:27:00.004: GPU2 GPU2 initMiner error: out of memory
17564:12:27:00.191: GPU3 GPU3: Allocating DAG (2.32) GB; good for epoch up to #169
17564:12:27:00.318: GPU3 CUDA error in CudaProgram.cu:282 : out of memory (2)
17564:12:27:00.318: GPU3 GPU3 initMiner error: out of memory
17564:12:27:00.400: GPU1 GPU1: Allocating light cache buffer (37.1) MB; good for epoch up to #169
17564:12:27:00.521: GPU1 GPU1: Generating DAG for epoch #167
17564:12:27:00.572: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x2e8a792c718867a8bdf1df222574c99b608f9a441e2b75bbc50af387f5842ad4","0xb683d2a971567602a1931b76b9fb447dd5563f0e4ab5dd69250556e7c1c94783","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4c8da4"]}
17564:12:27:00.572: eths Eth: New job #2e8a792c from eu1.ethermine.org:4444; diff: 4000MH
17564:12:27:00.590: GPU2 GPU2: Starting up...
17564:12:27:00.603: GPU3 GPU3: Starting up...
17564:12:27:00.848: wdog GPU thread(s) not responding. Restarting.
17564:12:27:02.073: GPU1 GPU1: DAG 13%
17564:12:27:02.084: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
17564:12:27:02.084: main GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0) 3: 0.000 MH/s (0)
17564:12:27:03.755: GPU1 GPU1: DAG 25% the same in PhoenixMiner2.4 GPU default setting Why is that? Please use a batch file to start the miner with the following contents (the important part are the setx statements to set the environment variables): 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 -clKernel 1 -pool eu1.ethermine.org:4444 -pool2 us1.ethermine.org:4444 -wal 0x36fd6ca7b320c46189bb9e78f5390573cace4745.Rig003 -proto 3
pause
Tried the 2.5d and got a lot of stale (but when I switched back to claymore I noticed a lot of stale shares too (15%+)). When the stale shares went back to normal with claymore 2-4%, I got 2.6b and tried again. Getting normal amount of stales again, so far so good.
I've noticed that the log file stays at 1 KB until I stop the miner. Is the log file in memory until I stop it? I'm worried about running out of memory.
No, the file is not kept in memory, but Windows Explorer doesn't show the size of the file properly. Press F5 while Windows Explorer is open in the PhoenixMiner folder and you will see the real size of the log file. Finally, a reminder that the release candidate of 2.6b is out with a possible fix for those that see more stales with 2.5d (and other improvements). For more information see this post: https://bitcointalk.org/index.php?topic=2647654.msg29359128#msg29359128. |
|
|
|
|
305
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.5d: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: February 01, 2018, 04:19:16 PM
|
Any chance for some nVidia performance upgrade with the new Cuda 9.1?
We've done some preliminary testing but the results are not encouraging - the difference it is very small and not always in favor of CUDA 9.1. Combined with the nuisance of having to install Nvidia drivers that support CUDA 9.1 we don't see much reason to support it until the drivers are older and more stable. I have tried your miner in my 2 GPU rig, miner starts and after 20-25 seconds later simply exits without giving any warning or error
here is the log :
...
any help?
Can you please open a command line window and run PhoenixMiner from there? Or, if it is easier for you, run the start_miner.bat file - it includes the pause command after the execution of PhoenixMiner, so the console won't close automatically and you will be able to see if there is any error message that is not included in the log file. RX 580 and the driver version is 18.1.1
I've got an RX 380 + 480 using the 17.30.1029 Blockchain driver. The firewall change didn't have any effect for me either.
We'll prepare a special version that will "spit out" more useful information about the error to give us some directions where to look for its causes. It will be PM'd to anyone who is suffering from the "Fatal error: debugger detected" problem. Just wanted to say, currently mining ether classic at 24ish mhs with version 2.4 on a 3GB 1060 verion 2.6b doesnt work as it has a cuda crashing saying not enough memory on the 1060 haven't tried 2.5d as windows defender reports some norty virus' (2.4 and 2.6b are virus free) You can safely ignore the windows defender warning (but keep in mind that it can be quite aggressive and even delete PhoenixMiner.exe without asking). Many AV programs seem to freak-out when see code that thwarts any attempts to debug or monitor the executable and declare it a dangerous. As for the memory error, this is kind of strange as we have 1060 3GB in our test rigs and they work fine with 2.6b when mining ETC. You can try to specify the -eres 0 command line option which will turn off the DAG pre-allocation and force 2.6b to behave exactly like 2.4, which didn't have DAG pre-allocation. |
|
|
|
|
306
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.5d: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: February 01, 2018, 06:14:26 AM
|
"which probably means that you have to increase the size of your page file to at least 16 GB. Let us know if the increasing of the page file size (you have to restart Windows after that in order to apply the changes) doesn't solve the problem." I had 25Gb pagefile size when i ran PhoenixMiners Please try the new version 2.6b. It is possible that the new OpenCL initialization code introduced in 2.5d is not working well with your driver and if this is the case, 2.6b should solve the problem. Another possible way to fix the problem is to create a batch file to start the miner with the following contents (the important part are the setx statements to set the environment variables): 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 -clKernel 1 -pool eu1.ethermine.org:4444 -pool2 us1.ethermine.org:4444 -wal 0xd8081f58c43bd84f9a7882f613a9d8947fb31d00.farm1
pause
Even with 2.5d now I'm unable to run the miner, though I'm starting to think it's something on my end. After further investigation once GPUs are identified in the console the error message: "FATAL ERROR: Debugger detected" is shown immediately before it crashes.
Any idea what might be the cause of this?
Can you please tell us what GPUs you are using and the version of the driver(s)? Yep, windows 10 and a legit copy. Tried the firewall.cpl thing without any luck either unfortunately.
Can you please tell us what GPUs you are using and the version of the driver(s)? |
|
|
|
|
307
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.5d: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: February 01, 2018, 05:50:57 AM
|
New release candidate: PhoenixMiner 2.6b. It can be downloaded from here: (MEGA links are no longer active) Here are the checksums to verify the download: File: PhoenixMiner_2.6b.zip
SHA-1: 83745294e4b8bd0ee9ab385b82ef7515885b8d2a
SHA-256: 57b3f97da3918232205201daf548a522a1dba920c1fccd94a483bad30420ed59
SHA-512: fb156c9ffa9fdfb042a7627386686a373bba9f9f951c924c30851f821dcfb3d62123c66a163677bc07b466d45e7fa5a3f2f2d8d4c770798afaafa4c3cfcb7d4b
Note that this is not an official release yet but will probably become such in a few days. The changes are: - Possible fix for the increase of stale shares that some are experiencing with ver 2.5d
- Made the new OpenCL initialization code optional (use -altinit option to use the new code if you experience crashes on startup)
- Added -lidag command-line option to allow slower but less intense DAG generation to prevent crashes on DAG switches (AMD only)
- Added a new interactive command in benchmark mode: press 'd' to advance to the next DAG epoch. You can use this option to test if your rig will be stable during the DAG swithes, instead of waiting up to 5 days to find out if this is the case.
- Turn off the Quick Edit functionality of the console to prevent freezing of the miner when clicking in its window (Windows 10)
- Show the IP address of the pool when connecting
- Show a '>' character in front of the pool address in the remote manager when trying to connect to a pool
|
|
|
|
|
308
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.5d: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 31, 2018, 06:21:49 AM
|
So I still have yet to find what is causing this. As per an early post in this thread with a similar issue with a Quadro GPU I understand that it's an anti-debugging feature kicking in, but I can't come up with a reason for it to do so.
Any suggestions? This miner was working amazingly for me prior to the ethermine issue and I'd love to get it running again!
There was a change in the OpenCL initialization code in 2.5 (which will be made optional in 2.6) but if you are unable to run even 2.4 then something else has changed. Did you install any new software lately - new drivers, major Windows update, etc.? I have been running PhoenixMiner 2.5d instead of Claymore for more than 24 hours and have to admit it is amazing.
My rig is 6x 1070 OC and I used to total 187 MH/s with Claymore: hashrate jumped 3.5% with same OC settings on Asus GPU Tweak II, so I was very pleased.
But the nicest part is that I was able to push OC even more with this miner, so GPUs are now running @ -91 core / +1592 mem smoothly, with avg hashrate of 196 MH/s.
Just by instaling this software and tweaking the GPUs, I gained more than 5% in hashrate, while paying less for dev fees.
ABOUT STALE SHARES: I have 28 after 24 hours, amounting to 1.36% on the total. Since I have no reference (first time mining with Phoenix), let me know if it's similar to what you are getting.
QUESTION: do you know if ethermine allows sending stale shares? I am not specifying the "-stales <n>" parameter, hence it's defaulting to 1 = "send stales"
So, I want to thank PhoenixMiner for the fantastic job and the great software.
Please keep squeezing performance from our almost-exhausted GPUs
Ehtermine do accept stale shares as do most of the other pools. While they do not credit the shale shares at the same rate as normal shares, there is no downside in submitting stale shares if the pool accepts them. If the pool rejects all stale shares, you can stop sending them by using the -stales 0 (or -stales2 0 for the fail-over pool). You should check about your pool but as far as we know (and we can be wrong) from the big pools only nicehash doesn't accept stales. Another thing connected to stale shares is that we can't give 100% accurate assessment which shares are stale. The reasons are explained in our first post in this thread in the FAQ section: Q003: What is a stale share?
A: The ethash coins usually have very small average block time (15 seconds in most instances).
On the other hand, to achieve high mining speed we must keep the GPUs busy so we can't switch
the current job too often. If our rig finds a share just after the someone else has found a
solution for the current block, our share is a stale share. Ideally, the stale shares should be
minimal as same pools do not give any reward for stale shares, and even these that do reward
stall shares, give only partial reward for these shares. If the share is submitted too long
after the block has ended, the pool may even fully reject it.
Q004: Why is the percentage of stale shares reported by PhoenixMiner smaller than the one shown
by the pool?
A: PhonixMiner can only detect the stale shares that were discovered after it has received a
new job (i.e. the "very stale") shares. There is additional latency in the pool itself, and in
the network connection, which makes a share stall even if it was technically found before the
end of the block from the miner's point of view. As pools only reports the shares as accepted
or rejected, there is no way for the miner to determine the stale shares from the pool's
point of view. The TLDR; version is that the estimated stale percentage shown by PhoenixMiner (or any other miner that reports stale shares) is at best equal, and in most cases lower than the final stales percentage, for which you should refer to the pool statistics. So why do we even bother to report it? Because high estimated stale percentages shown by PhoenixMiner indicate a latency problem in the rig itself and/or the miner options. For example the -mi (mining intensity) option can increase your hashrate but at the cost of higher latency, which leads to more stale shares. The default value of 10 works fine in most cases but if you like fine-tuning, play away, just know that there are trade-offs. @PhoenixMiner - please research a bit the stale problem. With 2.5d i get 3, 4 even 5 times more stale vs. 2.4. Anyway, the miner is amazing, getting 6 mhs more from 192 to 198 mhs with 6 rx 580. Good job. Also, please add to the miner cclock, mclock, cvddc, mvddc and other commands from Claymore, it would be really awesome. 24hours is way too little to make any measurements, you need 4-5 times that to get a good picture - From my experience phoenixminer, even the 2.5d is giving me more shares per day on ethermine compared to claymore, I actually have a machine with 12xRX580 which consistently underperforms with claymore miner, giving me fewer shares per hour than it should, on phoenix that machine runs smooth as butter.
V2.5d appears to have some stale share issues, it is actually leveling out a bit for me, but are still producing about 50% more stales compared to 2.4 - But 2.5d solves a problem which I have been having on one of my machines so overall there is improvement to track.
While we can't see a significant change in the stale shares on our test rigs, one of the changes that we hastily made in 2.5d in an effort to prevent the ethermine connectivity problems could be causing this for some users. As we now know that that has nothing to do with the connectivity problems, we are rolling back these changes, so 2.6 should fix any unusual issues. The beta of 2.6 is already undergoing internal testing and will be released in less than 24 hours. The hardware control commands (cclock, mclock, cvddc, mvddc, etc.) are our next priority. Version 2.7 will contain some experimental support but we would need to test a lot on a matrix of GPUs and driver versions before releasing it. Please note that only AMD provides open access to its Overdrive API via the ADL library. While Nvidia has similar capabilities via the NVAPI, the hardware control and overclocking are only available if the developers are pre-approved by them. We will try to get access but it's probably not going to happen. So, at least for now the hardware control capabilities will be limited to AMD cards. |
|
|
|
|
309
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.5d: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 30, 2018, 08:46:09 AM
|
2.5D seem to have hash rate inconsistensies compared to 2.4 . sometimes hash rate drop big time for some cards, 5mhs or so , compared to 2.4
The only thing than can be possibly linked to this is the new OpenCL initialization code (if you are using AMD cards?). We will make it optional in the next version if there are more reports of such behavior as the solved problem by the new code (occasional crashes on startup) is quite rare. Hii
I have Radeon RX 570 GPU's and i have problem with PhoenixMiner 2.4 and 2.5d on Windows 10
I try with drivers : Adrenalin 17.12.2 and Adrenalin 18.1.1
On Windows 7 with Adrenalin 17.12.2 and Adrenalin 18.1.1, PhoenixMiner 2.4 and 2.5 works fine
Thank you for the log. As you have the same problem with both 2.4 and 2.5d, this isn't caused by the new OpenCL initialization code. OpenCL error -6 is CL_OUT_OF_HOST_MEMORY, which probably means that you have to increase the size of your page file to at least 16 GB. Let us know if the increasing of the page file size (you have to restart Windows after that in order to apply the changes) doesn't solve the problem. I looked forward to 2.5 as I had problems like the others with it not making connections
...
but
...
2.5d doesnt seem to be working quite right either, unless now at least it will continue with the connection it had.
We tested with the same devfee pool by disabling all others (eth-eu2.nanopool.org:9999) and it worked fine. Probably a temporary connection issue. Furthermore, 2.5d has at least one backup devfee pool (and in most cases two), so this shouldn't be a problem. guys I have to say I am bit disapointed that you can develop kernel that can run radeons about 2-3% better (for me its about 20USD per day) But you cant contact pool providers to inform them about new miner.... Its quite logical that when your miner got popular it raised red flaggs on pool. Its like botnet when so many IP adresses are mining for one wallet.... And also you should heve issued warning ASAP not to use it until you make it right with pools.
At first we though that ethermine was having difficulties with the spike in Ethereum hash power lately. As soon as we realized that the block is targeting our miner, we published a warning message here. You are probably right and we should have tried to contact them beforehand but it's a bit of chicken and the egg problem - if (almost) nobody uses our miner why should they believe us and white-list us just based on our word? Additionally, outright blocking IP-s is probably not the best way to deal with a potential botnet. Perhaps it would be better to just "shadow-ban" the suspicus devfee-like connections and accept shares as normal but don't credit any coins to these addresses. In this way if the connections are from malicious software, the bad guys would give up because there is no upside to continue. And if it is a legitimate miner as ours, it would only affect our devfee, not the users of our miner, which was way, way worse. Anyway, it seems that the issue is fully resolved now - ethermine and ethpool work normally with PhoenixMiner (even the older versions). Kudos to ethermine for reacting so quickly, they really are top notch. Unfortunately the few bad apples in this business make the life harder for everybody else. I also wish I was younger, I used to code a lot.. Id also have taken a stab at building a miner, package it up so its a service, quietly doing its thing.. its not like I dont know how to code for linux and windows.. Im sure I could have done something but now Im older i get home and the enthusiasm just has worn out..
I did 6502 and Z80, I'm THAT old  Our average age is closer to 40 than to 30 It is fun but the last two days (and nights) were anything but. There was a lot of swearing, hair pulling, and face-palming in our office. To continue the side note, one of our programmers is really into retro computing. His house is like a computer museum. His remark: "6502 wasn't fun to write for, 8080/Z80 was much better, and when the IBM PC came out, the 8088 assembly was like writing in high-level language, compared to 6502". |
|
|
|
|
310
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.5d: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 29, 2018, 11:24:00 AM
|
Yes, new account user posting about PhoenixMiner, hot damn! (Old one got hacked).
I have been using 2.4 for some time, a good 8-10 hours yesterday and got hit with the IP block aswell, I reached out to ethermine.org and just got this reply back:
"The dev fee mining of the Phoenix miner on ethermine triggered our botnet detection and caused a temporary IP block. We have now adjusted our botnet detection system which resolved the problem. We are very sorry for the inconvenience. In general we encourage mining software devs to reach out to us prior to making their software generally available in order to avoid such issues. From the point of view of a mining pool dev-fee miners look exactly the same as botnets."
It appears that the issue even with 2.4 should be resolved in that case, but as a DEV please reach out to them and work with them to solve issues like this.
You most likely did not see this problem as there were too few actually using your miners.
Thank you for sharing this. This seems quite plausible but we don't think that the solution is that simple. After all what's to stop the author(s) of actual botnet to pretend to be miners and ask for directions how to avoid being blocked by their pools?  At the moment it seems that all ethermine pools stopped blocking our miner (at least the latest version) but we would advise to use other miner software on these pools for at least 12 hours. This would give us more time to confirm that the problem is really solved. |
|
|
|
|
311
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.5d: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 29, 2018, 09:05:56 AM
|
PhoenixMiner 2.5d is released (see the first post of the theme for details). If you are using older version of PhoenixMiner and you want to mine Ethereum, you must upgrade to 2.5d to avoid connection issues. Here is the download link: (MEGA links are no longer active) New in version 2.5d:- Removed the usage of ethermine/ethpool for devfee to avoid connection issues
- Added -eres command-line option to allocate DAG buffers big enough for 2 or more DAG epochs after the current one
- New OpenCL initialization code for better stability on DAG generation in multi-GPU rigs
- Stop mining if the connection can't be restored after some time to avoid wasting electricity
- Recognize failed connection attempt even if the pool doesn't close the socket
- Longer reconnect delay
- Several other small changes and impovments, mainly for stability
|
|
|
|
|
312
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.4: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 29, 2018, 08:35:08 AM
|
UPDATE on Jan 1, 2018: The problem is fully resolved, thanks to ehtermine.org. You can mine Ethereum (including on ethermine and ethpool pools) with all versions of PhoenixMiner. Here is the old message for reference: Please avoid using PhoenixMiner on ehtermine or ethpool. It appears that they have something against our miner and this is quite unfortunate because we were using them for devfee. If you want to use ethermine or ehtpool, please use another miner for now to avoid connection issues. All other pools seem to work fine but the devfee is messing the things up when mining Ethereum. The new version of PhoenixMiner without any usage of ehtermine/ethpool for devfee will be posted here in less than an hour.
Please take our deep apologies about these problems but we had no way to foresee that as we have tested PhoenixMiner privately for many weeks before releasing the first version and we haven't had any issues with them at that time. 
If you mine any coin other than Ethereum you are not affected by this. With the new version, the problem will go away for all other pools except ethermine/ethpool.
|
|
|
|
|
313
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.4: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 28, 2018, 06:31:17 PM
|
New Version? ?  Unfortunately we have found a bug in the new version which caused crashes on few of our test rigs. The good news is that we managed to reproduce it after a few hours and it was fixed but as a result we have run the latest build of 2.5 only for an hour so far, so we are not feeling confident to release it tonight even for a beta test. It will be released first thing tomorrow, unless something else comes up during the overnight testing. QUESTIONS TO DEV: do i have to take any additional steps for the buggy Vega64s and the super buggy Frontiers? can i expect at least the same hashing speeds maybe a little faster?
im using moded Reg tables and unlocked SoC with Ntool to regulate GPU values
migration can cause serious issues for my rigs (i have previous experience) as the 64s and FEs are like Supercars, faster than anything around but super sensitive to changing telemetry (and before you start yelling efficiency rating i pay $0.04kW/h so i litteraly dont care about Wattage my concern is max stable hashing speed, in any case they are running at av 180W)
btw DEV, you really want to make a difference? write the miner which will utilise 4 simultaneous threads for the FE on Cryptonight addressing the 16Gb mem into 4Gb per thread, much like the 2x4Gb on the 64-56 getting 2000H/s from cryptonight.
We only have a pair of Vega56s to test here and it seems that right now to get anything Vega-based is mission impossible. On Vega56 we are getting slightly better speed than Claymore but please only test on one rig first, and only after PhoenixMiner 2.5 is released (the official release will be most likely in Wednesday), as we have found that 2.4 and earlier versions can be occasionally unstable on highly overclocked rigs so we've made a lot of stability changes in 2.5. While we see a CryptoNight version in our future, for now we are firmly focused on ethash, as we have a lot of features to add to PhoenixMiner. can you please add the -tt command functionality? maybe it works? but its not listed in the readme or command list so i assume its not there currently.
this is my favorite feature on Claymore. auto fan speed control without having other software is extremely useful. without it, the cards to to target 85C and i dont want them running that hot. -tt 70 on claymore keeps eveything nice and kosher.
No, it isn't supported in the current version (and won't be included in 2.5) but we have planned for it and we are definitely going to implement -tt and the clocks/voltate options in the near future (at least for AMD cards). The problem is something else. Let me explain my situation. I have 7 rigs at home out of which 1 was running your miner and other were on claymore. I have another 20 rigs at my warehouse, all running claymore. All 27 rigs are on us1 servers of ethermine. At night all my home rig had connection issue but my warehouse rigs were fine. My internet connection was good as I was able to mine on other pools. us1 servers of ethermine was good as all my warehouse rigs were doing fine. It seems that us1 and eu servers of ethermine were blocking my IP after using your miner.
I dont know what happen but us1 servers of ethermine was good yesterday.
We have used three different ISPs to analyze the problem and we think we found what is causing it. Basically their servers are extremely busy and sometimes they refuse new connections (the devfee requires a different connection to the pool). This affects all miners but what seems to make matters a bit worse for us is the short default reconnect period of 7 seconds. So in version 2.5 we've increased the reconnect period to 20 seconds and added some failover devfee pools. However the network hashrate is increasing so fast that the pools are going to be strained for some time. It is best to have a least a few failover pools to avoid downtime as much as possible. |
|
|
|
|
314
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.4: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 27, 2018, 05:38:42 PM
|
|
Unfortunately, eu1 and us1 servers of ethermine were very unstable earlier today, which doesn't happen often. The problem was exacerbated by the fact that we are using ethermine.org almost exclusively for devfee on Ethereum, so even when another pool is used, the devfee will fail and cause some errors. The issue was that once you try to make a new connection, the pool closes both the new connection and the existing connection, so we were affected more than some other miners that don't use ethermine.org for devfee.
It seems that now the servers are stable.
On our part we are changing the devfee code to fall back to other pools if ethermine is inaccessible but this will help only if you have other fallback pools besides ethermine.org for the rare occasions when it is down or unstable. The beta version of PhoenixMiner 2.5 will be released tomorrow and it will address most of the stability issues.
|
|
|
|
|
316
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.4: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 27, 2018, 05:55:10 AM
|
Minor issue - when I'm scrolling up the window by holding the scrollbar button, the miner freezes and doesn't resume automatically when I lift the button.
This probably is the Windows 10 "feature" QuickEdit. Here is how to solve the problem: https://stackoverflow.com/questions/33883530/why-is-my-command-prompt-freezing-on-windows-10. Really liking 2.4, about 5 MHs faster then the competition for me do you have plans to make a CryptoNight (ETN/XMR) Miner too? that would be great! Nothing definitive yet but after PhoenixMiner is more or less feature complete, Equihash and CryptoNight miners are the obvious next projects. Still, it would be in the more distant future (at least six moths from now or even more). Since dual mining is dead I probably won't try this until it supports just mining ETH.
Actually ETH-only mining is the only mode that we are currently supporting. Even after we introduce dual mining, the ETH-only mining will continue to be given the most attention. Should the reported hashrates be stable like with Claymore? Mine seem to be jumping here and there (1-2%).
The hashrate that is reported to the pool is the same as the 5 min average hasrate displayed on the PhoenixMiner console window (unless the miner is paused). We could provide a longer window to filter the rate more but we feel that it is better to see the actual real-time hashrate instead of some highly filtered average value (and longer windows would require a little bit processing). Hi, I am using gtx1060 geforce for it and it keeps on showing :
GPU 2: unable to get fan speed unknown error (999)
GPU 3: unable to get fan speed unknown error (999)
and after sometime it accumulates :
GPU 2: unable to get fan speed error (999)
GPU 3: unable to get fan speed error (999)
GPU 5: unable to get fan speed error (999)
This is an NVML (the Nvidia hardware monitoring library) internal error. We have seen similar errors on our GTX1060s. Additional symptoms include high CPU usage (either by the miner or the MSI Afterburner). The same problems were also observed with Claymore's miner on the same rig. The short term-solution is to restart the rig (not just the miner) but the only long-term solution is to lower the memory overclock a little. We have found that even 20-30 MHz lower memory clocks completely solve the problem. Or you can continue mining and ignore the errors but the high CPU usage can be a real PITA when trying to control the rig via VNC or TeamViewer. I am getting this same error on 2 rigs
We have found the possible reason and have fixed the issue in 2.5, which is currently undergoing internal testing. If there are no bugs, we will release it for evaluation later today or tomorrow. NOTE. It seems that ethermine.org has problems again. Version 2.4 has a bug and continues to mine even if it is unable to reconnect for a long time. If you don't have failover pools other than ethermine.org please check your miners. |
|
|
|
|
317
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.4: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 26, 2018, 05:46:02 AM
|
Love Phoenix Miner, really is fast. I just got version 2.4 as well. But I having one issue, hoping someone can help me out. I can mine to any pool I wnat to all day long but when I try to mine to my geth node on my mineer I get the following:
...
What am I doing wrong with Phoenix Miner, I know if has to be something simple I am missing here? Thank you.
You are not doing anything wrong, it's just that we don't support solo mining yet. There is noting really hard to prevent us from implementing it but in 99% of the cases it's not very practical with the difficulty of most coins. However if there is enough interest (or at least after we implement more urgent features like control over clocks and voltages, and dual mining), we are going to implement it. Told you, SIA GPU mining is dead already
Yes, you were spot on. It was mainly wishful thinking on our part to assume that it would take more time before ASICs made siacoin GPU mining obsolete. Still we are too far into implementing dual mining with decred, so we are going to release it anyway whenever it is ready. Even if it is completely useless by then, at least we will have some experience with implementing it that would hopefully translate to some other coin that can be dual-mined with ethash profitably. |
|
|
|
|
318
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.4: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 25, 2018, 06:38:26 AM
|
what those two options change?
-mi when i use the default 10 i have a constant mhs, when i put 12 i have some up and down so what better?
-gt seem to not change a lot
The first option (-mi) changes the size of each "chuck" of work that is send to the GPU. The lower numbers mean generally lower and more unstable hashrate but you will be able to use your GPU for normal work without stuttering of the display, which is useful if the GPU is used for anything else than mining. Values above the default 10 aren't recommended because while they can marginally increase the hashrate, the number of stale shares will also increase and some GPUs may become unstable. The second one (-gt), which can also be changed with + and - keys when the miner is running, is a way to fine tune the GPU for maximum hashrate. Because the memory timings of each GPU can be a little bit different (especially after BIOS mods and overclocoking/underclocking), the default value of 15 may not be the best (although we have found that it is the best for the 90% of the GPUs). Please note that both -mi and -gt can be specified per-GPU, for example -mi 0,10,10,10,10,10 if you want only the first GPU of six GPU rig to mine with low intensity while using the PC and the display is connected to the first GPU. One of the units crashed but did not report again to claymore manager and hash and everything looked correct. It was just scrolling dev fee disconnected and stopped or something like that. over and over and over again
Closed it and relaunched and it started to work as normal.
We have implemented a 180 second timer in version 2.5 that will stop the mining and report 0 hashrate to the manager in cases of lost connection that can't be restored. But the devfee disconnection issue is something new and will be fixed thanks to your report. Most probably the connection was lost at some short time period while the devfee was ending and some kind of race condition caused the loop. The miner didn't switch to the backup pool after one of ethermine's servers dropped. Needed a manual restart:
today i got message unable to submit share to pool, but my other rig was connected just fine phoenix 2.4 as always. using ethminer eu.1 pool port 14444 , no failovers.
mitrobg -- maybe happend the same time with u and me also? weird.
We had the same problem at exactly the same time with eu1.ehtermine.org but our test servers reconnected successfully. Thank you for the log - from it seems that connection to the pool was restored but it never replied to the authorization request from PhoenixMiner and it didn't close the socket, so the miner was left waiting forever for the authorization from the pool. We will include a code to detect such weird pool connection issues in version 2.5. Pls add support for mining VIC without DAG switch on devfee. Thank you. We will look into it but it would probably have to wait until 2.6 as the stability improvements and fixes are with higher priority. I notice there are some error "eth share timeout in xxxxx s". It happen once a while (about 3-4 hrs). I guess it is some kind of warning. What is it actually? Thanks!
After finding a share, the miner waits for a confirmation from the pool if it was accepted or rejected. Only after this confirmation, the share is included in the effective hashrate calculations and other statistics. If there is no confirmation after some (fairly long) time, the miner "writes off" the share as rejected. This message notifies you that a share that was found a few hours ago never received accept or reject response from the pool and was therefore considered rejected in the stats of the miner. There is no reason to worry about these messages if they are infrequent. If the happen too often, it means that the pool is overloaded or has same issues and doesn't respond properly to the found shares. |
|
|
|
|
319
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.4: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 23, 2018, 04:54:45 PM
|
|
PhoenixMiner 2.4 is officially released. There are no changes from the release candidate that was released a few days ago so if you are already using 2.4, no need to download and install again.
We now are working on 2.5, which should include a few fixes for the DAG allocation and generation instabilities, and a fix for continuing mining when the miner is unable to connect for more than a few minutes. A per-GPU minimal speed will also be implemented, allowing finer control over GPUs slowing down for some reason.
|
|
|
|
|
320
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: PhoenixMiner 2.3: fastest Ethereum/Ethash miner with lowest devfee (Windows)
|
on: January 23, 2018, 04:41:09 PM
|
I tested the phoenixminer 2.4 and its showing gpu2 fan error and gpu5? any fix on this?
Are you using Adrenalin driver 17.12.x? If so, please upgrade to the newest driver, which should fix the problem. i try 2.4. sometime reported hashes on the pool is not registered. Need to restart miner.. Any solution for this?
Most probably the problem is with the pool - we have seen such problems some pools, which sometimes do not show the reported hasrate (but accepts shares and shows the effective hashrate normally). If the problem persists, please let us know which pool you are using to try and reproduce the problem. Yep this is a bad problem.... it just sits there trying to connect to the 2 pools in config and the other 2 in epools and never connects. If I shut PM down and just restart the app it connects and works fine. FIX THIS it's a bad problem and with that said back to claymore I go until I can get a confirmation this is repaired.
Thank you for trying our miner. The first problem (with the "connection attempt aborted" errors) is already fixed in PhoenixMiner 2.4, which is now being officially released. However we will also fix the continuing mining after the connection is being lost for any reason. In such cases the mining will stop after a few minutes and this will be properly reported to the remote manager. We are also adding some DAG switching stability improvements in version 2.5 and we will net you know when it is ready. |
|
|
|
|
Show Posts
