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

First 2 are in BTC and actual_last24h is in mBTC

Does this mean also that at least 48 hours pases before Netko can be sent to exchange in to BTC? If so does it still make sense to mine it given the fact that in long period of 48 hours it's vale may crash and thus be more safer for us to stay and mine only Verge, Taj and other coins which have quick turaround?

I'm just asking to understan how this works, not criticizing;)

I'm currently having a look at the API and there's something I don't understand.


It seems that "actual_last24h" is the same value as displayed on the website, however the "estimate_current" and "estimate_last24" seem to be by a factor of 1000? Is it a different unit?

Which value is used to compute the autoswitching?

Thanks!

What exchange is used for Netko?

Still seeing some odd things around payout time.

Ok thanks, just so use to seeing them exchanged like within 30 minutes.. thought maybe my account was jacked up or something and the blake2s was just adding to the issues, because in 3 payouts a payout has not been triggered on my account and im at 1/4 btc unpaid.. last time this happened it took 2 days before it finally payed me

Netko takes about 48 hours to confirm blocks. Shares can't get backed up on just one algo. If something backs up it shows on all algos

i am not sure what is up with the immature shares on blake2s, i have immature shares in the couple hundreds now that has been building up since yesterday.. is it backed up?>

Added x11 as well.

       x11 under 20Gh=2.25%, 20Gh-50Gh=2%, 50Gh-100Gh=1.75 & 100Gh+=1.5%

So is this intended to keep people from algo hopping too much?  I'd guess the hash rate may fluctuate a lot depending on the profitability.  I'm sure there are some that stick to one or two hashes, but for someone using multialgo this might cause a lot of variance in fees.  Granted the fees are fairly low overall, but likely would have to be figured into the profitability somehow.


Can you confirm what number we should use for equihash since it comes usually in KH/s?

Not yet, I haven't had time to look into it.  Been working on a new fee system (FlexFee™) and currently testing it on scrypt/lyra2v2 & sha256.

I'll soon be implementing this type of fee system across most algo's. The more hash the pool has, the lower the fee will be!

Current thresholds are:

        scrypt under 5Gh=2.25%, 5Gh-10Gh=2% & 10Gh+=1.75%

        sha256 under 500Gh=2.25%, 500Gh-1Ph=2%, 1Ph-5Ph=1.75 & 5Ph+=1.5%

        lyra2v2 under 5Gh=2.25%, 5Gh-10Gh=2%, 10Gh-25Gh=1.75 & 25Gh+=1.5%

Cheers

Well my first thought was just that it was too long.  So I started erasing a bunch of things and it wasn't until I started erasing the ones before blake2s that it started working.   I had a post half written thinking it was just too long until I decided to go back and make sure it wasn't just too far from the beginning or something like that.  I was adding things to the beginning until it failed again and noticed that when I added a long string without decred in it that it still worked.  That's when I realized my initial thought was wrong and that it was decred that was causing the issues.

I'm an IT support person so doing trial and error is pretty much in my nature.  Still working on stabilizing using Multipoolminer since that gives nice output and such, but I'm wondering if the pools multialgo method is still going to be more efficient since it cuts you off when it knows something else is more profitable.  Also not sure I like how Multipoolminer just kills the process when it switches to something else.  Not sure what that might do in the long run.


Also those numbers were basic averages for a single 1080 card.  I have a box with 5x1080, one with 1x1080, and one with 1x1080 and 1x1080Ti so the numbers all pretty much are the same ratios between the cards.  Haven't really had it stable enough to get a good feel for how much I'll earn in a day from zpool.  hmq1725 was causing bluescreens on my main miner until I realized I needed to set the intensity down to 17 from the default of 19 it was selecting.   Much more stable now.

yeah for some reason having decred in there will null your diff setting. It's been attempted to be fixed a couple times now but seems it still screws it up.

Sounds like it took a lot of trial and error.  You, sir, are more patient and persistent than I.

So it appears if you include decred in your multialgo it doesn't pick up the difficulty.

Tried this (decred at the end):

or this (decred at the beginning):


And it didn't pick up the difficulty from the d=32

Tried this:

And it does pick up the 32 difficulty.

Nope the dash was a typo in the post when I tried to reconstruct the whole string from the batch file. I've tried with the d=xxx at the beginning or the end and it doesn't seem to take effect unless I take out the multialgo factors.

Not sure about equihash, but all the other difficulties seem to be measured in MH/s with the exception of blake2s, decred, blakecoin which since seem to be measured in GH the pool does the proper comparison at least it seems too.

So what I did was actually use Multipoolminer on zpool and just let it benchmark all the algos that I wanted to use and then filled in the numbers that I got.  You could do the same with anything else and just run each algo for a bit and change the number to be what you averaged.  As I said not sure if you would do 1.2 for equihash or 1200, but for blake2s it seems you put the number in GH/s.

So if my rig is getting a total of 1.2ksol/s for Equihash, my factor would be -p equihash=1200?

BTW, I noticed you have a -p -c=BTC,etc,etc,etc.  I think the dash before the c=BTC is your problem.

All of the numbers after each mining algorithm are your hashrates so that the pool can decide which coin is most profitable.
They are not setting the difficulty at all and you need to use d=X as you have in your last command.

If you're not getting tons of rejects at super low difficulty you can just leave it and let the pool adjust for you.
Or try adding d=2 or something right at the beggining, but that may actually be a little high for some coins.
It's obviously better, but more work to split them all up and have custom difficulty for each one.

Have you tried putting the d=64 at the beginning of the password?

ccminer -r 0 -a blake2s -o stratum+tcp://blake2s.mine.zpool.ca:5766 -u %ADDY% -p -d=64,c=BTC,myr-gr=95,lyra2v2=50,decred=3.55,blakecoin=6.75,c11=22.5,groestl=50,blake2s=5.45,x17=12,nist5=60,skein=720,sib=16.5,lbry=380,timetravel=36,veltor=29,bitcore=18.9,hmq1725=5.6,stats

Also, do you need c=BTC?  I don't have that, and zpool already pays me in BTC.

What GPU do you have?  Just wondering how that profitability factor works.  I kept mine blank (default factor of 1).

I'd like to learn how to d calculate the factor based on my rig.

Seems like the d=xxx diff setting doesn't work when combined with the multialgos method of mining.

Tried the following and it never seems to pick up the fixed diff:

ccminer -r 0 -a blake2s -o stratum+tcp://blake2s.mine.zpool.ca:5766 -u %ADDY% -p -c=BTC,myr-gr=95,lyra2v2=50,decred=3.55,blakecoin=6.75,c11=22.5,groestl=50,blake2s=5.45,x17=12,nist5=60,skein=720,sib=16.5,lbry=380,timetravel=36,veltor=29,bitcore=18.9,hmq1725=5.6,stats,d=64

Yet when it kicked off it used the stratum difficulty which starts out much too low.

Do I need to set a diff for each coin or something?  At this point I've just  been adding a -m 8 for blake2s so it ramps up the difficult quicker.  If I use the following it picks up the difficulty just fine:

ccminer -r 0 -a blake2s -o stratum+tcp://blake2s.mine.zpool.ca:5766 -u %ADDY% -p -c=BTC,stats,d=64

This is just the one line I have from Nemo's miner batch script.