Topic: [POOL][Scrypt][Scrypt-N][X11] Profit switching pool - wafflepool.com - page 66. (Read 465769 times)
June 05, 2014, 01:45:06 PM
Yea, looking forward to trying out X11 tonight after I compile a new miner on my BAMT rig.
June 05, 2014, 01:35:39 PM
New Stats API is available. http://wafflepool.com/api/stats
Includes some requested things people were scraping from the stats page, and adds all the algorithms in one place. Everything is cached for 60s (basically how often our presentable stats update), so if possible, please don't pull more often than that
New Features (per algorithm):
- currently mined coin
- pool hashrate
- last hour of mining (% of the hour by coin)
- balances (sent, exchanged [pending send], confirmed [unexchanged], unconfirmed)
- last 7 days of aggregate stats
- btc earned
- hashrate
- btc per mhs/day
- vsltc (percent, scaled by our profit factors [0.47 for scrypt-N, 4.0 for x11]).
Includes some requested things people were scraping from the stats page, and adds all the algorithms in one place. Everything is cached for 60s (basically how often our presentable stats update), so if possible, please don't pull more often than that
New Features (per algorithm):
- currently mined coin
- pool hashrate
- last hour of mining (% of the hour by coin)
- balances (sent, exchanged [pending send], confirmed [unexchanged], unconfirmed)
- last 7 days of aggregate stats
- btc earned
- hashrate
- btc per mhs/day
- vsltc (percent, scaled by our profit factors [0.47 for scrypt-N, 4.0 for x11]).
June 05, 2014, 01:09:44 PM
Awesome news pw I will switch my two rigs over as soon as I get home great job.
June 05, 2014, 01:01:42 PM
X11 is ready to go
Same process as the small beta for Scrypt-N. If you've mined X11 before, or are OK setting it up without any outside assistance (I don't have the "Getting Started" written yet), you're free to start using it. The obvious "This is in BETA, stuff might break" applies. Darkcoin is disabled for now until we get some more hash power (soon as we can get a block on average every hour or so, I'll enable it).
http://wafflepool.com/newalgos
Enjoy!
Same process as the small beta for Scrypt-N. If you've mined X11 before, or are OK setting it up without any outside assistance (I don't have the "Getting Started" written yet), you're free to start using it. The obvious "This is in BETA, stuff might break" applies. Darkcoin is disabled for now until we get some more hash power (soon as we can get a block on average every hour or so, I'll enable it).
http://wafflepool.com/newalgos
Enjoy!
Switched! It couldn't have been easier. I simply changed the port number on my test rig, and it started right up, and is reporting all is well on the stats page! Very excited for the summer season mining with waffle!
June 05, 2014, 01:00:56 PM
Just to make sure - you are using 4x ratio for the vs LTC calculation, right?
Correct. Current profit multipliers are 0.47 for Scrypt-N, and 4.0 for X11. The raw numbers in the stats table are not multiplied (BTC, Hashrate, BTC/1MH/day), only the "vsLTC" numbers are scaled by the profit multipliers.
Any chance you can give us a stats_api?algo=all option to retrieve rate tables for all algorithms in only one call?
Yep, working on it now. I think we'll actually be moving to a completely different API however, just to avoid breaking the old one's structure.
June 05, 2014, 12:52:22 PM
Just to make sure - you are using 4x ratio for the vs LTC calculation, right?
Correct. Current profit multipliers are 0.47 for Scrypt-N, and 4.0 for X11. The raw numbers in the stats table are not multiplied (BTC, Hashrate, BTC/1MH/day), only the "vsLTC" numbers are scaled by the profit multipliers.
Any chance you can give us a stats_api?algo=all option to retrieve rate tables for all algorithms in only one call?
June 05, 2014, 12:29:30 PM
Just to make sure - you are using 4x ratio for the vs LTC calculation, right?
Correct. Current profit multipliers are 0.47 for Scrypt-N, and 4.0 for X11. The raw numbers in the stats table are not multiplied (BTC, Hashrate, BTC/1MH/day), only the "vsLTC" numbers are scaled by the profit multipliers.
Great! Will try out as soon as one my leased ones opens up...
June 05, 2014, 12:25:01 PM
Just to make sure - you are using 4x ratio for the vs LTC calculation, right?
Correct. Current profit multipliers are 0.47 for Scrypt-N, and 4.0 for X11. The raw numbers in the stats table are not multiplied (BTC, Hashrate, BTC/1MH/day), only the "vsLTC" numbers are scaled by the profit multipliers.
June 05, 2014, 12:17:50 PM
X11 is ready to go
Same process as the small beta for Scrypt-N. If you've mined X11 before, or are OK setting it up without any outside assistance (I don't have the "Getting Started" written yet), you're free to start using it. The obvious "This is in BETA, stuff might break" applies. Darkcoin is disabled for now until we get some more hash power (soon as we can get a block on average every hour or so, I'll enable it).
http://wafflepool.com/newalgos
Enjoy!
Same process as the small beta for Scrypt-N. If you've mined X11 before, or are OK setting it up without any outside assistance (I don't have the "Getting Started" written yet), you're free to start using it. The obvious "This is in BETA, stuff might break" applies. Darkcoin is disabled for now until we get some more hash power (soon as we can get a block on average every hour or so, I'll enable it).
http://wafflepool.com/newalgos
Enjoy!
Switching over now!!
June 05, 2014, 12:14:10 PM
X11 is ready to go
Same process as the small beta for Scrypt-N. If you've mined X11 before, or are OK setting it up without any outside assistance (I don't have the "Getting Started" written yet), you're free to start using it. The obvious "This is in BETA, stuff might break" applies. Darkcoin is disabled for now until we get some more hash power (soon as we can get a block on average every hour or so, I'll enable it).
http://wafflepool.com/newalgos
Enjoy!
Same process as the small beta for Scrypt-N. If you've mined X11 before, or are OK setting it up without any outside assistance (I don't have the "Getting Started" written yet), you're free to start using it. The obvious "This is in BETA, stuff might break" applies. Darkcoin is disabled for now until we get some more hash power (soon as we can get a block on average every hour or so, I'll enable it).
http://wafflepool.com/newalgos
Enjoy!
Just to make sure - you are using 4x ratio for the vs LTC calculation, right?
June 05, 2014, 11:59:27 AM
X11 is ready to go
Same process as the small beta for Scrypt-N. If you've mined X11 before, or are OK setting it up without any outside assistance (I don't have the "Getting Started" written yet), you're free to start using it. The obvious "This is in BETA, stuff might break" applies. Darkcoin is disabled for now until we get some more hash power (soon as we can get a block on average every hour or so, I'll enable it).
http://wafflepool.com/newalgos
Enjoy!
Same process as the small beta for Scrypt-N. If you've mined X11 before, or are OK setting it up without any outside assistance (I don't have the "Getting Started" written yet), you're free to start using it. The obvious "This is in BETA, stuff might break" applies. Darkcoin is disabled for now until we get some more hash power (soon as we can get a block on average every hour or so, I'll enable it).
http://wafflepool.com/newalgos
Enjoy!
June 05, 2014, 09:00:29 AM
sgminer + CGWatcher is what I'm using on one rig to test in preparation for waffle having x11. Can't wait for x11. I have all my rigs ready to go! The rig on x11 runs crazy cool.
June 05, 2014, 08:13:34 AM
Why bother pinning calculations to absolute currency values at all if they are guaranteed to be inaccurate as soon as the next market trade goes through? (And you even realized that by the time you finished writing your post!)
All an alternative algorithm miner would need to pass to the pool server is its own unique calculated efficiency factor, relative to Scrypt10.
The blissfully ignorant will ignore it and the pool server can use its own assumed algorithmic efficiency factors, exactly as it is doing now.
(0.50 for Scrypt11, 4.00 for X11, 3.00 for X13, etc.)
Others who are more aware of their miner's alternate algorithmic hash rate ratios can override those assumed values with more accurate ones.
(e.g. 0.48 for Scrypt11, 3.90 for X11, 2.90 for X13, etc.)
And those who understand the concept of hash rate production costs can scale the efficiency factor value appropriately.
(e.g. 0.48 for Scrypt11, 5.20 for X11, 3.87 for X13, etc.)
All an alternative algorithm miner would need to pass to the pool server is its own unique calculated efficiency factor, relative to Scrypt10.
The blissfully ignorant will ignore it and the pool server can use its own assumed algorithmic efficiency factors, exactly as it is doing now.
(0.50 for Scrypt11, 4.00 for X11, 3.00 for X13, etc.)
Others who are more aware of their miner's alternate algorithmic hash rate ratios can override those assumed values with more accurate ones.
(e.g. 0.48 for Scrypt11, 3.90 for X11, 2.90 for X13, etc.)
And those who understand the concept of hash rate production costs can scale the efficiency factor value appropriately.
(e.g. 0.48 for Scrypt11, 5.20 for X11, 3.87 for X13, etc.)
Power costs are fixed. Earnings per MH/s are variable. You cannot derive an efficiency factor for e.g. X11 without knowing the current profitability of X11 mining. Profitability is known to (estimated by) the pool and would need to be communicated to the miner to calculate that factor. All I'm suggesting is to avoid this two way communication (or website scraping or whatever) and recalculation on the miner's side, just pass the two components (hashrate and cost to run) to the pool and let the pool figure out the rest.
I'm in no mood to discuss this with you, as you seem to be missing and/or ignoring what I consider to be obvious. So you can believe whatever it is that you choose to believe.
If something like this is implemented though, all engaged miners will lose a large portion of their profitability edge, and only pool operators and distracted miners will benefit.
June 05, 2014, 07:31:55 AM
Why bother pinning calculations to absolute currency values at all if they are guaranteed to be inaccurate as soon as the next market trade goes through? (And you even realized that by the time you finished writing your post!)
All an alternative algorithm miner would need to pass to the pool server is its own unique calculated efficiency factor, relative to Scrypt10.
The blissfully ignorant will ignore it and the pool server can use its own assumed algorithmic efficiency factors, exactly as it is doing now.
(0.50 for Scrypt11, 4.00 for X11, 3.00 for X13, etc.)
Others who are more aware of their miner's alternate algorithmic hash rate ratios can override those assumed values with more accurate ones.
(e.g. 0.48 for Scrypt11, 3.90 for X11, 2.90 for X13, etc.)
And those who understand the concept of hash rate production costs can scale the efficiency factor value appropriately.
(e.g. 0.48 for Scrypt11, 5.20 for X11, 3.87 for X13, etc.)
All an alternative algorithm miner would need to pass to the pool server is its own unique calculated efficiency factor, relative to Scrypt10.
The blissfully ignorant will ignore it and the pool server can use its own assumed algorithmic efficiency factors, exactly as it is doing now.
(0.50 for Scrypt11, 4.00 for X11, 3.00 for X13, etc.)
Others who are more aware of their miner's alternate algorithmic hash rate ratios can override those assumed values with more accurate ones.
(e.g. 0.48 for Scrypt11, 3.90 for X11, 2.90 for X13, etc.)
And those who understand the concept of hash rate production costs can scale the efficiency factor value appropriately.
(e.g. 0.48 for Scrypt11, 5.20 for X11, 3.87 for X13, etc.)
Power costs are fixed. Earnings per MH/s are variable. You cannot derive an efficiency factor for e.g. X11 without knowing the current profitability of X11 mining. Profitability is known to (estimated by) the pool and would need to be communicated to the miner to calculate that factor. All I'm suggesting is to avoid this two way communication (or website scraping or whatever) and recalculation on the miner's side, just pass the two components (hashrate and cost to run) to the pool and let the pool figure out the rest.
June 05, 2014, 06:14:30 AM
poolwaffle
When we mine VTC, we also mine (merged) PLX and MON like other pool or not?
The merge-mined nscrypt coins are worth a decent penny,. WafflePool doesn't merge-mine anything (yet, anyway).When we mine VTC, we also mine (merged) PLX and MON like other pool or not?
Monocle mining gives on ~5-10% more profit.
June 05, 2014, 04:24:47 AM
poolwaffle
When we mine VTC, we also mine (merged) PLX and MON like other pool or not?
The merge-mined nscrypt coins are worth a decent penny,. WafflePool doesn't merge-mine anything (yet, anyway). When we mine VTC, we also mine (merged) PLX and MON like other pool or not?
June 05, 2014, 03:38:25 AM
poolwaffle
When we mine VTC, we also mine (merged) PLX and MON like other pool or not?
When we mine VTC, we also mine (merged) PLX and MON like other pool or not?
June 05, 2014, 12:06:00 AM
If WafflePool took this same idea, but instead waited for authentication, checked the user's pre-defined algo weights, and rejected/accepted auth based on the best algo, we would have a pretty excellent multi-algo-profit-switching pool =].
I'm very glad that other pools are interested in multi-algo as well. I'm definetly interested in common brainstorming and development in improvments in either stratum protocol or mining software, or both - whatever that could lead into efficient algo switching at miners side. Let's share ideas in the new sgminer thread https://bitcointalksearch.org/topic/ann-sgminer-v5-optimized-x11x13neoscryptlyra2reetc-kernel-switch-miner-632503 (or somewhere else).
BTW: regarding pre-defined algo weights - well, besides the hashrate ratio which is more or less equal for all miners, the only interesting weight is electrical power consumption. Unfortunatelly, electricity power consumption is not linear to BTC/GH/Day ratio calculation (exponential function with measured staring point should be used, and since miner doesn't know the current price ratio, he can't set power consumption weights). See also this example https://nicehash.com/multialgo/power-factor-calculation_x11.xlsx ... you can play with the numbers and you'll see that it is not trivial... but if you can come out with this logarithmic formula, please, do share it with me
... If we find this formula then we can introduce epp (electricity power price) parameter and evaluate it in the profitability formula.I think you are overcomplicating the power problem. The miner knows (well - needs to know) two facts about each algorithm: hashrate of the rig, and cost to run that rig. Cost to run should be normalized to a certain period - per day would be probably most convenient since we are used to calculating earnings as BTC per MH/s per day. It doesn't have to be just power cost, it could be rental cost or whatever the miner's expense is. So for example a fairly common GPU rig of 4x 280X would be:
X11: 12 MH/s, 0.002 BTC/day
X13: 9 MH/s, 0.002 BTC/day
Scrypt: 3 MH/s, 0.003 BTC/day
Scrypt-N: 1.4 MH/s, 0.003 BTC/day
This is enough information for the pool to determine which algo is best for that specific rig. I don't think there are any exponential functions involved here. Just find a way for the miner to supply that information to the pool - two numbers for each algo - whether via stratum protocol enhancements, or via password field (hate that but whatever gets it going).
If you want to make it easier for the miner you can provide a calculator on the website where the user could enter power consumption in Watts and power cost per kWh and get the BTC per day value, and even provide a list of typical rig configs to choose from, downloadable config files etc. BTC/fiat exchange rate is not that significant, because relative cost for each algo will remain roughly the same if BTC goes up or down, only the miner's absolute profit will change.
Why bother pinning calculations to absolute currency values at all if they are guaranteed to be inaccurate as soon as the next market trade goes through? (And you even realized that by the time you finished writing your post!)
All an alternative algorithm miner would need to pass to the pool server is its own unique calculated efficiency factor, relative to Scrypt10.
The blissfully ignorant will ignore it and the pool server can use its own assumed algorithmic efficiency factors, exactly as it is doing now.
(0.50 for Scrypt11, 4.00 for X11, 3.00 for X13, etc.)
Others who are more aware of their miner's alternate algorithmic hash rate ratios can override those assumed values with more accurate ones.
(e.g. 0.48 for Scrypt11, 3.90 for X11, 2.90 for X13, etc.)
And those who understand the concept of hash rate production costs can scale the efficiency factor value appropriately.
(e.g. 0.48 for Scrypt11, 5.20 for X11, 3.87 for X13, etc.)
Miners will probably have to configure unique worker names (which would need to remain consistent across all the algorithms configured for each mining rig).
The pool server will probably have to cache each worker's efficiency factor for each algorithm for an appropriate amount of time, as each mining rig can have a different set of algorithmic efficiency factors, and the efficiency factor for each algorithm would arrive individually on separate sockets (if specified via password parameter, as has been typical so far).
Or you could just automate pool selection on the client side as I have been doing for quite some time, and will probably continue doing long after anything like this is implemented. But it would be nice to have something to fall back on when your web sites are under attack and the relevant information on them (or via api) is temporarily unavailable.
June 04, 2014, 10:01:47 PM
If WafflePool took this same idea, but instead waited for authentication, checked the user's pre-defined algo weights, and rejected/accepted auth based on the best algo, we would have a pretty excellent multi-algo-profit-switching pool =].
I'm very glad that other pools are interested in multi-algo as well. I'm definetly interested in common brainstorming and development in improvments in either stratum protocol or mining software, or both - whatever that could lead into efficient algo switching at miners side. Let's share ideas in the new sgminer thread https://bitcointalksearch.org/topic/ann-sgminer-v5-optimized-x11x13neoscryptlyra2reetc-kernel-switch-miner-632503 (or somewhere else).
BTW: regarding pre-defined algo weights - well, besides the hashrate ratio which is more or less equal for all miners, the only interesting weight is electrical power consumption. Unfortunatelly, electricity power consumption is not linear to BTC/GH/Day ratio calculation (exponential function with measured staring point should be used, and since miner doesn't know the current price ratio, he can't set power consumption weights). See also this example https://nicehash.com/multialgo/power-factor-calculation_x11.xlsx ... you can play with the numbers and you'll see that it is not trivial... but if you can come out with this logarithmic formula, please, do share it with me
... If we find this formula then we can introduce epp (electricity power price) parameter and evaluate it in the profitability formula.I think you are overcomplicating the power problem. The miner knows (well - needs to know) two facts about each algorithm: hashrate of the rig, and cost to run that rig. Cost to run should be normalized to a certain period - per day would be probably most convenient since we are used to calculating earnings as BTC per MH/s per day. It doesn't have to be just power cost, it could be rental cost or whatever the miner's expense is. So for example a fairly common GPU rig of 4x 280X would be:
X11: 12 MH/s, 0.002 BTC/day
X13: 9 MH/s, 0.002 BTC/day
Scrypt: 3 MH/s, 0.003 BTC/day
Scrypt-N: 1.4 MH/s, 0.003 BTC/day
This is enough information for the pool to determine which algo is best for that specific rig. I don't think there are any exponential functions involved here. Just find a way for the miner to supply that information to the pool - two numbers for each algo - whether via stratum protocol enhancements, or via password field (hate that but whatever gets it going).
If you want to make it easier for the miner you can provide a calculator on the website where the user could enter power consumption in Watts and power cost per kWh and get the BTC per day value, and even provide a list of typical rig configs to choose from, downloadable config files etc. BTC/fiat exchange rate is not that significant, because relative cost for each algo will remain roughly the same if BTC goes up or down, only the miner's absolute profit will change.
June 04, 2014, 09:50:16 PM
Wafflepool could be dead in 6 months the way things are going.
We had a good run with scrypt coins. Scrypt-n are not so successful. X11 and X13 are the coins of the month but unfortunately their PoW phase is usually very short. By the time wafflepool implements them something new will be out.
I have a fairly good idea what the new theme is going to be. Cryptonote coins. GPU miners are out but are not very efficient in terms of energy costs. however GPU miners are being optimized as of now.
If wafflepool starts implementing cryptonote coins like MRO now, then i think we will have another good run for next year.
We had a good run with scrypt coins. Scrypt-n are not so successful. X11 and X13 are the coins of the month but unfortunately their PoW phase is usually very short. By the time wafflepool implements them something new will be out.
I have a fairly good idea what the new theme is going to be. Cryptonote coins. GPU miners are out but are not very efficient in terms of energy costs. however GPU miners are being optimized as of now.
If wafflepool starts implementing cryptonote coins like MRO now, then i think we will have another good run for next year.
Jump to: