Hello all,
I'm trying my hand at Whale Coin mining, but I can't seem to connect to the server. Please help. Here's the config.txt, please let me know if you see anything funky. The same general configuration seems to work on ethermine.org. (for eth, obviously.) Thanks in advance.
config.txt:
-pool stratum+tcp://whale.minerpool.net:8008
-pool2
http://whale.minerpool.net:8888-wal 0x51312ad92329C2887e0b14d24a5Ac8a9Bc21c80E
-worker Miner49er
-pass x
-coin whale
-proto 1
-cdmport 3333
-cdm 2
Remove the -
proto 1 from your config.txt - minerpool uses eth-proxy stratum protocol, which is the default protocol for PhoenixMiner.
2018.04.29:20:37:58.645: GPU2 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.29:20:37:58.645: GPU2 GPU2 search error: unspecified launch failure
2018.04.29:20:37:58.674: GPU1 CUDA error in CudaProgram.cu:264 : unspecified launch failure (719)
2018.04.29:20:37:58.674: GPU1 GPU1 search error: unspecified launch failure
2018.04.29:20:37:58.791: wdog Thread(s) not responding. Restarting.
2018.04.29:20:38:02.402: main Eth speed: 57.008 MH/s, shares: 21/0/0, time: 0:20
2018.04.29:20:38:02.402: main GPUs: 1: 24.358 MH/s (14) 2: 32.650 MH/s (7)
I got this error on Gigabyte WF OC 1070 every 5~20 minutes running 2.9e
Phoenix is 2.9e .3mh/s faster than Claymore 11.7, but claymore can run at least 5 hours before hit "unspecified launch failure" error.
Is it because Phoenix runs at higher intensity than claymore?
I cannot use -dcri option to tune nVidia cards in claymore? Can I fine tune nVidia card at the miner startup (command options)?
Please try using
-nvnew 0 in the command-line (or in config.txt file if you are using it). This will revert to the old CUDA kernels. Please let us know if this fixes the problem (it is not the best fix as it will lower the hashrate and increase the stale shares but we need to know if the problem persists with the old kernels). -gt (and -dcri) is only for AMD cards, at least until we implement dual mining.
hello,
i have to say, i like this miner very much, but have 1 problem.
i have rig with 12 x rx580 cards,
i set parameter -minfan 90 , but it doesnt work, fans still work as default
any advice ?
thanks
If you are using the blockchain beta drivers (or any driver older than 18.x.x) all bets are off - these drivers has quite buggy ADL implementation. If you are using 18.x.x drivers, please check the log for
set auto fan speed: message or
Unable to set auto fan speed, or
fanmin (xx) is bigger than fanmax warnings.
Hello, I'm using 2 RX 580 GPUs
When I use -clKernel 0
The hash rate moves up & down, most of time it is showing 64 MH/s, sometimes go down to 58 MH/s
The average 5 min. is just above 58 MH/s
When I use -clKernel 1
The hash rate is more stable, most of the time is 60 MH/s sometimes go down to 59.7 or so
The average 5 min. is about 59.8
With kernel 0, looking at it, the average appears to be over 62 MH/s
What I must believe the 5min. average or what I see on the screen?
Could the average 5 min. with kernel 0 be wrong?
& why just after starting miner it tell me the 5 min. average when I have been only mining for 1 min. or even less?
Thank you.
The 5 min average obviously is not very accurate until at least 5 minutes have passed. If the DAG generation is slow then you should wait for at least 5 minutes
after the DAGs are generated before checking the average speed. Finally, the 5 min average speed is better indicator for the speed than the momentary speed (which is also averaged but only over 15 seconds by default).
Uh ..
Eth: Accepted shares 49778 (276 stales), rejected shares 3 (0 stales)
Eth: Incorrect shares 4 (0.01%), est. stales percentage 0.55%
Eth: Maximum difficulty of found share: 33297.4 TH (!!!)
Max share difficulty of 33000? So 10x the network difficulty of 3200 TH?
There is a very very very slim chance that rig found a block, but 33297 seems more like a software calculation error :/
No, there is no error, you have found a block. The probability of finding solution with such difficulty is low but it isn't zero. You can check the logs and find when exactly you have submitted this share and then check with ETH blockchain explorer if a block has been found around this time - it should be by your pool.
Hi just tried new amd driver 18.4.1. I get error errors on vega 64;
windows 10 pro
2018.04.30:19:12:24.575: GPU1 build: Failed to GPU1 program: clBuildProgram (-11)
2018.04.30:19:12:24.575: GPU1 GPU1: Failed to load kernels: clCreateKernel (-46)
tried using
-clKernel 0 and 1 no luck.
We will check with the same driver. We only have Vega 56s but the error should be the same for both.
Hello Admin
-stales not working in new version.
Reported Hashrate 0
Please note that
-stales is per-pool setting. If you have several pools in epools.txt, you have to specify
STALES: 0 for each of them otherwise, it will submit stale shares as this is the default. The option to disable reporting hashrate to the pool is
-rate 0 and it is global, i.e. it affects all pools.
hi,
there is one more problem,
for pausing a single gpu, i press 1..9, but what if i have more then 10 gpus, and i need to pause #12 ?
thanks
Press 010 for GPU10, 011 for GPU11, etc. This is key 0, followed by key 1, followed by key 0.
Hi PM developers. I have caught 719 error again two times
...
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
Rig configuration in my footer.
Please try to use
-nvnew 0 and see if the error happens with the old CUDA kernels. We have some suspicions what may be the reason but so far we were neither able to reproduce it, nor to pinpoint any definitive cause like job switching or something else that could cause these crashes. If
-nvnew 0 doesn't help, please try adding
-nvf 2 (along with
-nvnew 0).
We have tried contacting the anti-virus makers about this, and one actually responded (Kasperski) and "un-flagged" the first release but it become apparent that we would need to go through this process every time, as their automated scanning algorithms doesn't like any program that uses advanced anti-debugging techniques. We don't have the time and resources to submit each new release for manual review and wait for the result, so it is what it is. You can be sure that the executable is clean if you have downloaded from the link in the first post, and if you want to be absolutely sure, check if the .zip checksums match these that are listed in the first post.
I think the "Every 5 seconds" shown speed or the average 5 min. are wrong.
With my 2 x RX580 & -clKernel 0
I have been looking carefully for some 15 min. periods, at the screen I see:
70 % of time 64+ MH/s (rarely up to 65)
15 % 62 MH/s
15 % 58.1-58.2
The average 5 min. shown is 57.9 to 58 after 15 min., lowest than the lowest 5 seconds speed.
Also the average goes lower within time while the 5 sec. are the same.
I think the same happens with Kernel 1 but differences are small & it is harder to know for sure, I have not tested it carefully yet.
Looks like the 5 min. average is metering the lowest H/s or I don't know what.
More:
I checked it again this time for more than 30 min.
The lowest 5 sec. have never been below 58.15 (Most of time between 58.2+ & 64.7+) while the highest average 5 min. have never reached 58.1 MH/s (58.08 at most, usually below 58).
So, something is not OK.
-clkernel 0 is actually the slowest version of the kernels that aren't optimized for any particular GPU, so you should believe the average setting (and it is more accurate than the momentary most of the time). We haven't tested much with -clkernel 0 but such large discrepancies between the momentary and average speed are unusual and are indicators that your hashrate is quite unstable. Use the parameter -gswin 0 to see the real momentary hashrate (not averaged over 15 seconds as default) and you will probably see it jumping wildly with -clkernel 0.
One of my rigs stopped mining earlier today. Turned out it was Windows Defender that moved the PhoenixMiner.exe into the quarantine categorised as "Trojan:Win32/Tilken.B!cl"
Did restore the .exe and disabled Windows Defender. The threat in my opinion is Windows Defender, not the miner.
Windows Defender Details:
Trojan:Win32/Tilken.B!cl
Alert level: Severe
Status: Active
Date: 02/05/2018
Recommended action: Remove threat now.
Category: Trojan
Details: This program is dangerous and executes commands from an attacker.
Affected items:
file: C:\dev\Ethereum\PhoenixMiner_2.9e\PhoenixMiner.exe
process: pid:10100,ProcessStart:131683638871312779
A less radical solution is to add the folder that contains PhoenixMiner.exe to the list of exclusions of Windows Defender. In this way you can both mine and have Windows Defender turned on.
when phoenix in hive os???
Whenever we finish the long-awaited Linux version.
Who can say - why sometimes speed 1 of cards drops from 31M to 25M untill restarting miner?
Sometimes it is just Windows messing with one GPU (probably the active one, if you have a display or display-emulating "plug" in it). In such cases the hashrate recovers within few minutes.
IAMTUTU - Thanks for finding my additional error! In my haste of copying pasting between bat files, I jacked that all up. Got that part fixed, but am getting this error.
2018.05.02:13:15:40.936: GPU2 GPU2: Generating DAG for epoch #43
2018.05.02:13:15:40.971: GPU9 CUDA error in CudaProgram.cu:102 : an illegal memory access was encountered (700)
2018.05.02:13:15:40.971: GPU9 GPU9 initMiner error: an illegal memory access was encountered
2018.05.02:13:15:40.971: GPU10 CUDART error in CudaProgram.cu:127 : an illegal memory access was encountered (77)
2018.05.02:13:15:40.971: GPU10 GPU10 initMiner error: an illegal memory access was encountered
2018.05.02:13:15:41.071: GPU11 CUDART error in CudaProgram.cu:127 : an illegal memory access was encountered (77)
2018.05.02:13:15:41.071: GPU11 GPU11 initMiner error: an illegal memory access was encountered
2018.05.02:13:15:41.071: GPU4 CUDART error in CudaProgram.cu:127 : an illegal memory access was encountered (77)
2018.05.02:13:15:41.071: GPU4 GPU4 initMiner error: an illegal memory access was encountered
2018.05.02:13:15:41.071: GPU5 CUDART error in CudaProgram.cu:127 : an illegal memory access was encountered (77)
2018.05.02:13:15:41.071: GPU5 GPU5 initMiner error: an illegal memory access was encountered
2018.05.02:13:15:41.071: GPU2 CUDART error in CudaProgram.cu:127 : an illegal memory access was encountered (77)
2018.05.02:13:15:41.071: GPU2 GPU2 initMiner error: an illegal memory access was encountered
2018.05.02:13:15:41.071: GPU7 CUDART error in CudaProgram.cu:127 : an illegal memory access was encountered (77)
2018.05.02:13:15:41.071: GPU7 GPU7 initMiner error: an illegal memory access was encountered
2018.05.02:13:15:41.071: GPU3 CUDART error in CudaProgram.cu:127 : an illegal memory access was encountered (77)
2018.05.02:13:15:41.071: GPU3 GPU3 initMiner error: an illegal memory access was encountered
2018.05.02:13:15:41.129: GPU1 GPU1: Using new optimized OpenCL kernels (device name 'Ellesmere')
2018.05.02:13:15:41.129: GPU1 GPU1: Allocating DAG for epoch #43 (1.34) GB
2018.05.02:13:15:41.129: GPU1 GPU1: Allocating light cache buffer (21.4) MB; good for epoch up to #43
2018.05.02:13:15:41.184: GPU1 GPU1: Generating DAG for epoch #43
Thoughts?
Please send us the log file from the start to the occurrence of the error (it should happen in the first minute or so when creating the DAG).
this have claymore source in it i found it. it a timebomb that will mess with Gpu voltage to Blowed it
there is no phoenix, this was made by claymore to further his Strength in claymore miner monopoly.
after he explode all gpu, no one will ever use any other miner but claymore.
i will release my proof in 48 hours.
Dude, check your calendar, April 1th was two months ago.
While it is tempting to think that you are paid shill, the reality most probably is that you are too emotionally invested in Claymore's miner and you are posting this BS for free. Whatever the reason, please GTFO with your FUD.
