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

[zhulick]

ok, some quick observations after running for about 8 hours or so.

Short version - miner reports great hashrate, better then any other i tried so far.  However, the pool likes to jack up the worker diff way too high, choking out smaller rigs.

Long version:

Trying on a total of 10x1070's spread across one main rig, and some random boxes.

box 1 - win 7, single gpu. (worker 1)
box 2 - win 10, single gpu. (worker 4)
box 3 - win 7 2xgpu (worker 2)
box 4 - win 10 6xgpu. (worker 3)

All gpu's are tuned with exactly the same settings - +125 core, +500 mem, 60%tdp (110w) in afterburner. These were my go to settings for zcash and lbry, so i left them alone for now  All get just over 29mh on skunk, according to the miner.

However, and this is especially true for the single and 2x gpu machines, the pool difficulty ends up being too high.  The single gpu's started out at pool diff of 64 (worker at 0.25), which from my previous experimenting is the sweet spot for a single 1070 gpu, and then eventually ended up at diff of 256 (worker at 1).  At 256 the card chokes.  When the nethash is nice and steady, the card is still able to submit work ever 2-3 sometimes 4 blocks.  When whatever is hitting this coin hits it hard (when you see the nethash double in like 5 minutes) the card can't keep up with fast moving blocks at all.  There was a time when i caught a glimpse at the miner and saw at least a good dozen blocks go by before the card was able to submit any work.  There were instance that the card was so chocked, the pool would show that a worker dropped out, meaning that the card submitted no shares in whatever time interval the pool uses to calculate hash.    In fact, as i'm typing this i can see the miner window on my single gpu boxes, and one of them just had about 10 blocks go by without any work submitted (diff 256 pool, 1 at worker).

It's a similar story for the 2xgpu box.  The diff started off at 128, which again i think is a sweetspot for this setup, but then climbed to 512.  At that diff, just like the single gpu setup, too many blocks go by before a share is submitted and the cards choke.

6xgpu rig seems to be not as affected by this.  It started off at 256, then eventually climbed to 640.  It too misses out on blocks, and hashrate reported at the pool jumps around wildly, but at least it's able to get some shares in every other block or so.

Overall, i am very happy with the miner.  The pool is finding blocks at a good clip, and with good efficiency, so maybe this approach of jacking up the worker diff works.  But it feels wrong to see this many bunches of blocks go by without a share submitted.  To me it means that my gpu's are not even competing to find a solution to a whole lot of blocks.  You can't solve a block if you don't at least compete to solve it.

As i was finishing typing this, another 6 blocks went by before my single gpu rig submitted a share.  That means that this particular gpu didn't even compete for 6/7th of the opportunities to find a block.

[1714106356]

1714106356

[1714106356]

1714106356

[1714106356]

1714106356

[cannonfodder]

4 1080 GTX Ti running at +120 core, 80% PL and 21 intensity. All running around 52.3 MH/s.

Whereas all the other miners I've run have the power limit and core clock constantly bouncing around, this one remains steady. Overall, very impressed with it. Thanks. 

[josywong]

ok, some quick observations after running for about 8 hours or so.

Short version - miner reports great hashrate, better then any other i tried so far.  However, the pool likes to jack up the worker diff way too high, choking out smaller rigs.

agree. great hashing rate but without a share after mining for about 7+ hours

[tpd09]

ok, some quick observations after running for about 8 hours or so.

Short version - miner reports great hashrate, better then any other i tried so far.  However, the pool likes to jack up the worker diff way too high, choking out smaller rigs

same story here - my one GPU rig goes offline after failing due to diff.

my other 5 GPU rig, would go offline after 8 or so but will reconnect again.

have yet to run 24 hours stable.

[mydreamadsl]

hi all ...

seems like i am online again - and will catch up on the posts ...


#crysx

Would you please send link to the miner in PM or reply to the email please)))

[g01dt00th]

for first: sorry for my english.

gpu's: 6x GTX Titan Xp
drivers: 385.12 beta

default bat for sigt

first start was with PL 100%, core +150, mem -500 :  driver was crashed in few seconds

second start was with PL 100%, core stock, mem stock : rig was crashed in about 4 minutes

hmm... like as ewbf in past

ok, PL 87%, core stock, mem stock : rig stable about 10 min

next, PL87%, core +150, mem stock: rig stable

intensity as auto is 21

add -i 25 to bat and run - rig stable already 30 min

http://roenko.ru/img/miner.png

what is missing: remote monitoring, like as EWBF 0.3.4b.
 

update after 10h uptime, speed reduced to 323Mh (initially was 325Mh), rig working stable, no reboot, no crashes

[zhulick]

Trying a single 1070 gpu (+125core/+500mem/60%tdp) with denarius (tribus) on win7.

Immediately noticed a new command in the bat that doesn't exist in the bat for sigt  --mean-net-diff=1.1

Miner reports a speed of 53.  I have never mined this algo before, so nothing to personally compare it to, but i did check yiimp benchs- 53 is pretty damn good

After a few minutes i noticed something weird.  In the right bottom box, a yellow line saying net diff > mean net diff.  The netdiff field in the miner turned red, and the miner just stopped mining.  I could see the card idling in afterburner.  This went on for a few blocks, then the netdiff field turned green, and the miner resumed.   Rinse/repeat every 5-10 minutes or so, with each break lasting about 2-3 blocks.

I guessed that the --mean-net-diff=1.1 was causing this, took it out, and this behavior stopped.  Miner just kept on mining.

I'm not sure what --mean-net-diff=1.1 is meant to do, and it's probably there for a good reason. For me, however, it's pausing the miner and makes the gpu just sit there idling for a bit.  An idling mining gpu is a sin

[Kostya_NSK]

DNR mining:

1080 Ti Aorus 97-102 MH
1080 Aorus 70-75 MH

Core +100 Memory -500 TDP = 0.7

But mining of denarius is not profitable today. Speed need to be at least 20% more MH from cards like in "SP tribus MOD"

[zorvalth]

DNR mining:

1080 Ti Aorus 97-102 MH
1080 Aorus 70-75 MH

Core +100 Memory -500 TDP = 0.7

But mining of denarius is not profitable today. Speed need to be at least 20% more MH from cards like in "SP tribus MOD"

SP mod is 68 on 1070 and 2% fee and 0.1 btc
CWIG is 58 on 1070, its not that much difference, 8 mh difference =    0.000639btc per week in perfect luck. which means you need 156 pieces of gtx 1070 to cover the initial 0.1 btc you need to pay for sp mod and you will pay it back in a week.

[tpd09]

can some one advise which Android app I can use to import the API from the chainworks pool?
thanks

[Boulevard2005]

Someone told me sigt mining may be make vga die soon because gpu power continuetly up/down 5-10% (not like zec mining only 2-3%). Is this true?

[slatanic2012]

any chance the new version work with other coins, like cream?

[chrysophylax]

there is a russian guy that messed with the code of CWIgm and is claiming it as his ... ill be posting about that a little later - but PLEASE do not use ANY other miner unless it comes from us ... if you do - you run the risk of ANYTHING happening to your system - and we just simply not be able to do a thing about it ... legally - we are asking the questions ... but either way - legal or not - if you use a miner that is not from the original source ( ie - directly from us ) - then dont use it ... especially if its a hacker looking at making quick btc from themselves by hacking your systems also ...

Not code, just strings. And I'm not claiming it as mine It was clearly stated it's a cwigm and all who want an original version were encouraged to participate here.
Yes, everyone who uses 3rd party versions should first accept the risks.

hi Mikanoshi ...

apologies for taking this long to respond - as ive been inundated with pm - mail - and real life considerations ...

lets get a few things straight here - as i dont want to get into an argument of semantics - or technicalities for that matter ...

i appreciate that your explanation on terminologies - but its quite skewed and false ...

first - when you change ONE character on a proprietary application - you are messing with code ... changing ANYTHING in the system means you are changing the owners state of the system - which means you are changing the original state of the code ... thus changing the core functionality of the application and also changing the way it works ... this is not open source software - it is proprietary ...

second - when you put your name to any part of the code ( strings or even a single character ) - you are stating that you are directly or indirectly involved with ( or associated with ) the developers and / or core code ...

regardless of whether you THINK you are helping or not - you are changing OUR code - no matter how small the changes maybe ... and as such - are changing the core functionality of what we ( the developers and actual owners of the code ) intended ...

if you had ANY intention of being ANY help whatsoever - you should have contacted us FIRST and requested involvement ... instead - you took the standalone application and changed it without out permission ... so we will categorically ask you to cease and desist the changing of our code - and the distribution of this code ... our miner is still in beta and is constant change - so what you are doing is actually detrimental to the further development of CWIgm ... this includes impeding the accurate testing and growth of CWIgm which extends to the use of the people who mine with it ...

we shall continue to push updates and further the functionality - and as the new versions come to light - we hope that you will abide by our requests ...

we could always use the help of good coders in different areas of our business - and we welcome it ...

#crysx

[chrysophylax]

Does anyone know which android app can be used to monitor pool with the QR code provided?

look for applications ( some are free ) that are MPOS API compliant ...

we are looking into our own ...

#crysx

[chrysophylax]

have not received any transaction for over 2 hours.

should I stop mining?

Its been almost 4 hours without the pool hitting a block. The pool should hit the block about every 70-80 minutes with the current hashrate. The last two hours before the last block the pool hit 5 blocks which was great, so its normal to be little dry now. For the last 24 hours it hit 25 blocks which was great because half of that time the pool was with almost twice less hashrate. I hope we will start hitting blocks again very soon. If it goes more than 6 -7 hours without a block we can speak about a problem but i doubt it will get to that.

very high nethash ...

at the time of writing this - i think it was at 5.7TERAHASH ...

thats a lot of hashrate right there - and most was at yiimp and suprnova ...

anyway - you probably know that by now - as im only just catching up with the thread ...

...

#crysx

[soothaa]

Okay dev I'm here cause you said you had bested sp_ with your version, where can I download it? Do I need to compile from source?

[chrysophylax]

ok, some quick observations after running for about 8 hours or so.

Short version - miner reports great hashrate, better then any other i tried so far.  However, the pool likes to jack up the worker diff way too high, choking out smaller rigs.

Long version:

Trying on a total of 10x1070's spread across one main rig, and some random boxes.

box 1 - win 7, single gpu. (worker 1)
box 2 - win 10, single gpu. (worker 4)
box 3 - win 7 2xgpu (worker 2)
box 4 - win 10 6xgpu. (worker 3)

All gpu's are tuned with exactly the same settings - +125 core, +500 mem, 60%tdp (110w) in afterburner. These were my go to settings for zcash and lbry, so i left them alone for now  All get just over 29mh on skunk, according to the miner.

However, and this is especially true for the single and 2x gpu machines, the pool difficulty ends up being too high.  The single gpu's started out at pool diff of 64 (worker at 0.25), which from my previous experimenting is the sweet spot for a single 1070 gpu, and then eventually ended up at diff of 256 (worker at 1).  At 256 the card chokes.  When the nethash is nice and steady, the card is still able to submit work ever 2-3 sometimes 4 blocks.  When whatever is hitting this coin hits it hard (when you see the nethash double in like 5 minutes) the card can't keep up with fast moving blocks at all.  There was a time when i caught a glimpse at the miner and saw at least a good dozen blocks go by before the card was able to submit any work.  There were instance that the card was so chocked, the pool would show that a worker dropped out, meaning that the card submitted no shares in whatever time interval the pool uses to calculate hash.    In fact, as i'm typing this i can see the miner window on my single gpu boxes, and one of them just had about 10 blocks go by without any work submitted (diff 256 pool, 1 at worker).

It's a similar story for the 2xgpu box.  The diff started off at 128, which again i think is a sweetspot for this setup, but then climbed to 512.  At that diff, just like the single gpu setup, too many blocks go by before a share is submitted and the cards choke.

6xgpu rig seems to be not as affected by this.  It started off at 256, then eventually climbed to 640.  It too misses out on blocks, and hashrate reported at the pool jumps around wildly, but at least it's able to get some shares in every other block or so.

Overall, i am very happy with the miner.  The pool is finding blocks at a good clip, and with good efficiency, so maybe this approach of jacking up the worker diff works.  But it feels wrong to see this many bunches of blocks go by without a share submitted.  To me it means that my gpu's are not even competing to find a solution to a whole lot of blocks.  You can't solve a block if you don't at least compete to solve it.

As i was finishing typing this, another 6 blocks went by before my single gpu rig submitted a share.  That means that this particular gpu didn't even compete for 6/7th of the opportunities to find a block.

this is great ...

positive results and criticism ...

the results seem to be quite good - especially stability ...

the aggression the pool / stratum has - we are tuning it to the algo ... this is why at times you will see the miner stop for a few seconds - while adjustments are being made ...

we are working diligently to resolve all / any issues - as well as work towards a better system with both miner and pool ...

much appreciated ...

#crysx

[chrysophylax]

ok, some quick observations after running for about 8 hours or so.

Short version - miner reports great hashrate, better then any other i tried so far.  However, the pool likes to jack up the worker diff way too high, choking out smaller rigs.

agree. great hashing rate but without a share after mining for about 7+ hours

you mean - without a block ...

thats due to the ( still ) high difficulty ...

if you have not submitted a share in 7hours - then there would be some big issues there ...

#crysx

[chrysophylax]

ok, some quick observations after running for about 8 hours or so.

Short version - miner reports great hashrate, better then any other i tried so far.  However, the pool likes to jack up the worker diff way too high, choking out smaller rigs

same story here - my one GPU rig goes offline after failing due to diff.

my other 5 GPU rig, would go offline after 8 or so but will reconnect again.

have yet to run 24 hours stable.

yup - looking into the refactoring of the settings of the stratum ...

your miner 'looks' like its dropped off to the pool - but its not obviously - as its processing a very high difficulty share - which takes time to submit to the stratum / pool ...

as much as high diff shares are counted more heavily if a block is solved - this shouldnt happen this way to smaller machines ... so we are looking at settings and tweaks that will allow the smaller miners to submit more lower diff shares - hence increasing the share rate as well ...

#crysx

[chrysophylax]

for first: sorry for my english.

gpu's: 6x GTX Titan Xp
drivers: 385.12 beta

default bat for sigt

first start was with PL 100%, core +150, mem -500 :  driver was crashed in few seconds

second start was with PL 100%, core stock, mem stock : rig was crashed in about 4 minutes

hmm... like as ewbf in past

ok, PL 87%, core stock, mem stock : rig stable about 10 min

next, PL87%, core +150, mem stock: rig stable

intensity as auto is 21

add -i 25 to bat and run - rig stable already 30 min



what is missing: remote monitoring, like as EWBF 0.3.4b.
 

update after 10h uptime, speed reduced to 323Mh (initially was 325Mh), rig working stable, no reboot, no crashes

reduction ( as well as consistent fluctuation ) of hashrate is normal due to throttling from heat and other factors ...

but once it settles into a steady hashing stream - that should stay 'reasonably' stable ... unless you have an algo like bitcore for example - which changes constantly ...

stability is what we are after - so this is a great result ...

#crysx