djeZo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 24, 2014, 11:22:08 PM |
|
There is one good paying order, which has high volume considering 4 hours max rental time. You should fill it up.
|
|
|
|
sn00p3r
Newbie
Offline
Activity: 4
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 01:38:40 AM |
|
As it appears, some rigs did lost stats recently, but only few. I am looking into it. It has to do something about java garbage collecting referenced objects.
I have noticed strange things too . My rig appeared down today but the rig was running ... i think the timeout theory is right , there is now reason the graph show the rig was down today ... Network connectivity of the rig is dedicated redundant fiber path with multiple providers. All circuits are monitored 24/7. my cgminer never restarted and seams to have mined properly all day. This bug need to be investigated because rig provider look bad at the end of the day.
|
|
|
|
djeZo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 02:17:05 AM |
|
If you notice downtime now, try to run the test. It will tell you where is the issue.
The lost stats bug shall not repeat again. It was fixed.
|
|
|
|
sn00p3r
Newbie
Offline
Activity: 4
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 05:05:10 AM |
|
If you notice downtime now, try to run the test. It will tell you where is the issue.
The lost stats bug shall not repeat again. It was fixed.
Maybe for the lost stats but the stats engine is bugged... i have two screenshot to prove that. 1 show that i had down time and the other show that the hash speed dropped but rig was online ... pm me an email address to send the screenshot if you want them. thanks
|
|
|
|
djeZo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 09:22:52 PM Last edit: February 25, 2014, 09:54:28 PM by djeZo |
|
UPDATE REGARDING LOCAL PROXY DEVELOPMENTI have not done much updates on site directly in past few days, because I was "hiddenly" developing local stratum mining proxy that will bring several benefits to users of LeaseRig.net (mostly providers). ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fi62.tinypic.com%2F2l25wk.png&t=665&c=nTQM_MI8M8hBbw) I am already running beta test on my own 2 rigs and will soon offer the rig (yes, now it will be one rig combining hash power of both rigs together) for rental. So, lets see what are the benefits: - no more cgminer API configuration needed - no more port forwarding needed - no more taking care of your IP either being static or using some dyndns service - basically, it gets as simple as running a simple lightweight application among with cgminers - better pool management; immediate pool changes, reliable pool removals - this will very nicely integrate with existing features such as preconfigured pools in orders and auto-set-pool when hiring - overall pool management is not bugged anymore and will work as expected- saving of pools; every change is reflected in updated pools.conf file - in case your rig goes down, you will have no issues putting customers pools back on; in fact, all you have to is run proxy and these pools will be auto loaded; pools are saved by priority (another great thing that cgminer lacks) - speed statistic is measured by ACCEPTED SHARES - the stats shown on LeaseRig will actually reflect what you get on pools; this means that rigs using this proxy can be sold for higher price - support for big farm rigs with tens of mhs - less admin management needed - pool switching is fast with no delays (just make sure your cgminer or whatever miner connects to proxy ONLY and no other pools - you can manage all backup pools via proxy - by config file or via LeaseRig.net admin panel) - decentralized mining is intact (very important factor, just check out what happened with betarigs when there were too many connections to single pool) - various miners will be supported, thus supporting cpu mining for cpu only altcoins The drawbacks are: - no realtime of khash stats that you get in cgminer; khash measured by accepted shares means that if your customer is mining on bad pool, he will get much lower actual speed (I may change this in future and report both speeds just to make everything more clear) - only stratum protocol supported (for now, I will implement getwork for solomining later; the issue with solomining is that we will not be able to calculate speed, because miners do not send any data back besides when block is solved - until I develop real pool-proxy) - variance of reported speed might be high (just like on pools) There will be windows and linux binaries provided. The application is very lightweight, coded in C, consumes almost 0 resources and could handle 500+ rigs for sure. Since it is a singlethreaded design, it means I have plenty of room to scale it up with worker threads, but so far this is not needed yet. You will be able to run it on one of your existing rigs and then configure all other rigs to connect to it in your local network.
|
|
|
|
hutnik
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 95
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 10:06:14 PM |
|
- speed statistic is measured by ACCEPTED SHARES - the stats shown on LeaseRig will actually reflect what you get on pools; this means that rigs using this proxy can be sold for higher price I don't get that. ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) speed from accepted shares will be lower than normal speed, which includes stales and rejects, right? The rig will show lower speed on site => lower price. Also the reject/stale/accepted ratio depends on pool. And customer won't know what will the ratio be on his/her pool. Am i missing something?
|
|
|
|
djeZo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 10:20:58 PM |
|
- speed statistic is measured by ACCEPTED SHARES - the stats shown on LeaseRig will actually reflect what you get on pools; this means that rigs using this proxy can be sold for higher price I don't get that. ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) speed from accepted shares will be lower than normal speed, which includes stales and rejects, right? The rig will show lower speed on site => lower price. Also the reject/stale/accepted ratio depends on pool. And customer won't know what will the ratio be on his/her pool. Am i missing something? Well, after thinking for a bit more, I decided to INCLUDE rejected and staled shares in calculation. But the variance is still high. My rig (5.3mhs) was going from 2mhs and up to 10mhs lol. That is some "luck". Anyway, the support for old "cgminer API" method is still there and will stay. So providers have a choice which method to use.
|
|
|
|
Pustul
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2014, 10:57:28 PM |
|
Another drawback I see is single point of failure, if the rig running the proxy is dead all the rigs connected to it will stop :/ And what about rigs not connected to the same local network?
|
|
|
|
Heleuka
Newbie
Offline
Activity: 22
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 06:31:07 AM |
|
Heya
newb question but in the URL section, what do I put in?
is it
stratum+tcp://grumpy.imine.at:3355
or
//grumpy.imine.at:3355
or
grumpy.imine.at:3355
Thanks!
|
|
|
|
kenshirothefist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 06:55:36 AM |
|
- speed statistic is measured by ACCEPTED SHARES - the stats shown on LeaseRig will actually reflect what you get on pools; this means that rigs using this proxy can be sold for higher price I don't get that. ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) speed from accepted shares will be lower than normal speed, which includes stales and rejects, right? The rig will show lower speed on site => lower price. Also the reject/stale/accepted ratio depends on pool. And customer won't know what will the ratio be on his/her pool. Am i missing something? Well, after thinking for a bit more, I decided to INCLUDE rejected and staled shares in calculation. But the variance is still high. My rig (5.3mhs) was going from 2mhs and up to 10mhs lol. That is some "luck". Anyway, the support for old "cgminer API" method is still there and will stay. So providers have a choice which method to use. Even better - the new local proxy should have an option to interact with cgminer API (via local network). So, if rig provider would configure&enable API in cgminer (access can be restricted to only the local network proxy), the local proxy would communicate via API with cgminer, collect hashrate data and send this data to the LeaseRig.net. This would allow you to keep the current STATS with accurate hashrate as well as the new reporting with (separate!) accepted|rejected|staled shares ... well, this would really be a great feature for the renters because: - they would really be able to see if they are getting what they are paying for (declared hashrate vs. actual hashrate) - they would be able to see if the pool where they are mining if efficient - they would be able to see if the rig is configured to be efficient (high stales/rejects are many times due to overclocked/misconfigured rigs) LeaseRig is great because renters are able to get full transparent overview of the rented rig and are getting the best possible efficiency out of rented rigs (they can't get this on betarigs...) ... so, djeZo, you should at least keep this level or possibly improve it!
|
|
|
|
kenshirothefist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 07:25:27 AM |
|
Another drawback I see is single point of failure, if the rig running the proxy is dead all the rigs connected to it will stop :/
This is my concern, also. One solution is to run "leaserig local proxy" on a separate machine, which is independent of "the high possibility of a rig crashing" ... however, this is still a single point of failure (and requires additional machine, even though it can be an old Celeron ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) ). What I would really want is a master-slave feature for "leaserig local proxy". Let me explain ... let's say I have 5 rigs. I would install "leaserig local proxy" on first and on another, second rig. I would run "leaserig local proxy" as master on first rig and as slave on second rig - the slave would be alive, but not active. I would configure two pools on each rig's cgminer (fist pool master local proxy, second pool slave local proxy). If the "master" rig would die, the slave local proxy would detect this and "enable itself" - and rigs would switch to failover pool (slave local proxy) and all is good ... When I fix the master rig, the master local proxy is alive again and it enables itself while disabling the slave local proxy, cgminers switches to primary pool (master local proxy). And what about rigs not connected to the same local network?
Well, LeaseRig is all about decentralization ... which we want to keep. Therefore there is no point in grouping many dislocated rigs in a big rig because in this case you can't assure "best performance" for the renter. If you have many rigs in different networks, but they are still close enough, you can of course configure the "local proxy" to listen on a public interface (or configure NAT) and then you can connect your cgminers to this local proxy ... but if rigs are dislocated you will just have to keep them separated and run local proxy on each rig.
|
|
|
|
s4ndm4ns
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 11:02:17 AM |
|
UPDATE REGARDING LOCAL PROXY DEVELOPMENTI have not done much updates on site directly in past few days, because I was "hiddenly" developing local stratum mining proxy that will bring several benefits to users of LeaseRig.net (mostly providers). ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fi62.tinypic.com%2F2l25wk.png&t=665&c=nTQM_MI8M8hBbw) I am already running beta test on my own 2 rigs and will soon offer the rig (yes, now it will be one rig combining hash power of both rigs together) for rental. So, lets see what are the benefits: - no more cgminer API configuration needed - no more port forwarding needed - no more taking care of your IP either being static or using some dyndns service - basically, it gets as simple as running a simple lightweight application among with cgminers - better pool management; immediate pool changes, reliable pool removals - this will very nicely integrate with existing features such as preconfigured pools in orders and auto-set-pool when hiring - overall pool management is not bugged anymore and will work as expected- saving of pools; every change is reflected in updated pools.conf file - in case your rig goes down, you will have no issues putting customers pools back on; in fact, all you have to is run proxy and these pools will be auto loaded; pools are saved by priority (another great thing that cgminer lacks) - speed statistic is measured by ACCEPTED SHARES - the stats shown on LeaseRig will actually reflect what you get on pools; this means that rigs using this proxy can be sold for higher price - support for big farm rigs with tens of mhs - less admin management needed - pool switching is fast with no delays (just make sure your cgminer or whatever miner connects to proxy ONLY and no other pools - you can manage all backup pools via proxy - by config file or via LeaseRig.net admin panel) - decentralized mining is intact (very important factor, just check out what happened with betarigs when there were too many connections to single pool) - various miners will be supported, thus supporting cpu mining for cpu only altcoins The drawbacks are: - no realtime of khash stats that you get in cgminer; khash measured by accepted shares means that if your customer is mining on bad pool, he will get much lower actual speed (I may change this in future and report both speeds just to make everything more clear) - only stratum protocol supported (for now, I will implement getwork for solomining later; the issue with solomining is that we will not be able to calculate speed, because miners do not send any data back besides when block is solved - until I develop real pool-proxy) - variance of reported speed might be high (just like on pools) There will be windows and linux binaries provided. The application is very lightweight, coded in C, consumes almost 0 resources and could handle 500+ rigs for sure. Since it is a singlethreaded design, it means I have plenty of room to scale it up with worker threads, but so far this is not needed yet. You will be able to run it on one of your existing rigs and then configure all other rigs to connect to it in your local network. So if I got everything up and running, configured and so on. Is there any benefit for me as provider?
|
|
|
|
kenshirothefist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 11:18:04 AM |
|
UPDATE REGARDING LOCAL PROXY DEVELOPMENT
So if I got everything up and running, configured and so on. Is there any benefit for me as provider? If you have only one rig and you're happy with current configuration (API, IP, DNS, etc.) then there is no benefit for you and you can keep things just the way they are now (as far as I understood djeZo, LeaseRig will support both modes - current and with local proxy). If you have multiple rigs you would benefit with the local proxy, because you could offer all the rigs as a whole, for example, if you have 3Mh/s, 4Mh/s and another 3Mh/s rig right now, you can offer all three of them as one 10Mh/s rig - big rigs are attractive for the renters (simplifies management and is always nice to have a "beast" in your control ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) ). I thing that djeZo forgot to stress out that the biggest benefit with the local proxy will be for all the new upcoming providers because the initial setup will be much easier with local proxy (and of course, for those with multiple rigs who want to offer all of them as a whole).
|
|
|
|
djeZo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 11:27:30 AM |
|
UPDATE REGARDING LOCAL PROXY DEVELOPMENT
So if I got everything up and running, configured and so on. Is there any benefit for me as provider? If you have only one rig and you're happy with current configuration (API, IP, DNS, etc.) then there is no benefit for you and you can keep things just the way they are now (as far as I understood djeZo, LeaseRig will support both modes - current and with local proxy). If you have multiple rigs you would benefit with the local proxy, because you could offer all the rigs as a whole, for example, if you have 3Mh/s, 4Mh/s and another 3Mh/s rig right now, you can offer all three of them as one 10Mh/s rig - big rigs are attractive for the renters (simplifies management and is always nice to have a "beast" in your control ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) ). I thing that djeZo forgot to stress out that the biggest benefit with the local proxy will be for all the new upcoming providers because the initial setup will be much easier with local proxy (and of course, for those with multiple rigs who want to offer all of them as a whole). Yes, exactly. And you forgot to mention that this new method with local proxy has way better pool management. The biggest issue with cgminer pools is that it will not save them in config by priority. You may have everything set up correctly in case of rig failures, but you will eventually fail to deliver proper pool order as your customer set. With LeaseRigProxy, this issue is gone, because pool saving is done by priority. I will add option to LeaseRigProxy to read speeds stats from cgminer API. Then it is time to do some more testings involving more providers. I need providers with Windows machines (to put proxy on) for testing.
|
|
|
|
salsamoves
Newbie
Offline
Activity: 58
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 11:32:48 AM |
|
UPDATE REGARDING LOCAL PROXY DEVELOPMENT
So if I got everything up and running, configured and so on. Is there any benefit for me as provider? If you have only one rig and you're happy with current configuration (API, IP, DNS, etc.) then there is no benefit for you and you can keep things just the way they are now (as far as I understood djeZo, LeaseRig will support both modes - current and with local proxy). If you have multiple rigs you would benefit with the local proxy, because you could offer all the rigs as a whole, for example, if you have 3Mh/s, 4Mh/s and another 3Mh/s rig right now, you can offer all three of them as one 10Mh/s rig - big rigs are attractive for the renters (simplifies management and is always nice to have a "beast" in your control ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) ). I thing that djeZo forgot to stress out that the biggest benefit with the local proxy will be for all the new upcoming providers because the initial setup will be much easier with local proxy (and of course, for those with multiple rigs who want to offer all of them as a whole). Yes, exactly. And you forgot to mention that this new method with local proxy has way better pool management. The biggest issue with cgminer pools is that it will not save them in config by priority. You may have everything set up correctly in case of rig failures, but you will eventually fail to deliver proper pool order as your customer set. With LeaseRigProxy, this issue is gone, because pool saving is done by priority. I will add option to LeaseRigProxy to read speeds stats from cgminer API. Then it is time to do some more testings involving more providers. I need providers with Windows machines (to put proxy on) for testing. DjeZo, will we only be able to offer as a big rig or will we be able to have the leasee split it/ choose a smaller one? I also suppose that it will make it easier for us to change our own pools too when they arent rented out. I use windows at the moment, and could test it on some of my rigs if you like? how long will it take to set up and in how long will you be ready? have the kids later for 4 hours or so.
|
|
|
|
Tigggger
Legendary
Offline
Activity: 1098
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 11:46:54 AM |
|
DjeZo, will we only be able to offer as a big rig or will we be able to have the leasee split it/ choose a smaller one?
I'm curious about this too, have over 2TH of SHA256 miners I can bring bring (which ties in with the topic change), there may be a market for that size but if not would be nice to offer the individual machines. Also will this new proxy allow the use of antminers as currently I don't think it's possible due to them not using a cgminer.conf file If you need someone to help test I have windows and am around all day.
|
|
|
|
kenshirothefist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 11:51:29 AM |
|
And you forgot to mention that this new method with local proxy has way better pool management. The biggest issue with cgminer pools is that it will not save them in config by priority. You may have everything set up correctly in case of rig failures, but you will eventually fail to deliver proper pool order as your customer set. With LeaseRigProxy, this issue is gone, because pool saving is done by priority.
Yeah ... but djeZo, I've already told you that you could actually implement this already - you could simply implement scheduled task (for example every minute) in the LeaseRig to check if the pool priority order, set by LeaseRig, is the same as the pool order in the rented machine. And if it is not, you can reorder pool priority on the rented machine via the cgminer "priority" API call. Of course, to do that, you would have to implement "stored pool list with priority" for renters (for each rented rig) ... this would also be useful in case if rig provider accidentally deletes cgminer conf, etc. That said, you would never synchronize pools rig -> leaserig but always only leaserig -> rig (this is the way it should be because when a rig is rented, all that counts is what renter sets via LeaseRig).
|
|
|
|
djeZo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 11:51:32 AM |
|
DjeZo, will we only be able to offer as a big rig or will we be able to have the leasee split it/ choose a smaller one?
I'm curious about this too, have over 2TH of SHA256 miners I can bring bring (which ties in with the topic change), there may be a market for that size but if not would be nice to offer the individual machines. Also will this new proxy allow the use of antminers as currently I don't think it's possible due to them not using a cgminer.conf file If you need someone to help test I have windows and am around all day. You can split it up by running multiple instances of proxy, just use different listen port for each proxy. This should work with any miner, as long as it is using stratum protocol. For SHA256, I need to test speed measurement, I think it is calculated a bit different (scrypt does multiply shares with 2^16, SHA256 multiply with 2^32 - this is so far only theory for me, need to test in practice).
|
|
|
|
djeZo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 11:55:44 AM |
|
And you forgot to mention that this new method with local proxy has way better pool management. The biggest issue with cgminer pools is that it will not save them in config by priority. You may have everything set up correctly in case of rig failures, but you will eventually fail to deliver proper pool order as your customer set. With LeaseRigProxy, this issue is gone, because pool saving is done by priority.
Yeah ... but djeZo, I've already told you that you could actually implement this already - you could simply implement scheduled task (for example every minute) in the LeaseRig to check if the pool priority order, set by LeaseRig, is the same as the pool order in the rented machine. And if it is not, you can reorder pool priority on the rented machine via the cgminer "priority" API call. Of course, to do that, you would have to implement "stored pool list with priority" for renters (for each rented rig) ... this would also be useful in case if rig provider accidentally deletes cgminer conf, etc. That said, you would never synchronize pools rig -> leaserig but always only leaserig -> rig (this is the way it should be because when a rig is rented, all that counts is what renter sets via LeaseRig). The problem with this is that sometimes providers "correct" pool errors of their customers and help them. If I do LeaseRig pool management, then this will be broken and become an annoying problem. The question that remains is; should LeaseRig take customer as full authority over pools when rig is rented or is does provider have full authority? In both cases of implementation, it brings additional problems and unhappy customers. And I am not willing to make another switch on admin panel to configure this, because we already have many and most new providers are lost due to the amount of configuration possible.
|
|
|
|
salsamoves
Newbie
Offline
Activity: 58
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2014, 12:07:35 PM |
|
DjeZo, will we only be able to offer as a big rig or will we be able to have the leasee split it/ choose a smaller one?
I'm curious about this too, have over 2TH of SHA256 miners I can bring bring (which ties in with the topic change), there may be a market for that size but if not would be nice to offer the individual machines. Also will this new proxy allow the use of antminers as currently I don't think it's possible due to them not using a cgminer.conf file If you need someone to help test I have windows and am around all day. The Monarch 600, 500, 400 GH/s - 350, 450, 550, 650W - Pre-Order Yours Today! `````` Only $4,680 - Guaranteed delivery by December 2013, January, February, March, April, May, June, July, August, September, October, November, December 2014 did you get it in the end? ....
|
|
|
|
|