Topic: █▓▒░-< [ZPOOL.CA][BTC Multipool] The miners multipool >-░▒▓█ Paid 925+ BTC - page 68. (Read 217685 times)

is that the same algo vertcoin once had?

Added scryptn to the pool with MRY and some FUJI once it's sync'd

Still doesn't make sense to me. Mining a high difficulty coin for a short period of time will often produce no gain, but when it does you get a spike in your balance. There is just more variance ("luck") involved.
The issue must be something else, maybe technical (orphans? diff mismatch?) or an error in the profitability calculation for skein.

It's a problem on all algo's where you have high difficulty high value blocks mixed with low difficulty low value coins. If you switch to Lyra2v2, you really hope for a VTC or MONA block to be found, otherwise your contribution gets wasted on low value merged mined coins.
One of the problems with myr-gr is that saffron is only functioning on 2.5 out of 5 algos. A lot of hash rate gets wasted on rejects until one of the other algos pushes it along.
Another problem is that some junk algo's such as c11 gets bursts of high pooled hash rate far above its average hash rate.
Another issue is that the block notify mechanism cannot solve blocks as fast as block winning hashes coming in on some coins.
I would suggest a longer algo wide PPLNS time period is considered, but there are many more issues as to why an algo falls short of its estimate.

For instance;  Skein seems to poop out lots of low value blocks... which is totally fine... but it deosn't get as many high value coins out except in groups.  So when the profitability spikes, it switches only to not see the gains as if you were on the algo the entire time.   Kinda like when the miner switched to decred for a few min here and there.   The reward down the line after you are switched off it and a block is finally found; is pretty minimal.

*edit*

Also, I have found the best switching algo combo to be X11evo, X14, X13, X17, X15 and neoscrypt...

"maybe its the algo switching and the larger value coins don't come in regularly enough to keep it profitable"

not sure that makes sense from a statistical point of view.

A side note to see if anyone feels the same...

skein just doesn't seem to earn enough... maybe its the algo switching and the larger value coins don't come in regularly enough to keep it profitable.  I have seen my average slowly decrease since adding all the algos so I think I may be pulling it from the batch;  but I will leave the code at the bottom for people to paste in if they want to use it.

Interested on any others opinions....

It can happen sometime. It's not a problem. The pool on average finds 75-100 blocks a minute so if there are big spurts on slower wallets, it can make the updating delayed.

I see no problems.   Please be more specific on what blocks, what algorithm, if it's mining or exchanging, etc.


I am seeing regular block generation on my rigs right now.

Hi ,

It seems for about half an hour all the blocks are not processed , or is a front end problem , could you please check?

Thanks

So, I added V1.03 to the original post where I update the batch.

I need to figure out what happened as the process detection isn't working with the 3rd algo.  At first thought it's probably a long filename issue, so I will need to do some testing.

I suggest people whom have used 1.04 to go back to 1.03 where it was reliable.   I will report back when I have figured it out.

God help me when it comes to simple things related to microsoft that don't work when you do them correctly.

Snap.  I tested with default intesity and didn't transfer that setting to the final batch.  Try removing the -I and (I believe) the setting of 17.5 from the "start %C% /min %C1%....." Line...  Also the comma and diff setting after the %PASS% section on the same line.  Should "uncork" it.

I'll remove all these personalizations when I get back home in a few hours and post it as 1.4.1

*edit*   Looks like the intensity and difficulty are not set and default... did you by chance happen to download it right as I posted it?  I found a small bug right after posting it and changed the code a few min after...  Probably should have noted it...   But I dont see why you would be seeing reduced performance otherwise...

I had a very strange issue with trying a new utility to force my card into P0 state... which helped... but, my card is still getting kicked into P2 by ccminer....  At least the settings for P2 are now locked at full speeds and I gained ~3Mh on lyra2.  Havent checked how the others were effected.

Hi JK - do you have a "aggressive" diff string for my 980Ti. I currently use your stock diff levels, and I can see my 980Ti runs slow out of the gate. The 980Ti is a beast on algos like lyra2v2 and I was wondering if you could have a switch to enable "beast" mode. Thanks!

Done and Done.  Thanks for the pointer!   Happy to report hashrate (at my current "to have a usable PC" backed off intensity) Increased from 9.6Mh to 23.7Mh.  Current app filename was: ccminer_nanashi_lyra2rev2.exe  Downloaded Nicehash miner V. 1.6.0.1

I have updated the miner batch to reflect this with V1.04.  If you wish to update, first visit this link:
https://github.com/nicehash/NiceHashMiner/releases
And download the latest version of the nicehash miner.  As mentioned above, unpack the folder that the ZIP includes, and you will find the lyra2v2 optimized version in the ./bin folder.  Copy it only to your regular miner app directory where the batch is and you are set to go.

This is a major change, only because if people want to stay with the non optimized versions, they will need to re-assign the C variable to reflect your normal miner app, and you will also need to change the normalization in the password string to be the old value of 9.6.   Seeing the performance boost (more than 100% more hashrate) I don't see why you would not want to update.... Plus hopefully I can just release a main ZIP file of all miner apps wrapped up, and release any updates as just copy and replace type of deals in the near future.

I have noticed on small screen resolutions that in my signature the miner batch link isn't always able to be shown.  In that case: Click here to get to my batch file.

No update that I saw

thanks

Is there any update? I haven't bothered to look since I just pulled it and compiled it recently. I've tried resyncd and it's still the same. Don't have time to muck with it right now.

Are you going to update the tigercoin wallet?

In the bin folder of the latest NH windows miner (v1.6), there is a "ccMiner 1.7.6-r6 Nanashi Meiyo-Meijin" that is suppose to be optimised for 970, 980 and 980Ti. I am running it now on zpool lyra2v2 port and getting alot of Vert hits.... nice!

Diff 24, 36.42MHs, 980Ti stock clocks

@ JaredKaragen I noticed your comment on git.  nvapi: base memclock was wrong on maxwell  Ccminer.
Does it have effect on my ccminers?
Thx

So I was having issues with getting devices older than my GTX980 to work with the recent miner apps.

Sadly, None of the newer ones seem to support the older devices.... except the X11evo release mentioned a few pages back.

So if you would like to use the batch with older cards, let me know and I will strip down a copy as to fit within the password length limit to only include the most profitable algos.

Currently I am able to get ~1.4Mh out of the watercooled EVGA GTX 560 I got handed to me recently on the X11evo algo.

However;  I didn't modify the batch, so when it finally switches to an algo that is further down the list than the password allows, multiple algos will stay connected at the same time.

I will experiment with re-ordering the variables as to let this happen as little as possible on its own without any major modifications to the batch....

Anyone else in this same situation?



Also, is there anyone here with a windows X64 machine that has the programs and libraries to compile a miner for me?  I would be tickled pink if someone could take that X11eco fork of the ccminer-DEV version to accept the longer passwords and make the batch truly universal....


If someone can point me to the GTX980 optimized Lyra2 version as well.  I used to have an optimized version (GTX980 I was seeing 12-14Mh back when zpool first opened last year, but hearing the 8Mh->20+Mh jump for the nvidia cards has me intrigued)....   Basically I am starting to get motivated to add all the optimized versions to this batch as to make it as versatile and as efficient as it could ever be.

Once I have a master stable conglomerate of miners and the batch all in one place, I will find somewhere useful to host it so people can just download it as an entire package instead of having to find the miners like I have been.

If people want to help me assemble a list of version numbers, fork name, for different algos that are optimized in CCMINER ONLY (I am trying to stay on a one-track road with config strings)  Please comment them here and Ill build up the list and take the necessary steps to get them all together for the public to know and have access to easily.

I know it will be tough staying up to date with bugfix version releases, but honestly, I think its time to just step up to the plate and do it myself to save face for the rest of you.


I got rid of all of those ATI cards (at the request of my friend since he's going purely nvidia now) so if someone else could do this for the ATI side (if needed) I will work with them to get a similar batch and miner package together for that as well.   Maybe even if its useful and in enough demand it will be linked on the site for the newcomers as well... but I think that is reaching beyond my grasp for now