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

[Brucelats]

Rofl at GH/s in the picture instead MH/s

[1715405962]

1715405962

[1715405962]

1715405962

[1715405962]

1715405962

[1715405962]

1715405962

[1715405962]

1715405962

[1715405962]

1715405962

[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?

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

but why on other miner they're stable?

And what is in your batch file?

[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?

And what is in your batch file?

cwigm -c sigt -u myusername.myworker -p x -i 23 --lodiff --max-temp=70

[Brucelats]

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?

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

but why on other miner they're stable?

And what is in your batch file?

cwigm -c sigt -u myusername.myworker -p x -i 23 --lodiff --max-temp=70

Try use intesnity 22 and if it still occurs try lower the core slowly until it will work fine. I also lowered my core from 95 to 90 when i seen few ounce messages during mining. Seems ok now. I had several in 5 hours but maybe this helps and give extra profit in long run.

[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?

And what is in your batch file?

cwigm -c sigt -u myusername.myworker -p x -i 23 --lodiff --max-temp=70

Try use intesnity 22 and if it still occurs try lower the core slowly until it will work fine. I also lowered my core from 95 to 90 when i seen few ounce messages during mining. Seems ok now. I had several in 5 hours but maybe this helps and give extra profit in long run.

ok,thanks!i will try this, but im only wondering, it's stable with spmod3

[zero_sight]

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?

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

but why on other miner they're stable?

And what is in your batch file?

cwigm -c sigt -u myusername.myworker -p x -i 23 --lodiff --max-temp=70

Try use intesnity 22 and if it still occurs try lower the core slowly until it will work fine. I also lowered my core from 95 to 90 when i seen few ounce messages during mining. Seems ok now. I had several in 5 hours but maybe this helps and give extra profit in long run.

ok,thanks!i will try this, but im only wondering, it's stable with spmod3

These miners are not the same though....

[shubaduba]

Almost everyone who tested CWI miner reported too high diff.

I really don't understand why you can't lower stratum diff.
Is that because pool running on slow hardware or internet connection?

There is a simple logical suggestion:  If user did not submitted any share between found blocks, then stratum diff is too high.
My 320MH/s rig is trying hard not to miss those fast blocks with 1.24 stratum diff and 4.3 shares/minute.

Even with this speed you can see that my rig just missed two blocks.

What sharerate do you mean when talking about hammering by big rigs?

Normal sharerate is 12-30 shares/minute. If submit more than 30, then mining efficiency will be choked by internet connection limits.
If submit less than 12, then it will be chocked by missing blocks.

Survnova, yiimp, nicehash, coinmine, nanopool, theblocksfactory, miningpoolhub - EVERY pool supports sharerate up to 60/minute.
Why you choke your miners with 15x-30 times lesser sharerate?

[yayoerrol]

what happened to pool site cant login...

[xcougarx]

This has given me the most stable results so far, especially if I compare final hash rate on pool side ... the one under statistics->graph shows you what your pool side average is visually, while any pool will have momentary numbers go up and down.

Every miner with every particular card has a different maximum, same miner different algorithms will also have a different limit for overclocking.

You look for that limit, than back off some to give it breathing room. By example:
When I was testing the limits with CWI I saw the same failure mode 2-3 times around +125 core -1000 memory 88% power, -i 26.5 with my cards (works for a few minutes, I believe when the cards warm up it starts failing). I get "invalid nonce" in a loop, estimated coins goes into millions

With the +121 core -1000 memory 88% power, -i 26.5 I was stable for a few hours.
I notched down to -i 26 +120 core for some breathing room and have not had problems with my 1080 ti cards within past day.

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?

And what is in your batch file?

cwigm -c sigt -u myusername.myworker -p x -i 23 --lodiff --max-temp=70

Try use intesnity 22 and if it still occurs try lower the core slowly until it will work fine. I also lowered my core from 95 to 90 when i seen few ounce messages during mining. Seems ok now. I had several in 5 hours but maybe this helps and give extra profit in long run.

ok,thanks!i will try this, but im only wondering, it's stable with spmod3

[chrysophylax]

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

there is always a chance to have a lot done ...

its still very young in its evolutionary stage - so as time goes on - our intention is to bring many features - along with optimization and hashrate ...

for now - its all about stability and usability ... like building a home ... you dont move into an empty block of land ... once we get the foundation of the miner set in concrete - we will work on the building - then the contents of this building to make it a home ... then improve the home in every way we can ...

#crysx

[chrysophylax]

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!

thats sad to hear ...

but without be obnoxious - where in the test did 'stability and ease of use' come into the equation? ... the main focus of this beta test ...

you talk about hashrate and 'how many coins' ... this is NOT the purpose of the test - and im really starting to get tired of miners thinking CWIgm / CWIgm pool will just magically get more ( or the same ) coins that other pools / miners get ... it doesnt work that way - it NEVER will ...

local hash - pool hash - network hash - and the 'block solving 'luck'' ALL have a part to play in this ... so a short 24-48 hour comparison of miners and pools when hashrates fluctuate so much - and nethash dips and increases in such a volatile nature - seems unfathomable to me and all those that actually understand what goes on in this crypto arena - especially mining ...

you CANNOT base ANY of these assumptions you have about coin minting - on the miner or the pool ... and IF the beta test was about minting coins ( which the beta ISNT ) - then we would make sure we had the highest hashrate in the pool - and all your assumptions would still be a little skewed - because there is no way of telling what will happen with the network hashrate and difficulty ...

we appreciate your test - but please be on focus as to WHY the beta test was created in the first place - and NOT based on what YOU want out of it ...

im sure if the 'luck' of block solving was the other way - and we solved more blocks on our pool that other - a more positive - less disappointing outcome would have been had for you ... but that would still have missed the point of the beta anyway ... stability and ease of use BEFORE anything else ... as written in response to the post above you ...

---

'
there is always a chance to have a lot done ...

its still very young in its evolutionary stage - so as time goes on - our intention is to bring many features - along with optimization and hashrate ...

for now - its all about stability and usability ... like building a home ... you dont move into an empty block of land ... once we get the foundation of the miner set in concrete - we will work on the building - then the contents of this building to make it a home ... then improve the home in every way we can ...

#crysx
'

---

tanx ...

#crysx

[chrysophylax]

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!

thats great ...

stability of the miner is fast becoming the staple of the code ... this is EXACTLY what we want ...

the bugs are there and we are working on squashing and removing these bugs ... this testing every one is doing is making such huge leaps in the code clarifying and improvement ... we are very appreciative of it ...

the diff issues WILL be resolved - tho i think with setting up a third port - the confusion will just increase ... many many new miners are entering this arena - and our second focus 'ease of use' will not be met if we introduce more ports into the mix ... it IS a good idea tho - but not practical in the usage sense ...  we really do need to tweak what we have and improve the diff calcs and aggression of the stratum ...

some great ideas being put forward tho - we are taking these on board ...

the comparison you are making between pools will never be accurate ... coin minting ( as mentioned in the previous response ) is a hash and diff factor 'luck' system ... there will be times our lower hashrate pool will receive more coins than other ( due to the amount of miners split ) and other time will be less ( due to the small hashrate the pool has in comparison - and the amount of blocks solved by the pool ) ... coin minting is NOT the goal of the beta - and we do understand it is the goal of the miner ... we mine for the same goal also - but hashrate and block solving is anyones guess as to who will have - and how much ...

as CWIgm grow into a mature miner - and is part of a much more mature and stable mining system - this will of course change ...

we are only in the beginning ...

tanx for the thorough test ...

#crysx

[chrysophylax]

                       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.  

whao ...

i missed this post ...

serves me right for working right after i get out of bed ...

some great suggestion ... some of which will be very difficult to implement if we go that way - but not impossible ...

tanx for the well though out suggestions ...

#crysx

[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

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.

there is a device called the PID ... it is a controller of sorts - an algorithm ...

https://en.wikipedia.org/wiki/PID_controller#Fundamental_operation ...

the implemented PID controller - at this point - has a racing condition with the internal firmware which controls the fans speed ... which means that if the user has not set the fan speed manually at a desired level - the pid will drop the temperature to the limit set by the user - but the gpu will notice that the temperature is going down and will drop the fan speeds - which will result in a temperature increase which the PID has to readjust and so on ...

ie ... do not use the --max-temp feature with the fans set to auto ...

the temp control and the netdiff parameters are experiential ... the netdiff parameter calculates the netdiff incorrectly - even tho its only about 1% error - we advise NOT using it at all for now ... it is fixed in CWIgm-0.9.9 ...

other than that - great results ...

soon - you will only need the --lodiff parameter for small rigs ... the consensus is overwhelmingly in favour of stratum diff change - so there will be some teething issues there - but we will get through them ...

#crysx

[blockbasher]

I signed up at yout pool and am ready to go.  I sent a PM about possibly getting a copy of the  CWI miner and hopefully get accepted in beta program.  Hope you get to it soon.  Thanks!     

[Amph]

i tried your miner, and i must admit, i was surprised, to see it so fast, it's faster than sp mod5 or 6, by 1 mega with the same settings, seems that this miner is good for low tdp usage

with 70% tdp i get nearly 30MH per gpu, you are going to make it work wth any pool after the beta ends right?

[chrysophylax]

Almost everyone who tested CWI miner reported too high diff.

I really don't understand why you can't lower stratum diff.
Is that because pool running on slow hardware or internet connection?

There is a simple logical suggestion:  If user did not submitted any share between found blocks, then stratum diff is too high.
My 320MH/s rig is trying hard not to miss those fast blocks with 1.24 stratum diff and 4.3 shares/minute.

Even with this speed you can see that my rig just missed two blocks.

What sharerate do you mean when talking about hammering by big rigs?

Normal sharerate is 12-30 shares/minute. If submit more than 30, then mining efficiency will be choked by internet connection limits.
If submit less than 12, then it will be chocked by missing blocks.

Survnova, yiimp, nicehash, coinmine, nanopool, theblocksfactory, miningpoolhub - EVERY pool supports sharerate up to 60/minute.
Why you choke your miners with 15x-30 times lesser sharerate?

yup ...

which is why later - i shall post WHEN we are changing the settings ...

this way most miners will have ample warning to recognize the disconnections ...

this will mean a few disconnections will take place - as we ALL try and figure a nice balance of diff ...

it might be a good thing to setup a small meet or group on skype to go through and test the stratum settings - for those that want to join in - make suggestions - and test the settings live ... especially while we adjust the settings ...

if we do this - those with smaller miners - please join the discussion ... we already have a CWI-Slack with a cwigm subchannel - so we can hold it there also ... but whatever we do - there WILL be interruptions to the mining today ( today = adelaide time which i think is +0930GMT - https://www.google.com.au/search?q=current+time+in+adelaide+sa&gws_rd=cr&ei=EPKPWdn8HYSh8QXIvZqgCA ) ...

tanx ...

#crysx

[chrysophylax]

I signed up at yout pool and am ready to go.  I sent a PM about possibly getting a copy of the  CWI miner and hopefully get accepted in beta program.  Hope you get to it soon.  Thanks!     

ill be going through the pm individually ...

another 20 + 17 while i was asleep ...

so please have some patience ... as it is sunday for me here - and 'supposed' to be my rest day / day off with family ...

#crysx

[chrysophylax]

i tried your miner, with the bust, and i must admit, i was surprised, to see it so fast, it's faster than sp mod5 or 6, by 1 mega with the same settings, seems that this miner is good for low tdp usage

with 70% tdp i get nearly 30MH per gpu, you are going to make it work wth any pool after the beta ends right?

hi amph ...

nice to see you mate ...

this is only the beginning - as the miner truly is only about three weeks old ... so there is a LONG way to go with it ...

stability and ease of use is the primary objective ... unlike that other guy - we dont base everything on false has rates and pretend code - we base it on written kernels - original code - and a LOT of it on user experience ( good and bad ) and make sure the beta is focused on the stability and ease of use of CWIgm ...

so if hashrate are more - then thats a huge bonus - because we have a higher level of algo optimization ( Class A ) that will not be released into this miner as of yet ...

when CWIgm is stable - and VERY easy to use - the consideration is there ... BUT - as stated many time over in this thread - the current state of the miner is tied to the CWI-Pool system and is done so for a number of VERY good reasons ... so for the foreseeable future - it will remain that way ...

glad you have tested and seen for yourself ... that we dont talk through our bums - we prove it ...

now - to get to multitude of pm - and then to 'fix' this diff issue we have ...

#crysx

[xixou]

My bat file:

Code:

timeout \t 5

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

pause

You better use --max-temp=88 to make sure to let nvidia throttling to +83C automatically and avoid mining pauses.