### A ChainWorks Industries (CWI) Project - CWIgm | Simple Powerful Stable

[chrysophylax]

I will write this just. It might be a small bug i seen.

When i started miner several times and after restart also, it always initialized only 2x GPU from 7. 7 were shown in device manager and in after burner, but when i started miner only gpu 2 and 6 shown hashrate, rest were stuck on 0.


Then i cancled miner for 5th time, went alt tab to do something, tried run miner again and it worked. Dunno why it didnt recognized my GPU-s right away.


This is my .bat file:


setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
cwigm -c sigt -u Brucelats.Zotacx7_SIGT -p x --cpu-priority=3 -i 22 --tlimit=65,65,65,65,65,65,65
pause


I used exact same on my other rigs with 5 6 7 GPU-s, only changed temp limits a bit and worker name and they all worked. Only thing that is speciffic to this rig that had problems is, it had all the same GPU-s and that are Zotac GTX 1070 AMP! Extreme. Rest have mix, or at least 1 card is different. Cheers!

first - remove all the setx environment parameters ...

they are really only used for sgminer / amd settings ...

cuda settings are usually set within the environment when you install the nvidia driver - and there is no need to set those environment parameter for nvidia cards ... you will see the same hashrate and results when you remove them ...

second - why --tlimit? ...

CWIgm is a unique miner ... try without that parameter and restart ...

you may want to try adding --lodiff to access the lower difficulty port also ... at least test it -until the port changes take place ( if they take place ) ...

let us know that all goes ...

#crysx

[1715621401]

1715621401

[1715621401]

1715621401

[pr0ximus]

Hey Crysx,

Thanks for accepting me to the beta test.

Before I start with my observations, let me post my setup.

I tested for SIGT with 6x Zotac GTX 1060 6GB Amp! Edition with pow:75%, CC:+175, MC: -400 and fan: 45%

And for the batch, I just changed to my pool login creds. leaving everything undisturbed. Intensity is auto assigned to 24 by the miner app.

The result bottom line: By far, this is the best miner I used for SIGT. With minor improvements, this could rule else all in the market.

Stats:
--------
1) It yields around 117-118 (with around 19+MH/s on each) consistently with the above setup. Though I wouldn't agree about the efficiency yet (which I will speak in the next point), it runs pretty stable with this setup for hours (or close to a day max on my test).

2) Starts of with more shares at low diff and as the diff increases, the time taken to find shares increase as well. Though this is natural, I see the rig waiting for 7-8 minutes to find 1 share which I felt was little longer. However, I see you already replied with your proposition of a solution of lowering the diff for both lowdiff and highdiff. This seems to be a good Idea. But I really could not figure out if 6x 1060 should be a low diff or high diff. This may sound navie but believe me, there would be many who'd be wondering what they want to use. A clarity (or an example may be in the read me) on up to what could be considered low diff and high diff would reduce the pressure on the pool and would also help solve blocks better. Please go ahead with proposed diff setup.

3) Although stable at some good OCs, it still crashes may be like after some hours, I don't have any watchdog implemented to watch my rig. So if something happens in the night while I sleep, I would be loosing some golden hours (which happened 2-3 times). effective implementation of a watchdog that understands while something goes wrong (in terms of GPU crash, miner errors, connectivity issues to the pool, etc.) and restarts the miner/system would be an amazing addition.

4) It starts with 1 or 2 GPUs at the start but takes plenty of time to get the remaining cards loaded and running. Is that designed that way to avoid crash?

[EDIT] 5) The power see-saw thing - I too happened to see (I left it to the miner app to decide but tuned AB to the above settings). I read your comment on another reply which states "the miner itself tries to create the 'perfect' scenario for mining IF you have those settings active ... take them off - and you will see that there will be a constant regular power consumption and mining", firstly, I don't have any temp setting in the miner and I have the see-saw power issues too. it would be great if you could let us know how to take them off. And if we take them off, would it affect the monitoring? whats the trade-off doing so?


I understand this is how beta works and I believe, it will improve from what it already is. I am continuing my miners in your pool with 0.9.8 at the moment . Unlike some greedy devs (I think you will understand whom I refer to. You name it ), it's good to see that very few devs like you doesn't be greedy with the knowledge but trying to give something back to the community (with minimal fee/donation which IS still necessary to get your R&D labs to a better place which could help you with better test cases there by yielding a better miner, a win win). Good luck to more releases to come.

PS: I would like to know your view on the panic happening with SIGT at the moment.

[cryptoinvestor_x]

I agree with the separate ports having different difficulties.

Implement the change and I will post results.

[deepWebRun]

Wanted to publicly thank the developers for beta access.

Love the graphical interface. Estimated coins/day is nice addition!  Added to that - nice and stable hashrate increase for Sigt across all rigs.
And the pool is actually much more responsive than supernova where I mined before.

[lentyna]

I'm running the miner (latest version) but I don't see it on the pool (http://pool.chainworksindustries.com/). My pool hashrate shows 0, I have a worker and it is configured to run on that worker.

Any idea why?

[lentyna]

My bat file:

Code:

timeout \t 5

cwigm -c sigt -u username.Miner03 -p x --lodiff --max-temp=75

pause

[saul.goodman]

Quick response after a few hours on sigt.

WIN 7                       
                        VC++ 2013 and CUDA 8.0 x64 384.76
CPU:1.09%          ChainWorks Industries beta - Version 0.9.8         [21:31:22]
--------------------------------------------------------------------------------
Algo:Skunk      | Port: 2000 | NetDiff: 24705.8            | Block:      35315 |
--------------------------------------------------------------------------------
Coin:signatum   | POW: 1250  | Estimated coins/day: 155.112                    |
--------------------------------------------------------------------------------
Solved:   0 | Diff:     1.24 | Shares: 285.81  | Rej: 0.608569% | Speed:  112.64
--------------------------------------------------------------------------------
0.EVGA GTX 1060 6GB          : Shares: 38.55   | Rej: 0    | Speed:   19.57MH/s|
1.Gigabyte GTX 1060 3GB      : Shares: 38.03   | Rej: 1.12 | Speed:   18.37MH/s|
2.GeForce GTX 1060 3GB       : Shares: 43.35   | Rej: 0    | Speed:   17.30MH/s|
3.EVGA GTX 1060 3GB          : Shares: 64.15   | Rej: 0.63 | Speed:   18.81MH/s|
4.Gigabyte GTX 1060 3GB      : Shares: 51.92   | Rej: 0    | Speed:   18.36MH/s|
5.MSI GTX 1060 6GB           : Shares: 49.81   | Rej: 0    | Speed:   20.06MH/s|
--------------------------------------------------------------------------------
0.EVGA GTX 1060 6GB          : T:79C | F:76% | P: 98W | I: 24.0 | Core:1924Mhz |
1.Gigabyte GTX 1060 3GB      : T:67C | F:72% | P:102W | I: 24.0 | Core:1978Mhz |
2.GeForce GTX 1060 3GB       : T:79C | F:78% | P: 98W | I: 24.0 | Core:1869Mhz |
3.EVGA GTX 1060 3GB          : T:60C | F:63% | P: 91W | I: 24.0 | Core:2018Mhz |
4.Gigabyte GTX 1060 3GB      : T:70C | F:75% | P:101W | I: 24.0 | Core:1980Mhz |
5.MSI GTX 1060 6GB           : T:72C | F:73% | P:106W | I: 24.0 | Core:1935Mhz |


Sp5 108MH/s
krnlx 110MH/s -20% on suprnova



------------------------------------------------------------------------------------------------------

WIN 10
                       VC++ 2013 and CUDA 8.0 x64 384.94
CPU:   0%          ChainWorks Industries beta - Version 0.9.8         [21:33:49]
--------------------------------------------------------------------------------
Algo:Skunk      | Port: 2000 | NetDiff: 21098.5            | Block:      35316 |
--------------------------------------------------------------------------------
Coin:signatum   | POW: 1250  | Estimated coins/day: 24.0661                    |
--------------------------------------------------------------------------------
Solved:   0 | Diff:     0.56 | Shares: 49.35   | Rej: 1.3986% | Speed:   18.31MH
--------------------------------------------------------------------------------
0.Zotac GTX 1060 3GB         : Shares: 49.35   | Rej: 0.7  | Speed:   18.38MH/s|
--------------------------------------------------------------------------------
0.Zotac GTX 1060 3GB         : T:65C | F:63% | P: 97W | I: 24.0 | Core:2021Mhz |


sp5 18.5 MH/s
krnlx 19 MH/s -20% on suprnova




Love it .)

[zhulick]

                       VC++ 2013 and CUDA 8.0 x64 382.05
CPU:1.64%          ChainWorks Industries beta - Version 0.9.8         [12:30:16]
--------------------------------------------------------------------------------
Algo:Skunk      | Port: 2000 | NetDiff: 21076.7            | Block:      35136 |
--------------------------------------------------------------------------------
Coin:signatum   | POW: 1250  | Estimated coins/day: 269.506                    |
--------------------------------------------------------------------------------
Solved:   0 | Diff:     1.24 | Shares: 3519.78 | Rej: 0.588878% | Speed:  175.84
--------------------------------------------------------------------------------
0.EVGA GTX 1070              : Shares: 589.07  | Rej: 4.91 | Speed:   29.13MH/s|
1.EVGA GTX 1070              : Shares: 620.8   | Rej: 3.86 | Speed:   29.31MH/s|
2.EVGA GTX 1070              : Shares: 618.98  | Rej: 5    | Speed:   29.45MH/s|
3.EVGA GTX 1070              : Shares: 543.51  | Rej: 1.82 | Speed:   29.07MH/s|
4.EVGA GTX 1070              : Shares: 592.34  | Rej: 2.83 | Speed:   29.44MH/s|
5.EVGA GTX 1070              : Shares: 555.08  | Rej: 2.43 | Speed:   29.61MH/s|
--------------------------------------------------------------------------------
0.EVGA GTX 1070              : T:55C | F:57% | P:106W | I: 24.0 | Core:1899Mhz |
1.EVGA GTX 1070              : T:56C | F:59% | P:106W | I: 24.0 | Core:1919Mhz |
2.EVGA GTX 1070              : T:48C | F:49% | P:106W | I: 24.0 | Core:1927Mhz |
3.EVGA GTX 1070              : T:55C | F:57% | P:106W | I: 24.0 | Core:1894Mhz |
4.EVGA GTX 1070              : T:52C | F:53% | P:107W | I: 24.0 | Core:1919Mhz |
5.EVGA GTX 1070              : T:52C | F:53% | P:107W | I: 24.0 | Core:1931Mhz |
--------------------------------------------------------------------------------
[12:27:12]Share: 6c57a501              | [10:31:06][GPU0]:Job not found (=stale
[12:28:08]Share: 7ee05340              | )
[12:28:15]Share: b0dc41c4              | [10:31:09][GPU2]:Job not found (=stale
[12:28:31]Share: c0d5ce9c              | )
[12:29:06]Share: b1511593              | [11:21:43][GPU1]:Job not found (=stale
[12:29:36]Share: a6845026              | )
[12:29:49]Share: 1d6ca931              | [12:05:50][GPU4]:Job not found (=stale
[12:29:52]Share: 3da8d1ab              | )


--------------------------------------------------------------------------------------------

x6 rig is running great. i have mine configured for efficiency over speed, so it may not be producing "record breaking" mhs, but i am very happy at the overall temp/wattage/speed balance this miner gives me.  this is excellent...

that said, my x1 and x2 rigs are still choking on high worker diff, with way too many blocks going by before a share is submitted.


        _________\ \     \____\     /|  \    \_\  \  Y Y  \  __________
                      \______  / \/\_/ |__|\______  /__|_|  / /
                             \/                   \/      \/ /
                        VC++ 2013 and CUDA 8.0 x64 382.05
CPU:   0%          ChainWorks Industries beta - Version 0.9.8         [12:40:58]
--------------------------------------------------------------------------------
Algo:Skunk      | Port: 2000 | NetDiff: 20220.5            | Block:      35151 |
--------------------------------------------------------------------------------
Coin:signatum   | POW: 1250  | Estimated coins/day: 40.8193                    |
--------------------------------------------------------------------------------
Solved:   0 | Diff:     1.12 | Shares: 623.29  | Rej: 0.52666% | Speed:   29.79M
--------------------------------------------------------------------------------
0.EVGA GTX 1070              : Shares: 623.29  | Rej: 3.3  | Speed:   29.03MH/s|
--------------------------------------------------------------------------------
0.EVGA GTX 1070              : T:54C | F:72% | P:107W | I: 24.0 | Core:1950Mhz |
--------------------------------------------------------------------------------
[12:34:17]Mean netDiff: 16873.9        | [06:16:30]Stratum connection interrupt
[12:34:47]Mean netDiff: 16969.1        | ed
[12:35:08]Mean netDiff: 17317.2        | [06:16:32]Failed to connect to stratum
[12:35:37]Mean netDiff: 17448.7        | .chainworksindustries.com port 2000: C
[12:36:31]Share: 86e53529              | onnection refused
[12:37:37]Mean netDiff: 17946.4        | [06:16:32]Retry in 30s
[12:37:59]Mean netDiff: 18027.3        | [06:17:29]Retry in 30s
[12:39:57]Mean netDiff: 18349.9        | [06:19:34]Retry in 30s
-------------------------------------------------------------------------------


for now i'm leaving the x6 rig running the miner/pool combo, but pulling my smaller rigs.  

for me the issue is not the wild hashrate they produce at the pool, or their sharerate etc.  the issue is participation.  and i think it's the low rate of participation of the smaller rigs that's actually harming the pool's ability to find blocks consistently.  

at any point the solution, or part of the solution for a block could be on one of the smaller rigs.  if they don't participate and submit shares, then the pool never stands a chance to find that block.  2-3 blocks here and there is fine, but 6-7-8 blocks without a share is just too much, especially when the latter seems to be the norm.  

multiply that by who knows how many other smaller rigs that are experiencing the same thing, and there are a LOT of blocks that the pool just never has a chance to even compete for.   i believe that the smaller rigs are actually hurting the pool's performance right now.

like i said, my x6 is staying, so i'm not abandoning the project in any way, and as soon as the new version of a miner and/or a pool update that fixes worker diff for smaller rigs is done - i'll be more then glad to bring them back

tanx for the thorough insight ...

what you are mentioning is a common issue at the moment - where the smaller rigs do choke on high diff shares ...

there is a solution i can propose ... but it will mean that EVERYONE has to comply with it ...

here is my proposition ...

1 - lower the difficulty of the lodiff port ( 2000 ) to an acceptable level where small rigs can mine easily without interruption ... this means that ALL smaller machines will be required to enter the --lodiff parameter ... this will allow shares to be distributed fairly and equally among the smaller rigs - no matter how many are on the port ...
2 - lower the difficulty of the hidiff port ( 6000 ) to start at a lower rate - but increase enough to cater for the larger machines and farms alike ... this means that ALL larger machines will be required to REMOVE the --lodiff parameter ... this will allow shares of higher difficulty to be freely shared among all the larger rigs - and still be able to submit enough shares to the pool so ALL miner have a better opportunity to solve a block ...

if this proposal is acceptable - i can have it sorted very quickly ... this will include the denarius pool ( tribus ) for those mining on the dnr pool as well ...

but i must reiterate - ALL miners must adhere to the correct port for their systems ... if a large miner slams the lodiff port and floods the stratum - we will implement a much more aggressive blocking system for the ip that do that ...

this will be in effect for ALL miners mining at our pool - not just CWIgm miners ...

let me know your thoughts - and any better ideas ...

tanx ...

#crysx

it may work, but you would have a hard time pulling it off.  relying on a user to follow directions is always a disaster waiting to happen

i have a different solution, especially since you control the entire environment from miner to stratum - a custom diff multiplier for the miner.

right now the 1080ti is the fastest card out.  it hashes at about 50 mh and the sweetspot for that card is ,let's say,  about a diff of 128, with 64 on the low end for fast blocks, and 256 on the high end for slower blocks.  use that card as the "default" or a value of 1.

1070 hashes at about 60 percent of the speed of 1080ti (1), so it's multiplier will be 0.6.  not sure what the 1060 hashes, but you get where i'm going with this - it would be whatever a ratio of it's speed/1080ti.

the miner knows a which gpu's are in there, and how many.  you could get fancy and make a per-model table to be really precise, or just take the easy way out and go by hashrate - which the miner also, obviously, reports.  if the default of 1 is 50mh, and the miner produces 80 mh, the multiplier is 1.6.  Again, i'm not sure what the 1060 hashes, but let's say it's 15.  an x6 1060 rig would report a hashrate of 90.  90/50 is multiplier of 1.8 etc, etc. etc.

this way you can have your diff logic walk the stratum through the range of diff of 64-256 only, and adjust on the fly when you have fast blocks.  each miner will calculate it's own multiplier based on which type and number and type of gpu's it's seeing ("fancy mode") or hashrate and adjust it's own difficulty accordingly with the stratum.     

i'm guessing that if you just change the difficulty on a miner, without adjusting the same on the stratum per worker, the miner will not submit valid shares.  so you'll need to either implement this multiplier on the stratum per worker, or better yet  - do it on a miner itself and just have the miner pass that info to the stratum.  if each miner is a worker, it would be an ideal way to pass the exact performance of a rig to the stratum.  this would also be really helpful if one of the cards on a multi gpu rig goes down, or throttles and miner hashrate goes down - the multiplier could adjust accordingly.

so let's say i have a x2 rig with 1 1080ti and 1 1070 or 80mh.  the pool starts me off at diff of 128 (sweetspot for 1080ti or value of 1), my miner does the math and figures out that my multiplier is 1.6, multiplies the 128 by 1.6 and tells the stratum - set diff for this worker at 128*1.6=204.8.  then a few minutes/hours later, the pool detects that the blocks are flying by and dumps the pool diff to 64.   my miner does the math again, divides 204.8 by 2, and tells the stratum to set the worker at 102.4.  pool goes to 256, my miner does the math etc. etc. etc.  

usually it's the stratum that tells the miner to adjust worker diff and you could do this on the stratum side, but since you control both ........

i think, if doable,  this would solve this particular problem permanently.  and you could implement this type of a system across any algo you want - just figure out what you want the default to be.  

[pr0ximus]

it may work, but you would have a hard time pulling it off.  relying on a user to follow directions is always a disaster waiting to happen

i have a different solution, especially since you control the entire environment from miner to stratum - a custom diff multiplier for the miner.

right now the 1080ti is the fastest card out.  it hashes at about 50 mh and the sweetspot for that card is ,let's say,  about a diff of 128, with 64 on the low end for fast blocks, and 256 on the high end for slower blocks.  use that card as the "default" or a value of 1.

1070 hashes at about 60 percent of the speed of 1080ti (1), so it's multiplier will be 0.6.  not sure what the 1060 hashes, but you get where i'm going with this - it would be whatever a ratio of it's speed/1080ti.

the miner knows a which gpu's are in there, and how many.  you could get fancy and make a per-model table to be really precise, or just take the easy way out and go by hashrate - which the miner also, obviously, reports.  if the default of 1 is 50mh, and the miner produces 80 mh, the multiplier is 1.6.  Again, i'm not sure what the 1060 hashes, but let's say it's 15.  an x6 1060 rig would report a hashrate of 90.  90/50 is multiplier of 1.8 etc, etc. etc.

this way you can have your diff logic walk the stratum through the range of diff of 64-256 only, and adjust on the fly when you have fast blocks.  each miner will calculate it's own multiplier based on which type and number and type of gpu's it's seeing ("fancy mode") or hashrate and adjust it's own difficulty accordingly with the stratum.     

i'm guessing that if you just change the difficulty on a miner, without adjusting the same on the stratum per worker, the miner will not submit valid shares.  so you'll need to either implement this multiplier on the stratum per worker, or better yet  - do it on a miner itself and just have the miner pass that info to the stratum.  if each miner is a worker, it would be an ideal way to pass the exact performance of a rig to the stratum.  this would also be really helpful if one of the cards on a multi gpu rig goes down, or throttles and miner hashrate goes down - the multiplier could adjust accordingly.

so let's say i have a x2 rig with 1 1080ti and 1 1070 or 80mh.  the pool starts me off at diff of 128 (sweetspot for 1080ti or value of 1), my miner does the math and figures out that my multiplier is 1.6, multiplies the 128 by 1.6 and tells the stratum - set diff for this worker at 128*1.6=204.8.  then a few minutes/hours later, the pool detects that the blocks are flying by and dumps the pool diff to 64.   my miner does the math again, divides 204.8 by 2, and tells the stratum to set the worker at 102.4.  pool goes to 256, my miner does the math etc. etc. etc.  

usually it's the stratum that tells the miner to adjust worker diff and you could do this on the stratum side, but since you control both ........

i think, if doable,  this would solve this particular problem permanently.  and you could implement this type of a system across any algo you want - just figure out what you want the default to be.  

Those are some nice suggestions there.

[Brucelats]

I will write this just. It might be a small bug i seen.

When i started miner several times and after restart also, it always initialized only 2x GPU from 7. 7 were shown in device manager and in after burner, but when i started miner only gpu 2 and 6 shown hashrate, rest were stuck on 0.


Then i cancled miner for 5th time, went alt tab to do something, tried run miner again and it worked. Dunno why it didnt recognized my GPU-s right away.


This is my .bat file:


setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
cwigm -c sigt -u Brucelats.Zotacx7_SIGT -p x --cpu-priority=3 -i 22 --tlimit=65,65,65,65,65,65,65
pause


I used exact same on my other rigs with 5 6 7 GPU-s, only changed temp limits a bit and worker name and they all worked. Only thing that is speciffic to this rig that had problems is, it had all the same GPU-s and that are Zotac GTX 1070 AMP! Extreme. Rest have mix, or at least 1 card is different. Cheers!

first - remove all the setx environment parameters ...

they are really only used for sgminer / amd settings ...

cuda settings are usually set within the environment when you install the nvidia driver - and there is no need to set those environment parameter for nvidia cards ... you will see the same hashrate and results when you remove them ...

second - why --tlimit? ...

CWIgm is a unique miner ... try without that parameter and restart ...

you may want to try adding --lodiff to access the lower difficulty port also ... at least test it -until the port changes take place ( if they take place ) ...

let us know that all goes ...

#crysx

Ok will change parameters. And i forgot --lodiff parameter. I'll add it yeah.



On second note, why not use temp limit?

I cant monitor my rig all the time. In case something happens and gpus start overheating i want my miner to close to prevent any damage. I use Air conditioner coz it's quite hot. In case something occurs with AC temps will start rising, so i want use temp limits to stop miners if that happens.

Unless i am wrong?

If there is no parameter to turn off miner if certain temperature limit is reached it should be added. I would always use it, and everyone should in case something goes wrong. Ok there are parameters to controll GPU usage and such, but i have my fans set on auto, i made a curve. And if i reach some high temperatures, something bad is going on haha. So no point to mine until that thing is resolved, so best idea is just to turn off miner and no harm done.

[TraianT]

I have a really small rig(about 100mh) and i was getting the same problem with the diff getting to high after the miner was runing for a h or so.

To work around it i just started more miner threads unsing just a part of the card to get lower Mh per mining instance. The diff didn't went up that much and i was able to get consistent shares to the pool.

[e6ug]

any chance you will add XCN  to your pool/miner?  it is a great nvidia coin that has been around forever. 

[Supercoiner111]

I have been testing the miner and pool and I have to say I am disappointed. I saw great results and boost on the mh/s I expected to get at the least same if not better. I was mining at the pool for over 6 hours with similar diffculty and I got 75% less in payments and rewards than with standard ccminer and on the old pool mining DNR!

I found this very strange not sure what is happening if its the miner or the pool but I am disappointed. I will return back to my old tried and tested setup, even if the hashrate is lower my return are much better!

[DiamondMax]

Thanks for accepting me to your closed beta-test program, Crysx.
Miner v0.9.8 runs for 2 days so far with no stability issues. OSes are Win7 and Win10, both x64.

The only problem as already mentioned here is too high difficulty shares for small rigs on lodiff port.
I have 1 rig of 6 * 1080 cards producing a total of 235Mh/s and another one of 3*1080+1*970 = 138Mh/s. Skunk algo.

For more powerful rig current diff setting of 1.24 seems fine, but still a bit high for the second. So I totally agree with your proposition to lower the diff on both ports. Or maybe add one more port for sublodiff miners?

Maybe provide some directions what port to choose based on hashrate of the rig? For example, less than 320 MH/s -> lodiff, 320 MH/s and more -> hidiff. Better solution would be to implement hashrate-based port switching within miner itself.

By the way I've started a comparison between CWI-pool/miner and Suprnova pool/palgin's miner. 3 cards from first rig directed to CWI and 3 cards to Suprnova. Same cards, intensity and PL/Clock settings, even same network latency. Started simultaneously. Initially thought that CWI will earn less because of that high diff issue (for 3 cards it becomes more important) or relatively low pool hashrate, but after 12 hours CWI leads by 2 coins despite 25 minutes downtime of the pool Will see after 24 hours.

Keep up a great work! Much appreciated!

[Warsaar]

Ok here we are.

Windows 10.

Miner is pretty stable. For 4 1080ti (x2 ASUS TURBO + x2 MSI AERO) here is something about 202-208 Mh/s depending on netdiff.

Temperature is stable and no more than 70C. But I have fans at 70-87% speed permanently for each card because they heat deifferently.

Intensity 25.

Settings: as you may see: http://imgur.com/a/tNmhQ
Also the screenshots taken from TM when the GPU0 have huge dump of hashrate and SAW like powerline.

Despite using TM to have a screenshots powerline is pretty much unstable. But the same was on palginmod so I think there is algo problem at all.

What about coins then there was about 189 for 24 hours. I think the miner's GUI option of predicted coin gain is not necessary - netdiff varies so you may have more and less coins for the same time. Also, usually you do not check miner to see how much coins you will  got - you check transactions and earnings history on the pool site. In this way, may be this part of GUI can be use for something else info?

Anyway - the miner is great, mostly for its stability. I have 50% hashrate drops on palginmod after ~2hours of continious work, so with palgin I need to reboot rig every 2 hours. This miner has no such issues.

Looking forward to unlock it for other pools! Thank you, Dev!

appreciate the feedback ...

if you are using ( and most seem to do ) the experimental temp control settings - and / or mean net diff setting - then you will always get a see-saw power usage and always start / stop mining ... this is because of the facts i posted earlier ... the miner itself tries to create the 'perfect' scenario for mining IF you have those settings active ... take them off - and you will see that there will be a constant regular power consumption and mining ...

as long as you have the correct parameters - its easy to mine consistently ... a LOT of the issues we are seeing with a lot of the users - are those settings ...

remove them and you should have a better mining experience ...

also - there is a very good reason WHY the stats are there in the miner AND the api has been remove ...

CWIgm-0.9.9 will have the new module inside to test ...

...

#crysx

Hello and thank you for your reply.

I've putted the MSI Afterburner settings to default and tried to use --max-temp setting, but it seems that it doesn't work. It has no influence on fan speed or hashrate or something.

Please let me know what actual settings should i set?

[dandyqb]

How to get rid of this error? 

https://farm5.staticflickr.com/4403/36531225015_0235c1c42b_b.jpg

[cryptoinvestor_x]

How to get rid of this error? 

https://farm5.staticflickr.com/4403/36531225015_0235c1c42b_b.jpg

Overclocking too much. Try dropping down core clocks slowly until it's stable.

[dandyqb]

How to get rid of this error? 

https://farm5.staticflickr.com/4403/36531225015_0235c1c42b_b.jpg

Overclocking too much. Try dropping down core clocks slowly until it's stable.

its only +150 on core, and they're stable on other miner, i tried to lower my intensity but still getting that error, its only on my 1060s, my 1070 is stable.

[pr0ximus]

How to get rid of this error? 

Overclocking too much. Try dropping down core clocks slowly until it's stable.

its only +150 on core, and they're stable on other miner, i tried to lower my intensity but still getting that error, its only on my 1060s, my 1070 is stable.

What's your OC setting?

[dandyqb]

How to get rid of this error? 

https://farm5.staticflickr.com/4403/36531225015_0235c1c42b_b.jpg

Overclocking too much. Try dropping down core clocks slowly until it's stable.

its only +150 on core, and they're stable on other miner, i tried to lower my intensity but still getting that error, its only on my 1060s, my 1070 is stable.

What's your OC setting?

PL 70, core +150, mem -502, fan 75, intensity 24

but why on other miner they're stable?