My profits have been decreasing dramatically as well.
Didn't start happening until that 'flat-spot' in the dashboard Exhanged BTC graph. Conveniently that is when the "BTC echanged by day' graph went down for 'maintenance'
Also, I am having trouble understanding how SPECULATIVE mining is working for CNL with the auto-exchange.
How can the auto-exchange be exchanging CNL when there is no exchange available???
Is it being done privately, or is it TMB that is speculating by exchanging a minimal amount of BTC for each CNL. Then dumping once it hits an exchange for a lot more?
If this is what is happening, i will have to disable my auto-exchange for CNL and speculative coins, which is problematic in its own way, as withdrawals to exchanges seem to rarely occur until TMB dumps first. No matter how quick you get in.
Am i missing something?
Topic: [ANN][MULTI][VARDIFF] TradeMyBit MULTIALGO Profit Swap w/ Optional Auto-exchange - page 10. (Read 153067 times)
July 18, 2014, 11:57:03 PM
July 18, 2014, 03:25:43 PM
that happend?
2014-07-17 23:51:00 0.02318156 BTC
2014-07-16 23:04:33 0.02175422 BTC
now 18.07 23.59 0.00224426
why profit is ten time smaller? I watch all the day stats, and profit never beet below 0.0003-0.0007
2014-07-17 23:51:00 0.02318156 BTC
2014-07-16 23:04:33 0.02175422 BTC
now 18.07 23.59 0.00224426
why profit is ten time smaller? I watch all the day stats, and profit never beet below 0.0003-0.0007
July 18, 2014, 10:05:30 AM
Can some explain the details of the proportional payout system that is used on TMB please?
With the use of the multi-algorithm miners (or in my case my home-made API based switcher) on the TMB pools, how does a miner get rewarded when swapping between algorithm pools?
Is the payout based only on shares within a block regardless of time? Some PPS variants use a time element to discourage pool hopping - eg; shares in last N seconds or similar or so called PPLNS.
If the difficulty is relatively low within the block and the number of shares is low, then the payout per share at that stage will be better than average for the block? Conversely if the difficulty is higher and the number of shares is high, then the payout per share is worse than average for the block. This is the whole point of the 'pool-hopping' problem isn't it?
How does the multi-algorithm hopping take account of this? Does it take this into account when switching?
For people using their own API-switching code, are you looking at this when making the switching decision? eg; number of shares and difficulty
I am doing a simple switch based only on the reported profitability every 5 minutes. If the profitability of a different algorithm is +5% then I switch. If not I stick. However I feel I should be taking more into account before switching.
Thoughts?
With the use of the multi-algorithm miners (or in my case my home-made API based switcher) on the TMB pools, how does a miner get rewarded when swapping between algorithm pools?
Is the payout based only on shares within a block regardless of time? Some PPS variants use a time element to discourage pool hopping - eg; shares in last N seconds or similar or so called PPLNS.
If the difficulty is relatively low within the block and the number of shares is low, then the payout per share at that stage will be better than average for the block? Conversely if the difficulty is higher and the number of shares is high, then the payout per share is worse than average for the block. This is the whole point of the 'pool-hopping' problem isn't it?
How does the multi-algorithm hopping take account of this? Does it take this into account when switching?
For people using their own API-switching code, are you looking at this when making the switching decision? eg; number of shares and difficulty
I am doing a simple switch based only on the reported profitability every 5 minutes. If the profitability of a different algorithm is +5% then I switch. If not I stick. However I feel I should be taking more into account before switching.
Thoughts?
We use PROP, not PPLNS.. so you are paid for every share you contribute towards a block whenever a block is found, regardless if you're mining on the block from the beginning, or if you hop in just before a block is found. The value per share is relative to the total amount of shares contributed to that block find.
July 18, 2014, 02:20:48 AM
Hey guys,
Have you made a change to the bestalgo API call???
That's the normalised score and the actual score?
Great!!
Thanks very much
+1 vote for this request
Have you made a change to the bestalgo API call???
Code:
[{"algo":"x11","score":"0.00327663","actual":"0.000595751"},{"algo":"nist5","score":"0.00266068","actual":"0.000161253"},{"algo":"x13","score":"0.00215897","actual":"0.000583506"},{"algo":"nscrypt","score":"0.0012064","actual":"0.00256681"},{"algo":"scrypt","score":"0.000672299","actual":"0.000672299"},{"algo":"x15","score":"0.000350805","actual":"0.000103178"}]
That's the normalised score and the actual score?
Great!!
Thanks very much
How about an API call for raw (non normalized) BTC/Day/Mhash earnings per algorithm?
I'm planning to extend my autoswitcher (currently works with NiceHash) to support TradeMyBit. To make it work correctly I need the non-normalized earnings per algorithm as I factor in hash rates myself to get the best bang for the hash. The "bestalgo" call has the format I want, but it currently has normalized values. If another key/value pair could be added per algorithm for the non-normalized values this would work great.
I'm planning to extend my autoswitcher (currently works with NiceHash) to support TradeMyBit. To make it work correctly I need the non-normalized earnings per algorithm as I factor in hash rates myself to get the best bang for the hash. The "bestalgo" call has the format I want, but it currently has normalized values. If another key/value pair could be added per algorithm for the non-normalized values this would work great.
+1 vote for this request
July 18, 2014, 01:56:36 AM
Can some explain the details of the proportional payout system that is used on TMB please?
With the use of the multi-algorithm miners (or in my case my home-made API based switcher) on the TMB pools, how does a miner get rewarded when swapping between algorithm pools?
Is the payout based only on shares within a block regardless of time? Some PPS variants use a time element to discourage pool hopping - eg; shares in last N seconds or similar or so called PPLNS.
If the difficulty is relatively low within the block and the number of shares is low, then the payout per share at that stage will be better than average for the block? Conversely if the difficulty is higher and the number of shares is high, then the payout per share is worse than average for the block. This is the whole point of the 'pool-hopping' problem isn't it?
How does the multi-algorithm hopping take account of this? Does it take this into account when switching?
For people using their own API-switching code, are you looking at this when making the switching decision? eg; number of shares and difficulty
I am doing a simple switch based only on the reported profitability every 5 minutes. If the profitability of a different algorithm is +5% then I switch. If not I stick. However I feel I should be taking more into account before switching.
Thoughts?
With the use of the multi-algorithm miners (or in my case my home-made API based switcher) on the TMB pools, how does a miner get rewarded when swapping between algorithm pools?
Is the payout based only on shares within a block regardless of time? Some PPS variants use a time element to discourage pool hopping - eg; shares in last N seconds or similar or so called PPLNS.
If the difficulty is relatively low within the block and the number of shares is low, then the payout per share at that stage will be better than average for the block? Conversely if the difficulty is higher and the number of shares is high, then the payout per share is worse than average for the block. This is the whole point of the 'pool-hopping' problem isn't it?
How does the multi-algorithm hopping take account of this? Does it take this into account when switching?
For people using their own API-switching code, are you looking at this when making the switching decision? eg; number of shares and difficulty
I am doing a simple switch based only on the reported profitability every 5 minutes. If the profitability of a different algorithm is +5% then I switch. If not I stick. However I feel I should be taking more into account before switching.
Thoughts?
July 18, 2014, 12:04:30 AM
I'd love to see stats on percentage of time spent on the various 4010-4013 ports!
See dashboard (only x11-x13-(n)-scrypt..)?
https://pool.trademybit.com/charts/
Yes, I'm aware of the dashboard, but this page doesn't show what % of time each 4010-4013 port was open (which algo was most profitable at the time).
In the irc channel #poolspam you can check it out via "-last multi"
Example:
Quote
[05:59:46] [TMBPool] multi stats for last 24 hrs
[05:59:46] 1 - X11 mined for 11.54 hrs (48.56%)
[05:59:46] 2 - X13 mined for 8.22 hrs (34.60%)
[05:59:46] 3 - NIST5 mined for 3.89 hrs (16.35%)
[05:59:46] 4 - X15 mined for 0.12 hrs (0.49%)
[05:59:46]
[05:59:46]
[05:59:46]
[05:59:46]
Excellent, that's just what I was looking for! Thanks!
July 18, 2014, 12:02:24 AM
I'd love to see stats on percentage of time spent on the various 4010-4013 ports!
See dashboard (only x11-x13-(n)-scrypt..)?
https://pool.trademybit.com/charts/
Yes, I'm aware of the dashboard, but this page doesn't show what % of time each 4010-4013 port was open (which algo was most profitable at the time).
In the irc channel #poolspam you can check it out via "-last multi"
Example:
Quote
[05:59:46] [TMBPool] multi stats for last 24 hrs
[05:59:46] 1 - X11 mined for 11.54 hrs (48.56%)
[05:59:46] 2 - X13 mined for 8.22 hrs (34.60%)
[05:59:46] 3 - NIST5 mined for 3.89 hrs (16.35%)
[05:59:46] 4 - X15 mined for 0.12 hrs (0.49%)
[05:59:46]
[05:59:46]
[05:59:46]
[05:59:46]
July 17, 2014, 10:41:37 PM
I'd love to see stats on percentage of time spent on the various 4010-4013 ports!
See dashboard (only x11-x13-(n)-scrypt..)?
https://pool.trademybit.com/charts/
Yes, I'm aware of the dashboard, but this page doesn't show what % of time each 4010-4013 port was open (which algo was most profitable at the time).
July 17, 2014, 07:07:46 PM
How about an API call for raw (non normalized) BTC/Day/Mhash earnings per algorithm?
I'm planning to extend my autoswitcher (currently works with NiceHash) to support TradeMyBit. To make it work correctly I need the non-normalized earnings per algorithm as I factor in hash rates myself to get the best bang for the hash. The "bestalgo" call has the format I want, but it currently has normalized values. If another key/value pair could be added per algorithm for the non-normalized values this would work great.
I'm planning to extend my autoswitcher (currently works with NiceHash) to support TradeMyBit. To make it work correctly I need the non-normalized earnings per algorithm as I factor in hash rates myself to get the best bang for the hash. The "bestalgo" call has the format I want, but it currently has normalized values. If another key/value pair could be added per algorithm for the non-normalized values this would work great.
+1 vote for this request
July 17, 2014, 03:32:27 PM
I'd love to see stats on percentage of time spent on the various 4010-4013 ports!
See dashboard (only x11-x13-(n)-scrypt..)?
https://pool.trademybit.com/charts/
July 17, 2014, 02:14:24 PM
I'd love to see stats on percentage of time spent on the various 4010-4013 ports!
July 16, 2014, 09:40:41 PM
Code:
"pools" : [
{
"name" : "TMB USW X11",
"url" : "stratum+tcp://west01.us.trademybit.com:4010",
"user": "barry.shitpeas",
"pass": "password",
"algorithm" : "darkcoin-mod"
},
{
"name" : "TMB USW X13",
"url" : "stratum+tcp://west01.us.trademybit.com:4011",
"user": "barry.shitpeas",
"pass": "password",
"algorithm" : "marucoin-mod"
},
{
"name" : "TMB USW X15",
"url" : "stratum+tcp://west01.us.trademybit.com:4012",
"user": "barry.shitpeas",
"pass": "password",
"algorithm" : "bitblock"
},
{
"name" : "TMB USW Nist5",
"url" : "stratum+tcp://west01.us.trademybit.com:4013",
"user": "barry.shitpeas",
"pass": "password",
"algorithm" : "talkcoin-mod"
},
{
"name" : "STATIC USW 1 Nist5",
"url" : "stratum+tcp://west01.us.trademybit.com:7770",
"user" : "barry.shitpeas",
"pass" : "password",
"algorithm" : "talkcoin-mod"
},
{
"name" : "STATIC USW 1 X11",
"url" : "stratum+tcp://west01.us.trademybit.com:4440",
"user" : "barry.shitpeas",
"pass" : "password",
"algorithm" : "darkcoin-mod"
},
{
"name" : "STATIC USW 1 X15",
"url" : "stratum+tcp://west01.us.trademybit.com:6660",
"user" : "barry.shitpeas",
"pass" : "password",
"algorithm" : "bitblock"
},
{
"name" : "STATIC USW 1 X13",
"url" : "stratum+tcp://west01.us.trademybit.com:5550",
"user" : "barry.shitpeas",
"pass" : "password",
"algorithm" : "marucoin-mod"
}
],
"intensity" : "20",
"thread-concurrency" : "8192",
"gpu-engine" : "1130",
"gpu-memclock" : "1500",
"gpu-powertune" : "20",
"gpu-threads" : "2",
"vectors" : "1",
"lookup-gap" : "2",
"worksize" : "128",
"shaders" : "2048",
"gpu-fan" : "0-90",
"temp-cutoff" : "95",
"temp-overheat" : "85",
"temp-target" : "72",
"auto-fan" : true,
"log" : "5",
"failover-only" : true,
"failover-switch-delay" : "30",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "10",
"expiry" : "120",
"hamsi-expand-big" : "1"
}
I think you are over complicating things guys....
Only one port is open at any given stage. (besides Static Backup pools) No more than around 5 secs overlap delay before old port closes and new port switches. Failover is the only strategy needed. This 'multimultimultimultiport' 'extranonce-subscription' jargon is really screwing up the elegant simplicity that TMB has. (I don't know about nicehash, perhaps they are more complicated)
If you are running your own API switching methods, then port 4010-4013 will NOT work correctly, use the static ports 4440,5550,6660,7770.
July 16, 2014, 04:07:55 PM
TMB_Multi-Multi_X11 stable for 10 seconds
"failover-switch-delay": "10",
drop that value
"failover-switch-delay": "10",
drop that value
Tried that, but this setting isn't having any substantial effect on the timing problem, since it appears that the ports simply aren't opening up in a timely fashion when they become most profitable (according to the homepage). Often times I'll even notice that two or more multi-multi ports are simultaneously open for a minute or more. Something weird is going on...
Merc, are you aware of this?
The mainpage is delayed if you want live multimulitport check the irc out, the two or more ports open is a sg5 problem. cheers
Thanks for that...yeah, so the multi-multi ports switch a bit after what the mainpage shows...I guess the switcher has some time-averaging factored in to smooth things out and avoid switching too frequently. Makes sense, thanks!
July 16, 2014, 01:30:36 PM
TMB_Multi-Multi_X11 stable for 10 seconds
"failover-switch-delay": "10",
drop that value
"failover-switch-delay": "10",
drop that value
Tried that, but this setting isn't having any substantial effect on the timing problem, since it appears that the ports simply aren't opening up in a timely fashion when they become most profitable (according to the homepage). Often times I'll even notice that two or more multi-multi ports are simultaneously open for a minute or more. Something weird is going on...
Merc, are you aware of this?
The mainpage is delayed if you want live multimulitport check the irc out, the two or more ports open is a sg5 problem. cheers
July 16, 2014, 01:21:01 PM
Can I set my own difficulty on X11 or X13 via the password?
July 16, 2014, 11:23:54 AM
TMB_Multi-Multi_X11 stable for 10 seconds
"failover-switch-delay": "10",
drop that value
"failover-switch-delay": "10",
drop that value
Tried that, but this setting isn't having any substantial effect on the timing problem, since it appears that the ports simply aren't opening up in a timely fashion when they become most profitable (according to the homepage). Often times I'll even notice that two or more multi-multi ports are simultaneously open for a minute or more. Something weird is going on...
Merc, are you aware of this?
July 16, 2014, 11:20:23 AM
Does anyone else notice with sgminer5 that the 4010-4013 multi-multi ports seem to lag considerably behind what coin/algo is in the top profitability spot on the TMB homepage? My sgminer5 seems to switch ports at least 30-60 seconds after the top spot changes on the website... Are there config settings I should be adjusting to make the switches quicker, or is this an issue on the TMB stratum side of things?
Quoted from below the BTC/Hashrate chart:
"Hashrate's are a 10minute average, they may be lagged a bit
"Yeah, what I'm talking about has nothing to do with the hashrate displays...rather that the multi-multi ports don't seem to open up when they become the most profitable...
July 16, 2014, 08:59:50 AM
No, you are correct I do not take into account the 2% withdraw fee.
To be honest I was just adding the NiceHash numbers to give me a rough idea of how they are comparing. So far TMB is winning (and the gap is more than 2%). I will factor in that 2% fee from now on.
Then next thing to do is to actually record earning properly so that we aren't misled by the stats given to us by the pools!!
Having said all that, NiceHash has just overtaken TMB!! I need to get that pool switch code working
Code:
------------------------------------------
2014-07-16 13:47:51 Current Rate: nist5 0.0075
2014-07-16 13:47:51 NiceHash Best Rate: x13 0.0070
2014-07-16 13:47:51 Best Rate: nist5 0.0075 stay: algo still best
------------------------------------------
2014-07-16 13:52:52 Current Rate: nist5 0.0068
2014-07-16 13:52:52 NiceHash Best Rate: x13 0.0070
2014-07-16 13:52:52 Best Rate: nist5 0.0068 stay: algo still best
------------------------------------------
2014-07-16 13:57:54 Current Rate: nist5 0.0027
2014-07-16 13:57:54 NiceHash Best Rate: x13 0.0070
2014-07-16 13:57:54 Best Rate: x11 0.0066 switch: performance +138.9%
De-normalizing will probably be my workaround as well. Unfortunately it means the users have to update those values every time the pool changes the normalization factors.
When comparing NiceHash to TMB are you also factoring in the 2% withdrawl fee on TMB? I'm curious myself to see how the two services stack up but it will be a week or two before I have everything wired up.
When comparing NiceHash to TMB are you also factoring in the 2% withdrawl fee on TMB? I'm curious myself to see how the two services stack up but it will be a week or two before I have everything wired up.
July 16, 2014, 08:52:07 AM
July 16, 2014, 08:26:31 AM
Just done the same thing! And I wanted raw earnings as well.
All I did was take their settings and divide all values by their normalisation factor. Not so hard, but it is a pain to keep up to date. Raw would be so much better. Simple python dictionary.
Code:
tmb_n = {}
tmb_n['scrypt'] = 1.000
tmb_n['nscrypt'] = 0.470
tmb_n['x11'] = 5.500
tmb_n['x13'] = 3.800
tmb_n['x15'] = 3.400
tmb_n['nist5'] = 16.500
I check every 5 minutes, then if the difference is more than 5% I will switch. If less than 5% I leave it run.
I also added a check against NiceHash with a view to adding code to switch pool if needed but so far NiceHash never beats the reported TMB numbers. For example:
Code:
------------------------------------------
2014-07-16 12:22:39 Current Rate: x13 0.0107
2014-07-16 12:22:40 NiceHash Best Rate: x13 0.0063
2014-07-16 12:22:40 Best Rate: x13 0.0107 stay: algo still best
------------------------------------------
2014-07-16 12:27:41 Current Rate: x13 0.0081
2014-07-16 12:27:41 NiceHash Best Rate: x13 0.0064
2014-07-16 12:27:41 Best Rate: x11 0.0083 stay: performance +3.0%
------------------------------------------
2014-07-16 12:32:42 Current Rate: x13 0.0085
2014-07-16 12:32:42 NiceHash Best Rate: x13 0.0065
2014-07-16 12:32:42 Best Rate: x13 0.0085 stay: algo still best
------------------------------------------
2014-07-16 12:37:43 Current Rate: x13 0.0143
2014-07-16 12:37:44 NiceHash Best Rate: x13 0.0065
2014-07-16 12:37:44 Best Rate: x11 0.0226 switch: performance +57.3%
------------------------------------------
2014-07-16 12:42:45 Current Rate: x11 0.0091
2014-07-16 12:42:45 NiceHash Best Rate: x13 0.0065
2014-07-16 12:42:45 Best Rate: x13 0.0098 switch: performance +8.6%
------------------------------------------
2014-07-16 12:47:46 Current Rate: x13 0.0129
2014-07-16 12:47:46 NiceHash Best Rate: x13 0.0065
2014-07-16 12:47:46 Best Rate: x13 0.0129 stay: algo still best
------------------------------------------
2014-07-16 12:52:47 Current Rate: x13 0.0088
2014-07-16 12:52:47 NiceHash Best Rate: x13 0.0065
2014-07-16 12:52:47 Best Rate: x13 0.0088 stay: algo still best
How about an API call for raw (non normalized) BTC/Day/Mhash earnings per algorithm?
I'm planning to extend my autoswitcher (currently works with NiceHash) to support TradeMyBit. To make it work correctly I need the non-normalized earnings per algorithm as I factor in hash rates myself to get the best bang for the hash. The "bestalgo" call has the format I want, but it currently has normalized values. If another key/value pair could be added per algorithm for the non-normalized values this would work great.
I'm planning to extend my autoswitcher (currently works with NiceHash) to support TradeMyBit. To make it work correctly I need the non-normalized earnings per algorithm as I factor in hash rates myself to get the best bang for the hash. The "bestalgo" call has the format I want, but it currently has normalized values. If another key/value pair could be added per algorithm for the non-normalized values this would work great.
Jump to: