Topic: ▂▃▅▆▇⫷[ 🆉🅿🅾🅾🅻.🅲🅰 ]⫸⫷[!KAWPOW!]⫸⫷[ the miners multipool ]⫸ ▇▆▅▃▂ - page 48. (Read 279744 times)

it's not abandoned, last update is ten days ago, hardest part is to configure it as it lacks active support.

Using a 60 minute average of profitability would be better than relying on either the instantaneous value when polled or the strange attempt to average the 24 hour and instantaneous data that NemosMiner and others are pursuing. However, MinerControl appears to have been abandoned several years ago while MrPlus has been working on a fork of NemosMiner* right now and so seems to be receptive to implementing good ideas provided by the community so I am giving it a shot now.


* - https://bitcointalksearch.org/topic/nplusminer-multirig-remote-managementaiautoupdatepoolalgo-switching-2965976

try MinerControl* to use all mentioned pools, it has config to use current pool api data or use an average window(60 minutes by default), use master-slave config if run multiple rigs, avoid looking @ zpool webpage stats cause it would block pulling api, use https://miningpoolhubstats.com/ instead.

* - https://drive.google.com/drive/folders/1lT8E8j3BKzM7r1Mo2EFHk1NmP8gkdZ1Q and https://bitcointalk.org/index.php?topic=769239.1180

There were some comments a few pages back about the pool limiting requests from the same IP (and some suggestions on how to manage that) that may be related if you have multiple miners...

@crackfoo After further testing, I came to the conclusion that it's something on your end or new hosting server doing something weird. I have tried 3 different yiimp based pools with all the same settings for multiple days, and all of my miners connect successfully to them constantly with no miner dropping out randomly. It's only when I connect to your pool that some miners drop out randomly and going to a backup pool.

I am still using your pool, but this random dropping out of your pool is a nuisance. I have narrowed it down to your pool, since it's not the miner's fault or else it would of experience the same issue on the 3 other yiimp based pools, but it doesn't.

Since you also have a Baikal miner, hopefully you will be able to figure something out because you can also test it with another yiimp pool to see yourself that it won't randomly disconnect.

P.S. I remember in the past, before your recent server changes/upgrade/overhaul, it never had this issue. Hope that info helps somehow.

XMR?  We don't mine monero on this pool as far as I know.  You would have to find a Monero specific pool since it is its own kind of animal.    If I am wrong, someone else will chime in.


But FYI:
On this pool, you select an algorithm to mine on, and workunits from many coins are sent to your miner to work on.

You can only pick what coin you are paid out with.

hello all,
i need xmr pool addeess and port

Yeah, the real world poolside calcs can leave be much to be desired for accuracy.... this is why when I do normalizations (the benchmark), I use the poolside averages in my norms.

Tribus;  not sure;  post up the miner app you are using, as well as the card(s) you are using.  This info may help crackfoo see what is causing it.  Typically you can see up to %20 less hash, but on average somewhere around -5-8% of what the miner app is reporting.  50% is a huge difference, but if everyone is seeing the same -50%;  then its cancelling itself out and nobody has an advantage (I noticed he restarts some services/ports when this happens on some coins/algos).

See;  profitability will never match the miner's guess if it never sees the same number as the site calcs.  That is the biggest fault of the client-side profitability calculations.

If the site used the reported hashrate from the miner;  someone could just modify the miner app to feed the pool erroneous/false data and you'd get paid for doing nothing in a way....  so the closest solution is what we use, and its far from perfect, but quite logical and reliable.    I've also noticed when luck is down for me;  I typically see the same results in everyone else's shares as well (the pool graphs pane).  Since all users in the pool are going to be working from the same base blocksignature hash salt to find the next block;  they tend to work from the same grouping of potential winning salt/nonce combination, and in turn, the same sort of results.

With multiple machines on different accounts, I have noticed the same low days and same high profit days on each account within a small % of error.... this is why I feel that luck is all encompassing based on base root hash we are all working on successive chunks on.

recalcs/switches can be a nuisance if the API is not responding.  Longer delays are better;  because most pumping rises in coins tend to happen over the course of a few hours to half a day... so having the recalcs done with more of a delay, probably won't hurt you.

On my ccminer x17 script i get 39 MH/s hashrate and on Zpool web page is 26 MH/s
Same with Tribus on ccminer is 250 MH/s but on zpool get a half of my speed .

Same for money, of course, Awesome Miner estimate between 14-25$ but get only 8$

Any ideea ?

Thank's!

PS. They have some kind of penalty if I change the script too often ?

when to wait for the appearance of coins B2X, ARION, SUPPO, MAMBO, OMEGA ... and others, for algorithm X11?

BERN is wasting hash, TTF 53s, last block 18h ago

on my autoswitching batch files I tended to turn off X17 after a while.  it hogged a lot of time, and i made more staying on lyra2 solid for example.


So that highlight I think is just the most popular coin;  I havent figured that out yet, but it could be....  the main problem is normalization;  "whats most profitable for one..." type scenario.  I believe crackfoo set all the default normalization factors to "1.0" thus, making them all equal per-say.

If you decide to test my batch and have hiccups, PM me or email me via my username at gmail.  I know a few of the new algos aren't on there, but with my batch file comments I left in the automatic batch, you can easily add new apps, or replace a currently used ccminer version with your own... or I can try and whip something up, but i'd rather put the effort into incorporating the auto batch into my manual batch so it an "all in one" sort of deal.

Are there any noticeable saving with tx fees when being paid in LTC vs BTC?

Because image embedding often doesn't work here, I made it a link.

https://imgur.com/a/zeuOW


Yeah, I didn't think so, but there was a reason I asked - the forked version of NemosMiner I was trying out was stuck on X17 for 3 hours before I closed it and started up an older version of the same to see what it selected as most profitable; for about 20 minutes it was X17, but now it has switched to Tribus. 


I normally love tinkering with this sort of thing, but I am approaching burnout today as a result of hunting down numerous issues that decided to happen all at once.

colorblind....

can you post an imgur link to a small screenshot (highlight the area) of what you are talking about?

I dont think so though;  stratum handles what's most profitable when doing profit switching via the pool and not another app or profit calculating script....  I have never seen it display it on the wallet or pool page.

Would be kinda nice;  but then again, profitability itself is based on your normalization factor;  so a web based display would be based on the 1.0 default normalization across the board and would not yield a correct answer per-user.

As far as your benchmarks;  Get my automatic batch out and give it a try for your profitability checks;  you are relying on nemosminer to do the profit calcs...  the pool code could be doing it differently itself when stratum decides what you mine instead.  There's the automatic batch, and the lite batch.  Both have merits and drawbacks.  Links in my sig.

I am still working on the new "mminer" batch;  some of the old ccminer versions I am using in it don't play well with the newest versions of W10 and newest video drivers.... but that's not a profit switching batch anyways.  I still have LOTS of work to do, but I posted it so the framework for auto-self-updating in a batch file is out there for people to utilize.


But those batches may give a little insight if running all of these extra API calls and benchmarks on your cards is worth the effort in the end....  I think its going to be within the margin of error on letting the pool control it;  which would free up a metric shit-ton of traffic to the frontend assuming people swap over to the stratum controlled way.


I do remember loving the stratum controlled method though;  which was the whole reason I wrote the auto-batch;  cause waiting for each miner app to load, timeout than close until it gets to the right algo was slow and cumbersome.  My batch launches a ccminer instance for all algos at once, and stratum only feeds data to the algo it wants, the rest of the ccminer instances timeout and go away.  Can be a little buggy;  especially with large wuantities of algos enabled;  but when trimmed down to a real-world list of the best of the best;  its actually quite nice.


Over the last ~year, I have solely mined one algo at a time.  Profits are very consistent;  less "bad days" than profit switching were seen.  Plus, when skien was a goldmine, I was making over $400/mo with 2x 1070's.

Does the magenta highlighting of an algo indicate it is the one that is most profitable at that time?

Just checked it out.

Seems ok for the hashrate you are putting out;  steady gains.

I see one payout 2 weeks ago;  by looking at your graph  I am guessing you are using the equivalent of lets say a gtx960 in hashrate? (just a guess)

You are close to your payout threshold;  Id expect to see it by monday; it looks like it will qualify for the sunday smaller payment round if not earlier.
You did get paid on your first ~2.5mBTC...   so all good there.  Its in your payout history (clickable up top where your earned totals are)

Forgoing any complications poolside, if you don't see it by monday evening (PST) i'd check back here to see if there were any extraneous issues delaying your payment.


Well;  your issue I dont need the address for;  but crackfoo will to be able to swap the coinID in the database for you no sweat.  Should be good to go;  don't fret.  Unless you have a rather large hashrate, and would get a payout right away (highly unlikely); you should be fine to keep mining on that address.  If you feel you will hit a payout threshold before the change happens (which would not be refundable if it gets transmitted to the wrong chain) then I would suggest hold off on mining here until its fixed , or reduce hashrate on the address until its fixed.   But hes normally good on getting it done in a timely manner.  I believe we usually see him on saturdays on the forum as well.... you shouldn't have much to worry about.

Hey sorry for delay, i just logged on.  
LTC addie -  LNXdTrq3YfVGtyffCYugwawsfwj4ZCkvVV

I know its a good addy i use it on other pool and have LTC in the wallet now from previous mining

Thanks for looking into it

And no i didn't submit a support ticket, i didn't know where to do that which you just provided, so thanks again

Sure any help will be appreciated 32DHGzjT1KRnuH9C8c62aFGrE5G8Di3i8W

It took about 2 hours to benchmark all the algos selected by default for Zpool (except for LBRY, as that algo has been ASIC'ed so no point mining it with a GPU) and it has been running in auto-switching mode for about an hour. So far it has remained on X17 the entire time, which is definitely unusual. Neither Nemos nor MrPlus do a very good job of explaining what their mining automation scripts do so I am inferring much from observation, but it appears that the MrPlus version needs to run for many hours to build up a decent average for the profitability stats, hence why I thought it was unusual it was sticking with X17 for so long.

That said, NONE of the multi-algo pools I've tested over the last few weeks - using NemosMiner, in all cases - beat out NiceHash when run concurrently on similar hardware. Two pools got on the wrong side of a hard fork which wiped out ~35% of my earnings so those were clearly outliers, but MiningPoolHub and Zpool both came in around 10% less than NH and so I have begun to suspect NemosMiner is the culprit, especially since I verified that both pools pay fairly/honestly when run in single-algo mode (Neoscrypt on MPH and Lyra2v2 on Zpool).

I'm *hoping* that MrPlus' fork of NemosMiner will help, but if not I will use NiceHash for auto-convert to BTC and Zpool or MiningPoolHub for "single-algo, convert to whatever I want."