 Show Posts
|
|
Pages: [1]
|
is it possible to change the default API listening port? for some unknown reason windows update borked my PC and its constantly telling me its rejected. firewall and router settings are definitely okay, and im hoping the port can be changed easily since I don't want the downtime of a reinstall.
You can edit the respective <miner_name>*.ps1 file inside the Miners folder. You'll see 2 places were this is used "$($Variables.MinerAPITCPPort)", replace that with the port number you want to use. |
|
|
|
|
Possible memory leak?
Been running 2 instances of NPlusMiner 1.3 for 2.5 days and the memory usage slowly ramped up to both 800MB memory and 800MB Commit size, restarted the miners and they've started to ramp up again.
|
|
|
|
|
To change the currency just add it to your Worker Name, here's what mine looks like:
ID=Miner1,c=LTC
No spaces.
|
|
|
|
I'm wondering why Equihash has such a high BTC/GH/Day compared to the others? Miner Algorithm Speed mBTC/Day BTC/Day USD/Day BTC/GH/Day Pool
----- --------- ----- -------- ------- ------- ---------- ----
ccminerAlexis78 Lyra2RE2 122.01 MH/s 0.683 0.00068 5.656 0.00560 miningpoolhub-Monacoin
CcminerAlexis78Phi Phi 54.59 MH/s 0.590 0.00059 4.890 0.01082 blazepoolplus-
ccminerAlexis78 X17 33.14 MH/s 0.571 0.00057 4.732 0.01724 blazepoolplus-
RavenMiner225RVN X16r 25.12 MH/s 0.500 0.00050 4.139 0.01989 zergpoolplus-
CcminerTpruvotx64 Lyra2z 5.53 MH/s 0.499 0.00050 4.132 0.09017 zergpoolplus-
CcminerAlexis78xevan Xevan 10.44 MH/s 0.464 0.00046 3.839 0.04438 zergpoolplus-
DSTM Equihash 1.27 KH/s 0.447 0.00045 3.702 352.43966 miningpoolhub-Zcash
ccminerAlexis78 C11 48.00 MH/s 0.391 0.00039 3.241 0.00815 zergpoolplus-
EthashClaymore Ethash 72.74 MH/s 0.362 0.00036 2.998 0.00498 miningpoolhub-Ethereum
Thanks It's just the nature of the algorithm, if you see your hashrate is only in kH/s while the others are in MH/s so at the end it just evens out. |
|
|
|
I gotta back MrPlus on this one, Excavator and HSRminer are the best for neoscrypt, giving 5-8% more than KlausT, but for people like myself with weak GPUs (Celeron 3930) and using +50/+600 OC and not having that much time to fine tune every setting, KlausT is way more stable (both Excavator and HSR would crash out of the blue).
Celeron 3930 is okay CPU for any decent rig with at least 8 x 1070 GTX. Saying that miner crashes or unstable is incorrect - it's like saying that Windows 7 is unstable OS and often BSOD for no reason - and the only reasons why it can give you blue screen are that you either have faulty hardware (ram, cpu, gpu, etc), overclocked too much cpu/ram/gpu or you've installed some buggy driver that forced kernel to BSOD. You should understand that crash is not software-related. It's not hsrminer that crash - it's your hardware (GPU) can't handle load from compute-intensive algo like neoscrypt with your current overclocking settings and fails - so cuda kernel that executes on GPU fails too - you get "crash". Reason why ccminer klaust seems "more stable" is very simple - it just doesn't load gpu as much as hsrminer or excavator due to lower default intensity (or not that intensive cuda kernel) and therefore you get lower hashrate. In classic overclocking, where people push hardware to the limit and just want to pass 1 single 3dmark test, or complete 1 single run of SuperPi to screenshot it and post on site with OC records, it's okay to stress hardware, because it's like sprint - hardware suffer from exremly high load but for short period of time. In case of mining it doesn't work, I think that mining is more like marathon, so I set medium and stable OC settings as GPUs gonna work for months. As for balance beetwen high OC/medium load from software or medium OC/high load from software I choose second one because high OC settings will kill hardware faster. My apologies, that did come out wrong, your miner by itself is not unstable, I've used it before without profit switching and it worked great. What I meant by weak CPUs is that when used it in conjunction with NPM, specifically when using the "plus" option, then there's a problem. CcminerAlexis78 still has the problem of a long "warmup" time when running more than 3-4 cards, so I'm running 2 copies of NPM, and as much as I like the "plus" option, running 2 instances of that just punishes my CPU (even after the delay increase from 10 to 60s and changing priority to "below normal"), so when HSRminer kicks in while the CPU is already running at 100% causes it to sometimes crash. I have a friend running the same setup with an i3, he doesn't have this problem. So just to reiterate, nothing wrong with HSRminer, it is just a casualty of that particular issue, not the cause. It is indeed faster than KlausT. |
|
|
|
How do I specify to use different miners? Neoscrypt for example defaults to KlausT, but Excavator gives 30% better performance. Same with RavenEnemy vs Raven225 build here
It is possible to add new miners, it's just a bit tricky the first time around. If you go to the Miners folder you'll see all the currents miners listed, to add RavenEnemy which I think it's ccminer, I'd copy and rename an existing ccminer*.ps1 file, then edit the files to do the necessary changes to make it run your new miner. In the case of Excavator it's a lot trickier, I'd recommend copy the excavatorNvidianeo.ps1 from SniffDogMiner and edit it to make the changes you need. Quick question, where do you download RavenEnemy from? |
|
|
|
I did not make a new folder. Just make a copy of startpool.bat and change dstm settings as 0 1 2 3 4 to 5 6 7 8 etc.
The problem with keeping everything in a single folder is that the hashrates will get all out of wack. Say for example, copyA is mining C11, copyB is mining X17. CopyA has been running for 60 seconds now it's going to update the saved C11 hashrate to the current value, to do so is going to see what ccminer is reporting on port 4068, but since copyB is also running ccminer on port 4068, then copyA will save X17's hashrate as the benchmarked hashrate for C11 and throw the whole switching algo out of whack. You can avoid this by making the saved hashrates read-only after the initial benchmarking, but you don't get the live hashrate updates, which it's not a biggie, I just like the otherway better  |
|
|
|
how do you fix the problems with CCminer... most of the ccminer from polytimus and alexis have problem running 12 cards..
always giving non existent cuda device error , tpruvot doesn't have this problem
Have you tried running 2 instances of the miner? You make 1 copies of the mine and run 6 cards on it (0,1,2,3,4,5), then you make a 2nd copy, on this one go to the Miners folder and change the port (-b) on all the miners you'll be using (e.g. ccminer default port is 4068, change it to 4069), then run the remaining 6 cards (6,7,8,9,10,11). NPlusMiner does the miner port change for you, I just don't know whats others differences there are between Nemos and NPM. |
|
|
|
Man, hsrminer_neoscrypt_fork works even with GTX 970, and funny little gpu like GT 1030, what are you talking about? The problem could be that most scripts like MrPlus' one and Nemos download and use hsrminer_neoscrypt_fork_ hp.exe - it's high priority version of my fork, and it clearly states that "You will get more hashrate, but also high load on GPUs! If you have troubles with it - use normal process priority version (or specify -c 2 for this version)". And many new users don't have a clue about hardware and how to properly use it, so they just overclock their gpu to high values AND reduce PL%, and press button to start miner - then "all of a sudden" gpu become unstable under high load and crash. You can make changes to script so it will download normal process priority version to lower GPU's load. If you still have problems with hsrminer_neoscypt_fork, post questions to my topic, I will help you. I didn't know of the normal process priority version. It may be more stable. I based my comment on other users posting of crashes. Thanks for letting us know of the other version. The miner itself is stable - otherwise my topic would be full of crash reports from users. Only reasons why it can crash - if GPU is overclocked way too much and can't handle high load ( because neoscrypt algo is very gpu-intensive) or user specify random intensity value with -i option (because program is optimised for certain values and usually you don't need to tweak intensity as default values are already fine-tuned for 1060,1070,1080(Ti) Gpus). As for that user's comment - he is a newbie with 1 post and a rig of 4 x 1050 Ti and he claims that "Hsrminer is sick and buggy as hell"? It's not even funny - hundreds of users with all types of GPUs (starting from 9xx to Titan XP) are using it without any problems. Of course only MrPlus can deside what miner he will include into his package, but I don't think he should make a decision based on fake claims of some random dude. If you guys have any issues with hsrminer_neoscrypt_fork, contact me via PM, or post questions to my topic. It wasn't just him, I think that the normal process priority version will work better as users push oc for the other miners and then when switching to HSR_hp it crashes. HP is probably just fine if you optimize oc for it and not for multiple miners.. just my opinion of what is happening. Hey Just_a_miner Have absolutely nothing against hsrminer_neoscrypt_fork. It is a great miner and always worked well on our rigs. The reason I changed is that not every users of NPlusMiner are advanced enough to use per algo OC using prerun and therefore get problem when they start playing with OC. So I made a choice of stability for common users while advanced users know very well how to get hsrminer_neoscrypt_fork back in play with the adapted settings so it can play with other miners and OC with no problem. This is just a default config choice (stable) anyone can customize the miners and I see a lot of users do so. Just trying to avoid the kid crashing G'Ma's computer I gotta back MrPlus on this one, Excavator and HSRminer are the best for neoscrypt, giving 5-8% more than KlausT, but for people like myself with weak GPUs (Celeron 3930) and using +50/+600 OC and not having that much time to fine tune every setting, KlausT is way more stable (both Excavator and HSR would crash out of the blue). |
|
|
|
Comparison of version 2.5.2 to version 3.0version 2.5.2 is much better than 3.0, almost 40% greater than 2.5.2 something is wrong in version 3.0, compare the images Version 3.0https://prnt.sc/isle0nVersion 2.5.2https://prnt.sc/isle4t Sorry to say man, but your assertion is completely wrong. The issue is not the miner since your hashrates have remained pretty much the same, the problem is the pay rates from the pool (the BTC/GH/day column). For example X17 dropped from 0.02381 to 0.01680, that's huge, and those values depend on the pool you choose, not the miner. And as a side note, you shouldn't pay too much attention to the USD/day column since the price of BTC is such a roller-coaster, instead always look at the mBTC/day column instead. This value should remain constant for the most part but every 2-3 months you'll see a big reduction due to mining difficulty always increasing. |
|
|
|
|
Looking for some advise. I have a 6-gpu rig, since alexis78 takes forever to fully start hashing when using more than 4 cards, I'm now running 2 copies of nemo's side by side 3 gpu each (I changed the miner's API ports to prevent any crosstalk). Now everything works great most of the time except that BrainPlus has a very high CPU utilization (I have a Celeron 3930), so running 2 copies bring up the CPU utilization to 100% and sometimes it makes HSR miner crash. I've tried to launch each copy of nemo at different intervals but eventually both copies of BrainPlus end up catching up to each other and running at the same time.
Any suggestions on how to drop the CPU utilization of BrainPlus?
|
|
|
|
Is it normal for the Powershell istance to take 30% Cpu(currently mining X17 on ccminerpoltimos)?
I've seen those cpu usage spikes from powershell since switching to 2.5.1, regardless of which miner is running at the moment. No idea what's causing them. |
|
|
|
Apparently if you are a Comcast customer the EarningsTracker won't work correctly (Balance= balance info disabled(cant retrive info)) due to a timeout getting the pool API info from http://sfiles.ucoz.org/sfiles/poolapiref.json. I tried TWC and TorGuard and those worked fine. So if you are on Comcast, this might help you (no promises since it's my first time dicking around with powershell programming). I copied the info from the website into the EarningsTrackerJob.ps1 file, not very elegant but it worked for me. Here's a copy of the file if you're interested: https://mega.nz/#!94NiRKJY!0CMulET7bpbUpJ7JDa0LTuFl6Tw0fdTnajur7joIPw4, I'm on comcast and that fixed my problem, much appreciated !!!!!! It's been driving me nuts for two weeks. I tried many things but didn't explore that angle. Just out of curiosity how did you discover this fix? You are welcome. This kinda happened by chance, the tracker wasn't working on my rig so I just turned it off, but for work I have a PC under TWC, and for the hell of it I ran the tracker on that PC, it worked without an issue. I then checked with 2 friends who are on Comcast, no dice. Finally I turned on TorGuard and that one did work. Afterwards I just went and started looking inside the .ps1 files, I do no have much experience with powershell, but I'm sort of a mid-level programmer. So after much trial and error, came up with this fix. |
|
|
|
Apparently if you are a Comcast customer the EarningsTracker won't work correctly (Balance= balance info disabled(cant retrive info)) due to a timeout getting the pool API info from http://sfiles.ucoz.org/sfiles/poolapiref.json. I tried TWC and TorGuard and those worked fine. So if you are on Comcast, this might help you (no promises since it's my first time dicking around with powershell programming). I copied the info from the website into the EarningsTrackerJob.ps1 file, not very elegant but it worked for me. Here's a copy of the file if you're interested: https://mega.nz/#!94NiRKJY!0CMulET7bpbUpJ7JDa0LTuFl6Tw0fdTnajur7joIPw4 |
|
|
|
|
I have a little science experiment, I wanted to monitor my rig from work using AM, but I've ran into an issue.
It's an 8-GPU rig, have some cards runing Claymore and the rest using Ccminer (KlausT).
Locally it works like a charm, I create 2 external miners, 1 pointing at 127.0.0.1:3333 for claymore, the other pointing at 127.0.0.1:4068, works great.
Next I go into my router's port forwarding menu, set both 3333 and 4068 to the rig's LAN IP. And finally, installed AM in the remote computer this time pointing the external miners to <rig's WAN IP>:3333 and :4068. The claymore monitor works great but the ccminer one is dead in the water, just stays "Disconnected". Been digging around not sure what the problem could be.
Is it that ccminer just doesn't like any connection coming from the outside world? Or is there an AM setting that I'm overlooking?
Thanks.
|
|
|
|
one of my rigs periodically will stop working. Seems to be losing one of the 7 GPUs for some unknown reason. I can manually restart Awesome and it will mine with the remaining 6 GPUs. Any tool on Awesome to help figure out what the cause is or what card is acting up?
I enabled the notification setting if A.M. detects a problem card (i think) so maybe that at least will let me know when it happens. I think I read somewhere that to have A.M. be able to reboot the PC that auto logon has to be enabled which I am not sure I want to do.
When this happened to me it was due to a bad riser, I got a new one and problem solved. I was able to identify the bad one with MSI Afterburner, the bad card wouldn't report the clock speeds or temperature unless I restarted windows. Hope this helps. |
|
|
|
|
