[ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More

[ku4eto]

NOTE: This miner does NOT monitor GPU temperatures.
      It is up to the user to ensure that GPU(s) are functioning within safe power and temperature limits.

API: The miner includes a read-only api based on the sgminer-5.5 API.
Both the json and text formats are supported. For more details, we refer to the sgminer api documentation.

Seems like there are changes on what is transmitted over the API, can you give more information about it?

Also, there is an issue, when mining Graft for example, which is a CNv8 coin as well.

Code:

[2018-11-02 16:59:23] Pool graft.ingest.cryptoknight.cc share rejected. (GPU3) Error code: -1 - Wrong algo, use monero7 miner (432/430/2)

When checking the Pool side, it reports hash rate as if 3 cards are mining, not 4. On CNv7, i have used XMR-Stak to mine Graft with

Code:

monero7

flag, since it seemed that they have the same metadata information.

anybody with hasrates for 470 and / or 570 4GB?

Naturally it’d be better for other forum members to provide their verified hashrates, but fwiw the 470/570 4GBs in our tests often reached the 1000+ h/s mark, many times a tad more. Some were stuck at ~850 h/s for all miners. It depends on your core clk as well as mem clk. Power draw should still be fine with a higher core clk. The configs to use are 7+7 and 8+7. Higher won’t work.

Cheers,
K

ok..so not a big impact on v2 like on heavy (where 8GB is much better)

A 1280/1950 570 Gigabyte does  ~980h/s. Although, the core clock is probably useless, gotta try it lower.

[1713855306]

1713855306

[nordmann666]

anybody with hasrates for 470 and / or 570 4GB?

ASUS RX570 Expedition OC (modded Elpida bios) clocked at 1225/1940 yields just under 1kh/s. cn_config 7+7. 8+7 seems to be slower.

You've got to give it a go and see for yourself which config will work best, but the above is a pretty safe bet.

i need advice for buying cards 470 and 570 8GB is harder to get than 4GB

[h311m4n]

Any plans to support cryptonight-haven?

[kerney666]

Any plans to support cryptonight-haven?

We will roll out all variants incl the heavy family in due time. Just need to get to a stable point with the miner first, it’ll be a shitshow with support otherwise .

[Art Gar]

teamredminer v0.3.6 Beta Release
This is an optimized miner for AMD GPUs created by todxx and kerney666.

Features In Development:

• New Algorithms
• Temp and Fan Monitoring
• Pool Failover
• Colors

NIce job, guys! Waiting for the cn-heavy class and watchdog mechanism also.

[ku4eto]

Any plans to support cryptonight-haven?

We will roll out all variants incl the heavy family in due time. Just need to get to a stable point with the miner first, it’ll be a shitshow with support otherwise .

Please check my post on the start of this page.

Also, any intentions of implementing Share Discarding for Bad Shares (Invalid ones), instead of submitting them to the Pool?

[h311m4n]

Any plans to support cryptonight-haven?

We will roll out all variants incl the heavy family in due time. Just need to get to a stable point with the miner first, it’ll be a shitshow with support otherwise .

Cool thanks for the quick reply mate!

[kerney666]

Any plans to support cryptonight-haven?

We will roll out all variants incl the heavy family in due time. Just need to get to a stable point with the miner first, it’ll be a shitshow with support otherwise .

Please check my post on the start of this page.

Also, any intentions of implementing Share Discarding for Bad Shares (Invalid ones), instead of submitting them to the Pool?

I’ll reply within an hour, phone only right now, doing short replies only.

[fenomenyaa]

Still same problem on win10 18.5.1 rx470-480 series G4400 4Gb ram.All rigs stable on srb 1.6.8-9

Code:

   Team Red Miner version 0.3.6
[2018-11-02 19:47:02] Initializing GPU 0.
[2018-11-02 19:47:04] Pool xmr-eu1.nanopool.org login succeeded.
[2018-11-02 19:47:04] Pool xmr-eu1.nanopool.org received new job. (job_id: 1796)
[2018-11-02 19:47:04] Pool xmr-eu1.nanopool.org set difficulty to 120001
[2018-11-02 19:47:05] Dev pool connected and ready.
[2018-11-02 19:47:06] Initializing GPU 1.
[2018-11-02 19:47:09] Initializing GPU 2.
[2018-11-02 19:47:11] Initializing GPU 3.
[2018-11-02 19:47:15] Initializing GPU 4.
[2018-11-02 19:47:19] Initializing GPU 5.
[2018-11-02 19:47:22] Initializing GPU 6.
[2018-11-02 19:47:26] Successfully initialized GPU 0: Polaris with 36 CU (PCIe 07:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 1: Polaris with 32 CU (PCIe 05:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 2: Polaris with 36 CU (PCIe 03:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 3: Polaris with 32 CU (PCIe 02:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 4: Polaris with 32 CU (PCIe 01:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 5: Polaris with 32 CU (PCIe 09:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 6: Polaris with 32 CU (PCIe 08:00.0) (CN 7+7)
[2018-11-02 19:47:34] Stats GPU 0 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 1 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 2 - cnv8: 249.1 h/s, avg 836.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 3 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 4 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 5 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats Total - cnv8: 249.1 h/s, avg 836.0 h/s, pool   0.0 h/s
[2018-11-02 19:47:38] Pool xmr-eu1.nanopool.org received new job. (job_id: 1797)
[2018-11-02 19:48:01] Pool xmr-eu1.nanopool.org share accepted. (GPU2) (1/1/0)
[2018-11-02 19:48:04] Stats GPU 0 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Pool xmr-eu1.nanopool.org received new job. (job_id: 1798)
[2018-11-02 19:48:47] Stats GPU 1 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Stats GPU 2 - cnv8: 1.030kh/s, avg 431.9 h/s, pool 1.483kh/s 1/0
[2018-11-02 19:48:47] Stats GPU 3 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Stats GPU 4 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Stats GPU 5 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Stats Total - cnv8: 1.030kh/s, avg 431.9 h/s, pool 1.483kh/s
[2018-11-02 19:49:13] Pool xmr-eu1.nanopool.org received new job. (job_id: 1799)
[2018-11-02 19:49:17] Stats GPU 0 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats GPU 1 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats GPU 2 - cnv8: 377.3 h/s, avg 573.5 h/s, pool 1.082kh/s 1/0
[2018-11-02 19:49:17] Stats GPU 3 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats GPU 4 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats GPU 5 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats Total - cnv8: 377.3 h/s, avg 573.5 h/s, pool 1.082kh/s

[kerney666]

Seems like there are changes on what is transmitted over the API, can you give more information about it?

We haven't changed anything API-related per se, but maybe you're hitting this thing: there is a very confusing design aspect with the sgminer API that we just had to follow to be compatible. The json keys for e.g. avg hashrate last N secs change when you change the period between prints. We did change the default period from 60 secs to 30 secs at some point, so the API keys have changed as well. The proper (and annoying) way to do it is to first send a "config" command, check the reported "Log Interval" value there. That value, in our case "30" for 30 secs, will then be used in the keys for all other messages, for example the "summary" command will return the key ""KHS 30s". Imho it's an idiotic design, but we had to follow it. We have a command line option for changing the period. If there's anything else you're noticing, let me know.

Also, there is an issue, when mining Graft for example, which is a CNv8 coin as well.

Code:

[2018-11-02 16:59:23] Pool graft.ingest.cryptoknight.cc share rejected. (GPU3) Error code: -1 - Wrong algo, use monero7 miner (432/430/2)

When checking the Pool side, it reports hash rate as if 3 cards are mining, not 4. On CNv7, i have used XMR-Stak to mine Graft with

Code:

monero7

flag, since it seemed that they have the same metadata information.

This looks very strange. We only have one pool connection that is shared by all cards, and the shares we submit are for sure CNv8. I'm guessing the pool might not have updated their error message after the fork? Moreover, in your printout above you have 0.46% rejected shares though, nothing out of the ordinary. I tried the same pool now, no problem for my 550/580/Vega 64 test workstation. In the reported stats every 30 secs, are all four cards hashing ok?

[ut9fj]

Hello.
All RIG with poolin.com connect.

          Team Red Miner version 0.3.6
[2018-11-02 18:59:20] Auto-detected AMD OpenCL platform 1
[2018-11-02 18:59:20] Initializing GPU 0.
[2018-11-02 18:59:23] Pool xmr.ss.poolin.com failed to parse server rpc: {"id":1,"jsonrpc":"2.0","result":{"id":"5c0002df","status":"OK","job":{"job_id":"5bdc826610bd4a5c00000000","blob":"0909e684f2de057f8683e8f3ce79c093d89f2fcbdc525b7c282d246fe2f2bfb89a636891143eb10 00000009fdae2def7822a0c34560b46dc32a0bf43f7fe10e1d31a735342559a8fca96d402","target":"ff0f0000"}}}
[2018-11-02 18:59:25] Initializing GPU 1.
[2018-11-02 18:59:29] Initializing GPU 2.
[2018-11-02 18:59:34] Initializing GPU 3.
[2018-11-02 18:59:39] Initializing GPU 4.
[2018-11-02 18:59:39] Pool xmr.ss.poolin.com failed to parse server rpc: {"id":1,"jsonrpc":"2.0","result":{"id":"650002d2","status":"OK","job":{"job_id":"5bdc827acd46b12f00000000","blob":"0909fa84f2de05a208f79644e6d2eb5fceb8c1759851f0f37eb0ccd58b1ee48648aa7f2d86220e0 00000008e6931dbf8e894a549b4abf37a153fb71c6b20bfc57b055bdd320f2194251b6401","target":"ff0f0000"}}}

[kerney666]

Hello.
All RIG with poolin.com connect.

          Team Red Miner version 0.3.6
[2018-11-02 18:59:20] Auto-detected AMD OpenCL platform 1
[2018-11-02 18:59:20] Initializing GPU 0.
[2018-11-02 18:59:23] Pool xmr.ss.poolin.com failed to parse server rpc: {"id":1,"jsonrpc":"2.0","result":{"id":"5c0002df","status":"OK","job":{"job_id":"5bdc826610bd4a5c00000000","blob":"0909e684f2de057f8683e8f3ce79c093d89f2fcbdc525b7c282d246fe2f2bfb89a636891143eb10 00000009fdae2def7822a0c34560b46dc32a0bf43f7fe10e1d31a735342559a8fca96d402","target":"ff0f0000"}}}
[2018-11-02 18:59:25] Initializing GPU 1.
[2018-11-02 18:59:29] Initializing GPU 2.
[2018-11-02 18:59:34] Initializing GPU 3.
[2018-11-02 18:59:39] Initializing GPU 4.
[2018-11-02 18:59:39] Pool xmr.ss.poolin.com failed to parse server rpc: {"id":1,"jsonrpc":"2.0","result":{"id":"650002d2","status":"OK","job":{"job_id":"5bdc827acd46b12f00000000","blob":"0909fa84f2de05a208f79644e6d2eb5fceb8c1759851f0f37eb0ccd58b1ee48648aa7f2d86220e0 00000008e6931dbf8e894a549b4abf37a153fb71c6b20bfc57b055bdd320f2194251b6401","target":"ff0f0000"}}}

Ok, something unexpected with the stratum messages going on here. Todxx will take a look at this when he's available. You'll get an update later today.

[kerney666]

Still same problem on win10 18.5.1 rx470-480 series G4400 4Gb ram.All rigs stable on srb 1.6.8-9

Gah this is annoying. It doesn't feel like the init problem we've been battling though. Do you have all the standard environment vars set when running the miner? Srb typically sets them with "setx" in the start bat file, so they should be persistent if you run srb as well. I mean these:

set GPU_MAX_HEAP_SIZE=100
set GPU_MAX_USE_SYNC_OBJECTS=1
set GPU_SINGLE_ALLOC_PERCENT=100
set GPU_MAX_ALLOC_PERCENT=100
set GPU_MAX_SINGLE_ALLOC_PERCENT=100

We should really include them in our example start bat file, that's a mistake. Last, if you run with something silly like 2+2 for all cards, does it work or not?

To speed up this process, would you be willing to hook up on Discord or Telegram? So much easier when you can ping-pong questions in realtime rather than this thread .

[petunder]

Is nicehash supported? 

[joseph32]

Is nicehash supported? 

Sure, Nicehash works.

[ku4eto]

Seems like there are changes on what is transmitted over the API, can you give more information about it?

We haven't changed anything API-related per se, but maybe you're hitting this thing: there is a very confusing design aspect with the sgminer API that we just had to follow to be compatible. The json keys for e.g. avg hashrate last N secs change when you change the period between prints. We did change the default period from 60 secs to 30 secs at some point, so the API keys have changed as well. The proper (and annoying) way to do it is to first send a "config" command, check the reported "Log Interval" value there. That value, in our case "30" for 30 secs, will then be used in the keys for all other messages, for example the "summary" command will return the key ""KHS 30s". Imho it's an idiotic design, but we had to follow it. We have a command line option for changing the period. If there's anything else you're noticing, let me know.

Also, there is an issue, when mining Graft for example, which is a CNv8 coin as well.

Code:

[2018-11-02 16:59:23] Pool graft.ingest.cryptoknight.cc share rejected. (GPU3) Error code: -1 - Wrong algo, use monero7 miner (432/430/2)

When checking the Pool side, it reports hash rate as if 3 cards are mining, not 4. On CNv7, i have used XMR-Stak to mine Graft with

Code:

monero7

flag, since it seemed that they have the same metadata information.

This looks very strange. We only have one pool connection that is shared by all cards, and the shares we submit are for sure CNv8. I'm guessing the pool might not have updated their error message after the fork? Moreover, in your printout above you have 0.46% rejected shares though, nothing out of the ordinary. I tried the same pool now, no problem for my 550/580/Vega 64 test workstation. In the reported stats every 30 secs, are all four cards hashing ok?

I checked with them, seems like you are correct, they have not changed the error message. The rejected shares are due to crappy card quality, not playing nice with the strap. Another thing that i seem to notice is, XMR-Stak was discarding Invalid shares, but logging them regardless, which were equivalent to Hardware Error (HW). But on this fork, instead of being HW, its a Rejected share. I have used the sgminer-gm-5.5.5, and it was doing HWs, instead of rejected shares. Pretty confusing.

I will be checking for the 30/60s stuff for the API.

[kerney666]

I checked with them, seems like you are correct, they have not changed the error message. The rejected shares are due to crappy card quality, not playing nice with the strap. Another thing that i seem to notice is, XMR-Stak was discarding Invalid shares, but logging them regardless, which were equivalent to Hardware Error (HW). But on this fork, instead of being HW, its a Rejected share. I have used the sgminer-gm-5.5.5, and it was doing HWs, instead of rejected shares. Pretty confusing.

I will be checking for the 30/60s stuff for the API.

Thanks for reporting back! In the current version our miner doesn't have cpu verification of the hashes, probably the only one that doesn't. We just send everything to the pool and let them check the shares. We're just about to add the cpu verification parts though, so when that's in place we will be reporting bad shares as "HW errors" as well and not piss of the pool(s) when you push your mem straps too hard .

[kerney666]

Is nicehash supported? 

Sure, Nicehash works.

Like joseph32 writes, it is supported. However, I'm not a big fan of Nicehash in the CN world. We need to support it though since it's the same mechanism that proxies like xmrig-proxy use as well.

Modifying a reply I wrote earlier today in our other ann thread that explains why it's a bad idea imho:

NiceHash mining is a little problematic with CN. Calculating a round of hashes for CN takes > 1 sec, which is a very long processing time. For other hash functions numbers in a few ms are more common. So, CN has a much higher probability of your hashes being stale when the gpu job completes. The more often your pool/NiceHash sends out new jobs, the higher the probability that calculated shares belong to a stale job. For e.g. direct XMR mining (a coin with 2 min block time), pools are generally nice about accepting shares for both the current and the previous pool job as long as the new job wasn't sent out as a reaction to a new network block. The more common reason for a new job is just an ntime roll forward in time. In that case, the shares you submit for the previous job are still possible to convert into a network block, so pools should really accept them. With a 2 min block time, these type of new jobs will be sent out (on average) every 2 mins. Given this, we can expect to have maybe between 0.5-1% rejected shares over time. Some pools accept shares for stale jobs anyway to be nice.

For NiceHash, this just isn’t true. They can throw you around between client orders every 5 secs and generally seem to be more picky with stale shares. Using the same style of mining as for normal pools, you will see a much higher reject ratio. They have pushed the cost of the long CN calculation period for gpus onto miners. Clients only pay for accepted shares. CPU miners will be fine though. One approach to dealing with NiceHash is an abort mechanism, i.e. as soon as a new job comes in you abort any ongoing calculations and restart with the new job instead. However, this means that the last ~0.5 secs of gpu time (on avg) will be wasted for every job switch. The more often new jobs are sent out, the more gpu time you will waste, so it’s not 100% sure you’ll be better off with this approach anyway.

In the end, maybe NiceHash will give you a higher return anyway due to an implicit profit switching between CNv8 coins, but when using this miner in its current form, you will lose a few pcts of hashrate in rejected shares.

[peterboy1]

Is nicehash supported? 

Sure, Nicehash works.

Like joseph32 writes, it is supported. However, I'm not a big fan of Nicehash in the CN world. We need to support it though since it's the same mechanism that proxies like xmrig-proxy use as well.

Modifying a reply I wrote earlier today in our other ann thread that explains why it's a bad idea imho:

NiceHash mining is a little problematic with CN. Calculating a round of hashes for CN takes > 1 sec, which is a very long processing time. For other hash functions numbers in a few ms are more common. So, CN has a much higher probability of your hashes being stale when the gpu job completes. The more often your pool/NiceHash sends out new jobs, the higher the probability that calculated shares belong to a stale job. For e.g. direct XMR mining (a coin with 2 min block time), pools are generally nice about accepting shares for both the current and the previous pool job as long as the new job wasn't sent out as a reaction to a new network block. The more common reason for a new job is just an ntime roll forward in time. In that case, the shares you submit for the previous job are still possible to convert into a network block, so pools should really accept them. With a 2 min block time, these type of new jobs will be sent out (on average) every 2 mins. Given this, we can expect to have maybe between 0.5-1% rejected shares over time. Some pools accept shares for stale jobs anyway to be nice.

For NiceHash, this just isn’t true. They can throw you around between client orders every 5 secs and generally seem to be more picky with stale shares. Using the same style of mining as for normal pools, you will see a much higher reject ratio. They have pushed the cost of the long CN calculation period for gpus onto miners. Clients only pay for accepted shares. CPU miners will be fine though. One approach to dealing with NiceHash is an abort mechanism, i.e. as soon as a new job comes in you abort any ongoing calculations and restart with the new job instead. However, this means that the last ~0.5 secs of gpu time (on avg) will be wasted for every job switch. The more often new jobs are sent out, the more gpu time you will waste, so it’s not 100% sure you’ll be better off with this approach anyway.

In the end, maybe NiceHash will give you a higher return anyway due to an implicit profit switching between CNv8 coins, but when using this miner in its current form, you will lose a few pcts of hashrate in rejected shares.

wow crystal

[kerney666]

Hey pbfarmer! Thank you for the elaborate tests and detailed descriptions, much appreciated!

When running at lower clocks around 1407, the 15+15 configuration have been clearly superior to 16+14 in our tests as well, so your results are well aligned with our own testing.

Replying to the noted concerns/feedback below:

Some sort of 'resource release' process at shutdown would be useful.  It seemed if the miner was started too soon after it was stopped, the entire machine froze up.  Also, in general, the crash behavior of this miner is much less forgiving than others - most crashes meant a full reboot.

Absolutely agree. We're sloppy at shutdown, and it will be addressed shortly. We need to add proper signal handlers that works for both Linux and Windows and catch the ctrl-c/sighup signals, then do a proper release of all OpenCL resources.

This may just be the cost of mining cnv2, but power transients are huge.  On other miners, i saw regular 30-40W spikes from the median (w/ similar drops,) but for TR, i'm seeing 70W+ spikes, causing your mean and median to significantly diverge.  Specifically, while the observed median (2 GPUs, excluding idle) was around 285-290W, regular spikes up to 360W+ resulted in a mean draw around 310W.  Any way to get these down?  I could see these causing stability issues or tripped circuit protections for some people.

This is a very good point, and we've noted it ourselves, both when designing the kernels and by direct at-the-wall measurements. The issue stems from this miner requiring less power in the long-running main part of CN compared to others, but it also goes full throttle in other parts, requiring more power. Hence, the min-to-max power swings are amplified at both ends. Any CN miner with the same profile as this one that executes the algo in the most straightforward way would exhibit this problem.

We're also seeing a notable difference in stability on the Vega 64s vs 56s. I believe this is part of the problem. The fewer CUs means there will be additional pressure on 8-16 of the 56 CUs compared to the 64s as these spikes occur, a little bit depending on your CN config though.

There are a few ways of addressing this, and if we want to achieve max stability I believe we need to solve it. I have a very good design for solving it, but it's a big redesign and rewrite. We will get there at some point. Meanwhile, we're debating simpler forms of reducing the effect of the spikes, like cutting the worst case scenario in half. We'll go to work shortly on this.

Any possibility of incorporating a simple HTTP/REST report mechanism in addition to the cgminer rpc api (like stak, cast, srb, jce.)  It could just dump the current rpc api summary json, and it would be much more useful for quick setup/tuning, esp if you're only incorporating summary reports and not miner controls.

Yep, we're aware that the cgminer/sgminer api isn't really the CN standard, and we have some plans. We've worked hard to keep the miner itself free from any open source dependencies, we've written every single line of code from scratch. For example, that's we're missing on-cpu verification for CN in these first versions, we refuse to steal any code from xmrig, xmr-stak or even the XMR wallet. We'd like to have it clean from attributions.

Given the above, we won't pull in e.g. lighttpd as a dependency in the miner. My plan is rather to implement a separate project that we open source, a little http adapter in C++/node.js/python/whatever that converts the cgminer/sgminer api to an xmr stak-like HTTP/REST api. It will also have the nice feature of working with any sgminer-derived miner, not just our miner. I don't get the point of these massive monolith miner implementations, it would be so much nicer if we would have separated these different concerns a long time ago in the miner dev world so everyone could focus on what really matterns, the kernels and mining process. You can also separate some of the watchdog aspects and place them outside of the miner. Never really a good idea to run a watchdog thread inside the same process it's supposed to monitor.

So, it's also on the TODO list, we'll see when we get there. Time is always the limiting factor . If anyone in the community wants to get involved, give me a ping.