I don't want to do that - customers may judge rigs out of shares and we all know that share stats can greatly depend on how good pool is
Exactly - this would be a good added value for customers - if accepted share percentage is low, they just might be mining at a bad pool and therefore they could switch to a better pool. And if customer is 100% sure that the pool is OK but there are still lots of rejects (for example > 10%) this would indicate a misconfigured/unhealthy rig. And yes, I agree that this information might bring some confusion ... it's all about weather to put providers or renters in a better position  And of course you would display this info only for the current rent period and would only be visible to the provider and current renter. Besides, share stats are reset the same moment you turn off cgminer or you turn off proxy, so there is not much point in doing this.
True. Maybe you could only display efficiency graph ... rejected divided by accepted in percentage - this would "survive" cgminer/proxy restart. |
|
|
|
Speed is measured out of shares - it is all about luck. I suggest you to use cgminer API speed readings.
djeZo, could you display separate graphs? One for hashpower (as it is already) + separate graph showing accepted/rejected/invalid shares? |
|
|
|
Front page loads much faster now. Only available rigs are loaded, the other ones are loaded on request. Now, lets scale up to 1000 rigs!  The information "Total Scrypt mining rigs: x" is kinda misleading ... it should be: Available Scrypt mining rigs: X (xx Mh/s); Rented Scrypt mining rigs: Y (yy Mh/s); Total Scrypt mining rigs: Z (zz Mh/s) |
|
|
|
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? |
|
|
|
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). |
|
|
|
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! |
|
|
|
|
I'm looking for a decent stratum proxy software ... bfgminer as proxy and miner-proxy are no good (problems with cgminer and limitations) ... does anybody knows for a good stratum proxy? I've seen some providers are providing farms of 10, 20, 30 and more Mh/s on BetaRigs, if anybody of those provider is reading this - what kind of stratum proxy software are you using?
|
|
|
|
I'm also looking for some advanced stratum proxy. MultiMiner is problematic, because it uses BFGminer as the proxy, which has problems with various cgminers. The famous mining-proxy (from here: http://mining.bitcoin.cz/mining-proxy-howto) is somehow useless, since I can only define one pool and thus I don't have any backup/failover pools. So, is there any decent advanced stratum proxy? By "advanced" I mean: - it should have support for mutiple pools (primary, backup/failover ...) - it should work with various cgminers, sgminers and other forks of them (vertminer...) Basically what I want is to have a single machine as a proxy, and all my miners would connect to this machine, and then to the actual pools. Miners can be configured for various coins (regular scrypt, vertcoin, scrypt-jane, keccak ... of course all miners would mine the same type of coin at once). Any suggestions? |
|
|
|
Is it possible you implement stratum proxy for cgminer connections? I get H-not-zero errors and it looks like more people ran into the same. You would be a hero of a lot of people if you implement that This is a bug in cgminer. Any working stratum client can handle the proxy fine. Just wanted to ask if anybody knows if cgminer has already been pached for this to work correctly? |
|
|
|
|
I know that this has already been discussed before, but how do I disable rig with there is an active lease on the rig? Basically I don't want the rig to be rented anymore after the current lease. Is the only option to delete all renting plans? This is really annoying ...
If I click on "Disable minig rig" button, I get an warning "Unable to disable rig with active lease." and rig is still active. What are my options?
|
|
|
|
|
Coloring of listed pools in the "POOLS" tab: djeZo, currently you're coloring in light red the pool that is alive and active ... I don't like this, because red color usually means that something is wrong, stopped, etc. I suggest this:
color= light green for alive + currently active pool
color= white (neutral) for alive + currently non-active pools
color = light red for dead pools
|
|
|
|
djeZo, what are those ugly black circles/dots in the menus ... this really looks ugly ... well, just my 2 cents |
|
|
|
Hi, If anybody is looking for some additional hash power for mining UltraCoin: my rig is available for rent: UltraCoin Scrypt-Jane Nfmin=4 Nfmax=30 StartT=1388361600 professional mining rig My mining rigs are located in professional data center backup-ed with UPS, redundant internet links, enterprise monitoring etc. I also provide custom website with rigs status. Feel free to PM me on bitcointalk.org with any questions/concerns. CAVEMINER01 at http://leaserig.net/index.jsp?t=2Happy mining! |
|
|
|
|
Feature request: As a provider I would like to be able to disable a particular Rent plan. For example, I have plans for 72, 48, 24 and 12h, and I would like to temporarily disable the plans for 72 and 48h, thus leaving just 24 and 12 (because I wan't to temporarily avoid long-term leases - or vice-verse, avoid short-term leases) . I know I can just remove it and later re-add it, but this is rather annoying since I would like to keep my pricing intact. All you need to do is to add a check-box column "enabled" to renting plans .
|
|
|
|
UPDATE for providers - when you advertise your rigs around, you can display only your rigs by providing following URL: http://leaserig.net/index.jsp?fprovider=djeZo Replace djeZo with your own name. If your name contains spaces, insert %20 instead of space. Note: comparison IS CASE sensitive! This is clumsy and more or less useless ... I have to adjust the url each time I change my rig type and if I have rigs with different types, I need different URLs ... not good. Also, when my rigs are rented, the URL shows a page without my rigs (well, actually they are hidden) and lot's of data which is not related (or just partly related) to my rig (orders, lease history, etc.) What I would really need is a new page, where you would display ALL of my rigs, show nice green status icon if a particular rig is available and red if is not; also display a column with rig type ... So this really has to be a custom, nice view if I wan't to advertise it, otherwise it looks just clumsy and definitely not attractive for potential customers ... |
|
|
|
First: Do you see anything glaringly wrong with my order?
Order looks fine. Second: Is the price close to what you would expect? Less/More?
Speaking as a rig provider: not really. scrypt-jane produces about 75% hashpower comparing to regular scrypt (this is onyl on my very very short testing with quickquickcoin without any fine tuning) ... therefore price should be at least 25% more then regular scrpyt. Plus there are the issues with cgminer confuguration for scypt-jane ... beacuse each algo has it's own --Nfmin, --Nfmax, --StartT, rig provider has to do explicit configuration of cgminer for each separate algo ... that said I would say a price of 0.02 + 25% per/Mh/day with at least 48h rent time would become attractive. (p.s.: I can't provide you my rig because they are all rented, but someone else might do it) Third: (And I don't completely understand this) but since Scrypt\Jane has a hashrate that goes down over time - is this bid for normal scrypt hash? Or is it assuming the miner will be mining the bid amount of hash with the increased difficulty? (I hope that made sense).
Hashrate won't got down so fast ... not in the duration of a couple days lease |
|
|
|
The biggest issue for big providers is management, when swapping from one algo type to another, changing description text on multiple rigs, and changing prices. This is manageable if having <5 rigs, but painful when having more. But even in this direction, we are already working on a solution and will soon be published.
OK, here is a solution for all of you who have Linux rigs: So, basically I made a simple web page, actually a web wrapper to control my Linux based multi-mode rigs. This solution is only for Linux rigs (I guess the majority of serious rig providers are running some sort of Linux on the rigs anyway) and requires some Linux knowledge to properly set-up the environment. With this solution rig provider can control his rig's "mode" remotely solely with web browser. https://bitcointalk.org/index.php?topic=471867.new#new (see the video demos) |
|
|
|
Problem: I have multiple rigs and I often switch different cgminers to be able to mine coins based on various algorithms (regular scrypt, scrypt-adaptive-nfactor, keccak sha-3, etc). I also lease my rigs on LeaseRig and customers often requests to switch a particular rig or all of them to a particular algorithm. Solution: Make a simple back-end script and a simple web interface to be able to do all this with a single button click. Oh yeah, let the dreams come true! --- So, basically I made a simple web page, actually a web wrapper to control my Linux based multi-mode rigs. This solution is only for Linux rigs (I guess the majority of serious rig providers are running some sort of Linux on the rigs anyway) and requires some Linux knowledge to properly set-up the environment. With this solution rig provider can control his rig's "mode" remotely solely with web browser. The system consist of one shell script that handles cgminer "mode" via screen sessions and one php web page to control rig's "mode" - this php web page basically just calls the underlying shell script. Apache or some other webserver must be running on the rig (just basic install of apache is good out of the box with defaults). To be able to support Windows rigs one would have to write some kind of whatever script/app to be able to start/stop different cgminers (different forks of cgminers) in windows - I have no idea how to do this; but one could re-use the php web app on Windows rigs as well. See demo video. This video shows how this script is stopping one cgminer and switches to another cgminer or vertminer or whatever. Keep in mind that this script switches cgminer and also (optionally) changes all the needed config at LeaseRig (see also the other demo below): Video DEMO: http://files.kobal.org/caveminers/cgminer_switcher_demo.m4vFurther more, I made another php wrapper that enables me to switch mode for all my rigs at once, just with a single button ... this one actually just submits proper POST data to each rig's php web wrapper, see the demo here (this demo doesn't show cgminer, but cgminer is switching in the background just as it is on the previous demo): Video DEMO: http://files.kobal.org/caveminers/cgminer_multi_switcher_demo.m4v--- Things to keep in mind: - currently only Linux rigs are supported- this let's you change rig's cgminer instance as well as LeaseRig rig's configuration (type, speed, description, pools)--- These scripts are in beta development. I'm not responsible for any kind of issues due to cgminer failures or errors! USE AT YOUR OWN RISK!But if you like it, consider dropping a few mBTC to 1LfFJV321RKeUmhRAf9T5VXKreX7Zdm4y7 ... Thanks! --- Quick (and dirty) how to (repeat this steps on each of your rigs): http://files.kobal.org/caveminers/cgminer_switcher_README.txtget the shell script here: http://files.kobal.org/caveminers/cgminer_switcher.sh.tar.gzget the web scripts here: http://files.kobal.org/caveminers/cgminer_switcher_php.tar.gz--- btw: here you can grab some Linux compiled versions of cgminer (and it's forks): http://files.kobal.org/cgminer/cgminer-3.7.2-kalroth-20140204-LINUX.tar.gzhttp://files.kobal.org/cgminer/cgminer-3.7.3-kalroth-keccak-LINUX.tar.gzhttp://files.kobal.org/cgminer/cgminer-vertminer-gpu-LINUX.tar.gz |
|
|
|
|
Show Posts
