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

groestl and myr-gr removed? Is this permanent or temporary?

BTC will never get hash put on to it. I keep it there so it can be seen that it is online and working. The only time a coin would get hash put on to it, is if the block solve estimation is less than 3-4 sometimes 5 hours max.

What I have done (can't be sure it is correct but it seems logical to me) is to obtain an overall hash rate for each algo, and then divide that by the scrypt hash rate.
For example, my GTX680 (+175MHz GPU OC, +500MHz Mem OC) gives me around 375 kH/s. X11 mining gives me around 3270 kH/s, so I divide the x11 hash rate by the scrypt hash rate and get 3270/375 = 8.7

Overall kilo hash rates are:
scrypt 375
X11 3270
X13 2500
Qubit 5630
Quark 4600
Lyra2v2 1430
Groestl 8980
Myr-Gr 15840
(Neoscypt unsupported on my card)

So this is my normalisation string
x11=8.7,x13=6.7,qubit=15.0,quark=12.3,lyra2v2=3.8,groestl=23.9,myr-gr=42.2,scrypt=1

I'll give it a try and see how it goes (although I've only just started mining on this site so comparison might be difficult)

Thank you for the info on nicehash and zpool !!

Yes, thats right.

For miners, it's better, if he rent hash with smaller hashs at the same time as large hash, because yimmp spread the miners between the coins. If there is a 5x5T hash, pool sw can mine 5 coins with 5T(/coin). with this, the coins difficulty is not jump high, because just a "small" hashrate are in one coin.

For this, the pool owner sould add coins as much he can, because the yiimp sw can choose the good profitable coins for miners.

Elbandi
ps: you can disable the bitcoin, 30T hashpower is very few to find a block, it's waste of hash if pool switch to btc.

We definitely find that dumping huge amounts of hash, isn't profitable like it is if you rent low/modest amounts of hash. The reason is because with a large amount of hash, it causes the coins to jump way up in difficulty, lowering your overall luck. Now it's not as much of a problem when there are lots of coins to choose from, but still better to go low and slowly increase.

My string for SP-MOD:
ccminer77 -o stratum+tcp://mine.zpool.ca:5433 -u 18EJ9w1MuZXWDNNEuLAyq4SJJUsYx9fqiX -p d=0.001 -a myr-gr --diff 0.003
for GTX750Ti

Tested NH's services again yesterday.  My settings were as follows:  Two rentals, one at 5Th, and another at 100Th.  Both SHA256 mining, to port 3333 with this password: d=2048,sha256

the 100Th completed without incident, and the 5Th is still going.



Again;  nicehash disappoints with a 100Th rental;  If I keep a steady 5-10Th, I actually make more btc every time that i've done this test.  Strange.  4th time this has happened... no longer a coincidence in my mind....  Probably has to do with luck over a short period vs luck over a long period.   

I haven't wanted to waste that much coin just doing tests knowing I would take that kind of a loss after this many fails or else I would do the same time frames for 5Th and 100Th......  Gonna just cut my losses and stay with slow and steady.... along with just using my own hardware.  Im a blessed one that doesn't pay any power bill

d=2048 - It runs for 2 minutes , then switched off,  Disconnected. Pool difficulty too low for high speed.

sha - ?

I usually do 2x the min...

so you do try to put the smallest complexity and see ....

thats's right, default diff may not be acceptable with nicehash so you need to set one:

http://www.zpool.ca/site/diff

Thanks

do a "test pool connection" before saving it.   I bet difficulty is not set properly for you... using the password field.....

nicehash not connect to scrypt and sha256

Update: seems like reward share on myr-gr is back to normal and is equal to share in pool's hashrate. Thanks!

@JaredKaragen - your message "I'll leave myr-gr. pool for now" was posted before my AMD rigs started hashing there. I know that ccminer performs wierd at myr-gr pools. For few hours I had 99,5% of myr-gr. hashrate at the pool and there was no ccminer in the list at that time.

Pool's statistics is done good, so monitoring of connected miners, their software and hashrate is almost real-time.

Pool hashrate is 180 Mh  -- 3 miners (1 cpuminer + 2 sgminers) -- my hashrate is 140+40 Mh -- my reward share is 75%.
Pool hashrate is 40 Mh  -- 2 miners (1 cpuminer + 1 sgminer) -- my hashrate is 40 Mh -- my reward share is 75%.
Pool hashrate is >180 Mh  -- >3 miners -- my hashrate is 140+40 Mh -- my reward share is <75%.

We're using nicehash for quibit, x11 and lyra. The odd time we'll use mrr if we happen to notice a cheap rig but the rigs can be annoying and unreliable. I had someone make a custom bot, similar to their own bot, but is node based and has more logic into it besides the basic price lowering of an order. It monitors multiple orders and adjusts to the max hash rate on the cheapest one, and drops all the others to the min.

curious who you are renting from and what algo   I like your idea... as long as the cost to rent is kept reasonable. (Curious what you are using as a trusted source, personally I haven't had great results with Nicehash and large hashrate rentals combined (found blocks lower percentage compared to the more hash i rented))

Id actually try this myself.... 

All this being said, it is a fork from the original yaamp/yiimp so we're just using what was existing and haven't looked into the math. I do know though, that the miners I have pointed on zpool.ca now, make more than they did on our xpool.ca and that is from renting rigs. We started a rental pot with 0.05 BTC a week ago and its grown to 0.12 and we've been slowly renting more and more.

The other machine was me.....

It was a ~45Mh video card.

The math makes sense; as in my hashrate isn't "negligible" given the hashrate on that algo yesterday.  I am also inclined to point out that I mined for HOURS on that algo with the server accepting about every 250th hash, and it would only report 11Mh on my wallet page, if at all.  When I got home I got the miner software switched out and left it on for some time;  then switched to the other newer algo (dmd-gr, which is now not on the list anymore);   and then finally switched algos again.

I found the pool doesn't report hashrate changes instantly.  The numbers on the listing seem to be normalized... thus it takes time for hashrate to ramp up to display actual readings (in the details section, not the Summary section which doesn't seem normalized)

Every time I start mining, I noticed that on the pool tab it slowly ramped up as well.... same with the pool statistics square at the top right...  plus the pool converts share value submittal / frequency to calculate your hashrate baesd on your work submitted, not the number reported by your miner application.

Now;  things I say about the pool are my observation;  crackfoo can be the actual one to confirm or deny my thoughts.   But I figured I would add this info for you to consider since I can see why it would be perceived as a loss to you, and I was the other miner working alongside you.   Hope it helps!