Any information when it will be possible to specify more then one backup pool (so more then 2 pools in total)?

API needed!

I'm a provider of mining rigs (leaser) and I have lot's of them. Therefore I wan't to control them programmatically, via API. For now the most desired request would be the ability to easily mark one rig as disabled/enabled and to get the current status of a particular rig [leased/available/disabled].

So I would like to have a simple API command that I would call, for example, with my API ID, my rig ID and "action".

Current needed actions are:
- enable/disable rig
- get the status of a rig [leased/available/disabled]

With this kind of API I could run my own "lease checker script" and I would have instant access of the status for all of my rigs and the ability to programmatically disable/enable my rig. This kind of functionality is especially useful if I offer my rigs at multiple rent&hire portals/services (RENTAMININGRIG.COM, leaserig.net, betarigs.com, etc). Because if one has many rigs (dozens of them) it is more likely to be able to get them all rented if one has them listed on more then one rent&hire portals/services.

If I would have this kind of API then I could disable a particular rig on other rent&hire portals/services as soon as I detect that it has been rented by someone on a particular rent&hire portal.

rmindel, could you add this?

API needed!

I'm a provider of mining rigs (leaser) and I have lot's of them. Therefore I wan't to control them programmatically, via API. For now the most desired request would be the ability to easily mark one rig as disabled/enabled and to get the current status of a particular rig [leased/available/disabled].

So I would like to have a simple API command that I would call, for example, with my API ID, my rig ID and "action".

Current need actions are:
- enable/disable rig
- get the status of a rig [leased/available/disabled]

With this kind of API I could run my own "lease checker script" and I would have instant access of the status for all of my rigs and the ability to programmatically disable/enable my rig. This kind of functionality is especially useful if I offer my rigs at multiple rent&hire portals/services (leaserig.net, betarigs.com, etc). Because if one has many rigs (dozens of them) it is more likely to be able to get them all rented if one has them listed on more then one rent&hire portals/services.

If I would have this kind of API then I could disable a particular rig on other rent&hire portals/services as soon as I detect that it has been rented by someone on a particular rent&hire portal.

mux, could you add this?

API needed!

I'm a provider of mining rigs (leaser) and I have lot's of them. Therefore I wan't to control them programmatically, via API. For now the most desired request would be the ability to easily mark one rig as disabled/enabled and to get the current status of a particular rig [leased/available/disabled].

So I would like to have a simple API command that I would call, for example, with my API ID, my rig ID and "action".

Current need actions are:
- enable/disable rig
- get the status of a rig [leased/available/disabled]

With this kind of API I could run my own "lease checker script" and I would have instant access of the status for all of my rigs and the ability to programmatically disable/enable my rig. This kind of functionality is especially useful if I offer my rigs at multiple rent&hire portals/services (leaserig.net, betarigs.com, etc). Because if one has many rigs (dozens of them) it is more likely to be able to get them all rented if one has them listed on more then one rent&hire portals/services.

If I would have this kind of API then I could disable a particular rig on other rent&hire portals/services as soon as I detect that it has been rented by someone on a particular rent&hire portal.

djeZo, could you add this?

Short notice for advanced API configuration with various restrictive permissions. In my case I want localhost (the rig itself) to have full permissions, remote monitoring system only read permissions and LEASERIG.NET only the permissions that are needed for LEASERIG.NET to work properly. One can achieve this with:

(LEASERIG.NET group permission)
"api-groups" : "L:switchpool:addpool:removepool:restart:save:*",

(W is special privileged access to commands that modify cgminer, thus all API commands)
(192.168.2.70 is my monitoring server with only default read access)
"api-allow" : "W:127.0.0.1,192.168.2.70,L:89.212.242.33",

willapl, have you rented my rigs on betarigs or leaserig? Please, send me a PM so that we can look into the issue.

Strange. It is properly configured and it up&running. I'll contact betarig support and I also sent you a PM with details.

Here you can post your feedback on doing any kind of business with me.

Sell & Buy hash power: NiceHash.com

Happy & Nice mining!

I have the same issue. I have five 7950 Club3D and four of them are playing nicely with g=2, xI=4, threads=8192 @670kh/s, however one of them just hangs after a couple of minutes so I have to use g=1, xI=300, threads=24000 @650kh/s

Quick question regarding pricing. And please, I would like to get some answers from actual users, who are renting their rigs and have already received payments.

Let me get this straight. Let's say I have a rig with a constant 5 Mh/s mining power. And I rent it for 0.02 BTC/MH/day. Somebody rent's it and uses is for one whole day (24h). So I will get

0.02 * 5 = 0.1 - 2% = 0.098 - 0.0001 tx = 0.0979 BTC

Is that correct? I would appreciate if someone who has actually been paid can confirm this.

BTW: Can I set the minimum amount of hours for rent, for example, 24h, so that my ring can't be rented for less then 24h? I see that Max lease time is currently 24 hours - so after 24 hours I have to wait for another user to rent my rig and meanwhile my rig can mine at my own pools?

Strange. Andoid App says "Internet connection is not available." when doing refresh. I tried to switch to Mobile data from WiFi and then it works. Google Chrome browser on my PC returnes "No data received" (on WiFi), however if I look at the source I can see the source of the webpage being displayed. Then I checked on my other remote computer, connected to antoher ISP and it works fine. Maybe is there something in the webpage or in the communication between Andoroid App and the server that my ISP doesn't like? Maybe there are just temporarily issues with my ISP. Anyway, email alerts works.

Are you currently having some issues on the server?

Overnight one of my GPU's went SICK and I got 50 e-mail messages from Middlecoin Monitor in a couple of hours ... You must implement retention policy:
- when you detect an alert, you mark the user as "in-alert" and you mark the time when the alert went to the user via email
- at the next checkpoint after 5 minutes you check (if current status is still "in-alert") AND (if the user still has to low hashrate) AND (time diff from previous e-mail is less the 2 hours) THEN you don't do nothing; only IF it's > 2 hours you send e-mail again ... and after 2 hours again ...
- when the user has back the normal hashrate you must send another type of alert "hashrate now OK", so the user is notified that everything is OK now

The logic must be similar as the one in the Nagios monitoring system notification: http://nagios.sourceforge.net/docs/3_0/notifications.html

If I change the Mh/s threshold for alert in the Android App, will this change also be synchronized to the email alerting system (and vice-versa)?

Thanks aTriz; BTC welcome at 1LfFJV321RKeUmhRAf9T5VXKreX7Zdm4y7

BTW: if you wan't to mine with pace, here are some usefull monitoring tools for cgminer:

- Nice monitoring tool for local monitoring of your miners (Linux): https://github.com/selaux/miner-dashboard
- Cacti monitoring integration with trully awesome cgminer templates: https://bitcointalk.org/index.php?topic=76502.0
- My own Nagios monitoring integration with some Nagios NRPE plugins: http://files.kobal.org/cgminer/cgminer_nagios_nrpe_checks.zip (check if current hashrate is above treshold and if all GPU's temepratures all below treshold)
- Windows monitoring tool: CGWatcher - a GUI/monitor for CGMiner and BFGMiner: http://manotechnology.blogspot.com/p/cgwatcher.html
- Windows monitoring tool: CGRemote, a remote dashboard for CGMiner and BFGMiner: http://manotechnology.blogspot.com/p/cgremote.html

To mitigate te disconnects on coin-switches you can definitely do at least these two things (besides the already mentioned --failover-only):

1. use sgminer: https://github.com/veox/sgminer or Martin "Kalroth" Danielsen's personal cgminer 3.7.2 build, you can find it here: http://k-dev.net/cgminer/. They include patches for resilience against pool disconnect with frequent coin switching as well as several other improvements (see http://k-dev.net/cgminer/kalroth-changes.txt)

2. Set appropriate values for scan-time and expiry:
--scan-time|-s <arg> Upper bound on time spent scanning current work, in seconds (default: 60)
--expiry|-E <arg> Upper bound on how many seconds after getting work we consider a share from it stale (default: 120)

A good in-the-middle values are:

"scan-time" : "15",
"expiry" : "15",

And even some more aggressive:

"queue" : "5",
"scan-time" : "1",
"expiry" : "1",

BTW: to decrease rejects, you should decrease Intensity. High intensity will hurt low-difficulty altcoins. Go for 13 with dual-thread GPU's (7970, 7990, R9 280) and with 18 with single thread GPU's. Or even beter, use xIntensity with  Martin "Kalroth" Danielsen's personal cgminer 3.7.2 build at a level of xIntensity = 144.

edit: hashcows definitely needs a secondary stratum server ... you can't run a serious pool with just one stratum server

edit: A bit of explanation for "failover-only":
--failover-only: Don't leak work to backup pools when primary pool is lagging
The normal failover mechanism in cgminer will allow some work to go to the backup pools if there is a delay in getting work from the primary pool you have set. This can be as much as 10% if the pool has latency issues. It then only fails to the backup pool if the primary pool stops giving work for 1 minute. failover-only does not change the failover mechanism, but it does not allow work to go to the backup pools unless the primary pool has failed completely for at least a minute. It then will switch to the backup pool. If cgminer considers a pool dead or down, it tries to contact that pool 1 minutely.

Q: Work keeps going to my backup pool even though my primary pool hasn't failed?
A: Cgminer checks for conditions where the primary pool is lagging and will pass some work to the backup servers under those conditions. The reason for doing this is to try its absolute best to keep the GPUs working on something useful and not risk idle periods. You can disable this behaviour with the option --failover-only.

FYI: I've updated my FAQ with cgminer configurations and hints for lowering reject rate:

http://middlecoin.kobal.org/index.php/Main_Page#cgminer_configurations.2C_lowering_reject_rate

Take it easy ... that's the way this pool runs ... information is basically community driven and you can find many info and personal stats here: http://middlecoin.kobal.org

For all of you who are looking for statistics and current status of your miners: if the official stats are stalled/broken you can always check the many third-parity web pages which are parsing JSON data and displaying many usefull graphs, see: http://middlecoin.kobal.org/index.php/Main_Page#Where_can_I_see_my_statistics.3F

Hi,

I'm seeking for experts on cgminer WU.

So, the cgminer WU is the Work Utility defined as the number of diff1 shares work / minute (accepted or rejected).

Please, correct me if I'm wrong. To get the most of my miner, I should optimize my miner to get the highest possible WU (because this is what is actually committed to the pool and thus makes money). In some cases you can get more WU with actually lower hash rates on GPUs. There are different approaches to accomplish this (decreasing intensity, increase/decrease thread concurrency).

Now, to my example: I have miner with 4x XFX R9 290 (all the same, all with the same settings 1015/1500/20481), resulting like this (running for 15 hours):

(5s):3.493M (avg):3.487Mh/s | A:2235392  R:48128  HW:0  WU:3097.8/m

GPU 0:  77.0C 5150RPM | 872.0K/872.6Kh/s | R:  3.0% HW:0 WU:747.8/m T:1 I:19
GPU 1:  80.0C 5250RPM | 873.2K/871.9Kh/s | R:  2.3% HW:0 WU:805.2/m T:1 I:19
GPU 2:  75.0C 5153RPM | 873.2K/871.8Kh/s | R:  3.0% HW:0 WU:736.3/m T:1 I:19
GPU 3:  77.0C 5171RPM | 872.9K/871.9Kh/s | R:  0.3% HW:0 WU:805.4/m T:1 I:19

So, the average WU / hashrate for the whole miner is 3097.8 / 3.487 = 88,8%

However, each card has a very different WU / hashrate:

GPU 0:  85,8%
GPU 1:  92,2%
GPU 2:  84,3%
GPU 3:  92,3%

I know that the WU is dependent on luck finding valid shares on each GPU, but this should stabilize in time. Now, why are there such differences between the cards? Are you experiencing the same thing? Is there any general rule to get the same WU on all cards? Any hints on optimizations to get the highest possible WU?

Thank you!