Topic: [ANN] LEASERIG.NET - rent&hire Quark hashing power! - page 12. (Read 106977 times)
I am making LeaseRigProxy for linux today and introducing new method for providing your rigs.
If I have 2 rigs in separate location (60km away with different internet provider), will it make sense to Use proxy and rent them as 1 big hashcow ?(customer wise) Will it even be possible ?
p.s. 1 option would make our life easier
- email notification for rig provider/renter (optional) when rig goes offline (I guess it's not hard to implement)
p.s. 1 option would make our life easier
- email notification for rig provider/renter (optional) when rig goes offline (I guess it's not hard to implement)
1. It is up to you how "viable" you think it is.
2. This is coming up with next update.
If I have 2 rigs in separate location (60km away with different internet provider), will it make sense to Use proxy and rent them as 1 big hashcow ?(customer wise) Will it even be possible ?
p.s. 1 option would make our life easier
- email notification for rig provider/renter (optional) when rig goes offline (I guess it's not hard to implement)
p.s. 1 option would make our life easier
- email notification for rig provider/renter (optional) when rig goes offline (I guess it's not hard to implement)
I made a simple python script for all of you that have high count of hired rigs and issues with pools being swapped to backups. This script will periodically (every 10min) issue a command to switch to your primary pool.
Don't laugh, py is not my language, so far did only few simple things in it
(it is for python 2.7)
Feel free to improve/adjust it to your needs.
Don't laugh, py is not my language, so far did only few simple things in it
Code:
import urllib2
import urllib
import sys
import time
print "\nLeaseRig.net auto bulk switch to pool"
if len(sys.argv) < 4:
sys.exit("Only for usage with LeaseRig.net service!\nUsage: LeaseRigUpdateBulkSwitch.py [e-mail] [password] [pool]\nPool is in format: URL@username")
print "Your name is: " + sys.argv[1]
print "Your password is: " + sys.argv[2]
print "Switching to pool: " + sys.argv[3]
url = "http://leaserig.net/index.jsp?page=bulkmanage"
data = {
'switch': sys.argv[3]
}
data = urllib.urlencode(data)
print "=========================="
while True:
try:
r = urllib2.Request(url,data, headers = {'Cookie':"login=" + sys.argv[1] + "; pass=" + sys.argv[2]})
f = urllib2.urlopen(r).read()
if len(f) == 0:
print "Error!"
else:
print "Switch issued!"
time.sleep(600)
except KeyboardInterrupt:
print "Quitting on request.\n"
break
(it is for python 2.7)
Feel free to improve/adjust it to your needs.
@djeZo how to use your proxy ?
You can't yet, it is in development, soon beta testing.
I'm willing to beta test
You need to have skype + Windows 24/7 machine (can be one of the rigs). PM me your skype if you are interested.
@djeZo how to use your proxy ?
You can't yet, it is in development, soon beta testing.
I'm willing to beta test
@djeZo how to use your proxy ?
You can't yet, it is in development, soon beta testing.
I have update proxy with 2 features now;
- optional obtaining of speed via cgminer API (you need to configure all your cgminers to use same port; sorry about that, else there is much more coding to link each IP with proper port)
- support for SHA256 rigs (this is basically just different speed calculation if cgminer API isn't used for speed)
@djeZo how to use your proxy ?
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.
I guess we don't understand each other ... pools management under the POOLS looks like this for the rig provider and for the renter:
All that I'm telling you is to store this locally in your DB, so that is resilient against pool changes in the cgminer itself. Rig provider still has the option to help renter with pools management - he can do it over LeaseRig ... If you would do this there are zero changes in the User Interface, rig provider and renter would both have authority over pools and settings (together with priority, resilience over misconfigured/deleted cgminers conf files, etc.). And this could work the exact same way with the new local proxy ... djeZo, what do you think?
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
`````` Only $4,680 - Guaranteed delivery by
did you get it in the end? ....
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.
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).
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, 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.
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
).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.
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
).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.
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
).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).
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
).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.
- 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. 
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!
Jump to: