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

[abudfv2008]

It's from too high sher diff. For some hidden reason, no one want change this...

No it is not.

Yes it is.

High difficulty leads to bigger fluctuations and thats all. But as you can see there are no fluctuations beyond real hashrate. So there are 2 explanations.
1) The reported hashrate is false. We can't check it as far as there is only one pool.
2) Stealing

[chrysophylax]

It's from too high sher diff. For some hidden reason, no one want change this...

No it is not.

Yes it is.

High difficulty leads to bigger fluctuations and thats all. But as you can see there are no fluctuations beyond real hashrate. So there are 2 explanations.
1) The reported hashrate is false. We can't check it as far as there is only one pool.
2) Stealing

you seem to forget WHO we are and WHAT we do - to even attempt an insult like that concoction of stealing ...

first - ChainWorks Industries is a BUSINESS - and as such are bound by the LAW of the Federal and State Government of Australia ... we dont even entertain the idea of doing anything underhanded - in any way shape or form - or we LOSE the company and all we have been working for ...

second - we are here because we have been mining for a LONG TIME - longer than most ... we have seen the underhandedness of other devs ( yes - THAT dev ) - and seen the greed that drive people to do underhanded and ILLEGAL things in this industry ... we WONT - and we DONT ... PERIOD! ... we take what we do and say very seriously - and so should you ...

all that you are seeing here are settings that are placed within the realms of the stratum and the pool - WITH protection now from DDOS - due to the attacks ...

IF you have not set the miner to the lodiff port ( using --lodiff ) then you WILL be forced into the hidiff port ( port 6000 ) which starts at diff2.5 and goes upwards from there ... meaning this - if you have more than 4cards ( and we will fix this in future releases ) and you DO NOT add the --lodiff parameter - you are on port 6000 and the diff WILL be too high for your rig to handle and as such - submit less shares tho at high diff rates ...

we do NOT accept ANY 'possibilities' that you have stated - ESPECIALLY with regards to stealing ...

your results and posts of stats are great ... and PROVES that you are submitting VERY high difficulty shares - which is why the pool shows you doing 'less' work by submitted shares ...

ALL this software we are using is EXPERIMENTAL - ALL of it ... including the Signatum Wallet / daemon ... there are many factors that accompany such software - and the use of ... all which we need to iron out as we go along ... all this talk of pools and people ripping miners off is absurd to say the least - at least it is for us and the likes of ocminer ( suprnova ) and tpruvot ( yiimp ) and a few others - who have been in this industry longer than most can remember ... good honest hardworking developers that are ALWAYS improving and ALWAYS doing the best we all can for the communities and people alike ...

if there is an issue - then state ALL the facts ... ie - ALL the stats ( like you have - and thats great ) - ALL the setup - including your commandline parameters ( without your username and password ) - and what EXACTLY the issue is ...

you have supplied two of the three things that we need ... so - to resolve this without slinging the 'option' of stealing / dirt around - please let us know what your commandline parameters are - so that we can test PROPERLY ...

afterall - this IS a test ... and we are NOT here for ourselves alone ... we are here for you also - as a miner and crypto enthusiast ...

remember - we could have kept ALL of this private and under a veil - and NOT brought it out into the open like this ... we have a farm ( theFARM ) - we have a company ( ChainwWorks Industries ( CWI ) ) - we have the means of making our own money / coins and have done so for over 5years ...

this issue you are having sounds like the typical issue of the miner forcing the hidiff port - which has been pointed out by other members of the community ... let us know what parameters you have used in order to rectify this issue ... so that we can improve the miner moreso ... which will be in my next post in the next few minutes ...

and please - no assumptions or options or accusations ( i know you didnt accuse - but you made it a residual option that it could 'only be if' ) - or i will start to delete posts ... this thread is about helping - and testing ... so lets work together ...

tanx mate ...

#crysx

[chrysophylax]

### CWI-MINING - CWIGM


hi all ...

the new revision of CWIgm is now ready for testing ...

a few things have changed since the last revision - especially the way the miner looks ...

the Interface Integration ...

this is the major part of the display which now allows you to see the stats ( and specs being static ) as they are updated ... unlike the scrolling list that most of you are used to ( with ccminer for example ) this is a major change to the way CWIgm works with the statistical display - making it MUCH easier to read and keep an eye on ...


the Algorithms ...

the skunkhash algo has been improved / optimized a touch ... so some cards should see a better hashrate with a more stable power usage - even with oc ...
the tribus algo has been added with some optimization - but coded so that stability is more the focus ...
 

the Parameters ...

new parameters have been added also which make for an easier mining experience ... since there are two algorithms in the miner now - a parameter has been added which allows easier setup for the coin that you want to mine ...

-c or --coin parameter allows you to specify the coin you wish to mine - and the miner makes the rest of the mining target for you ( currently algo and pool - which is fixed to the CWI-Pool system currently ) ...

--shares-limit parameter sets the maximum shares to process before exiting the application ...

--time-limit parameter sets the maximum time to process before eciting the application ...

--screentime parameter sets the time interval to update the visual frontend ...

-N or --net-diff-samples parameter is for those who want a more accurate estimation of network difficulty ... it does this by a calculation of the 'mean' ( average ) of a set number of blocks that have been processed by the network ...

a few other parameters have been added - one which is currently experimental ( being the --max-temp parameter ) - so please take the few seconds of time to read the readme that comes with the package ... and of course - test every parameter if you can - and please post ... we are still working on the CWI-Stats template - so that will added into future revisions of the miner ...


please be aware that bug exists in the distribution - where the miner will not allow you to Ctrl-C out of the mining process ... you will need to close the actual mining window via the 'x' in the top right hand corner to close the miner ... this is a known bug of course - and we are working towards a fix ...

you will also notice that there is only ONE executable this time - it is the x64 version ... this is intentional - as microsoft and nvidia are phasing the x86 support out from future SDK / CUDA ...

as always - check the md5hash against the zip package AND the files located in the second post on this thread - so that you can rest assured that the package you have is the same package you downloaded from our link ...

we hope you enjoy the new release - and hope that you test it to the furthest you can push this release of CWIgm-0.9.8 ...

please check the links you have been supplied for the new package in the next few minutes after this post ... and we look forward to your feedback - which is ever so important ...

tanx ...

#crysx

[chrysophylax]

Awesome work! Thanks for the update!

no worries - let us know what you think ...

and the stats / specs please ... we would be very intersted in the stability of tribus when you get the chance ...

tanx ...

#crysx

[Mapuo]

 File identification
MD5 0cdf14aa526fe94193de9e5224dc5c04


Not match

[chrysophylax]

File identification
MD5 0cdf14aa526fe94193de9e5224dc5c04


Not match

checking again now ...

edit - user error ( my error - copying the prior hash before changes made ) - correcting now ...

tanx for picking this up ...

#crysx

[lenosamsung]

Thank you for your favor  I tested it on my computer (just common desktop, 1060 3G 1rig)

Normally, In palginmod(Skunkhash mining), 1060 3G's hashrate 15.5MH/S~

but CWIGM 0.9.8's hashrate is better, which is more than 18MH/S

http://imgur.com/a/S2DAj

it is really good... I'm so excited

I'm gonna doing more test about this miner.

Say thanks to chrysophylax again.

Regards.

[nostrakhan]

Windows 10 x64

This is on SIGT with 6 msi armor 1080ti at 75% tdp, +130 core, -1000 mem.


I also have 8 msi armor oc 1070s and they are getting a combined 247 mh/s (30.875 mh/s each) at 90% tdp, +150 core (~2020Mhz) , -1000 mem.  Temps ranging between 60-66c.

I'm using cwigm 0.9.8.  I'm happy with the results.  Nice job with the miner.  Impressed

[Mapuo]

0.5 mh/s up. Mining great(better than 0.9.7.1) for now.

[abudfv2008]

It's from too high sher diff. For some hidden reason, no one want change this...

No it is not.

Yes it is.

High difficulty leads to bigger fluctuations and thats all. But as you can see there are no fluctuations beyond real hashrate. So there are 2 explanations.
1) The reported hashrate is false. We can't check it as far as there is only one pool.
2) Stealing

1) you seem to forget WHO we are and WHAT we do - to even attempt an insult like that concoction of stealing ...

2) IF you have not set the miner to the lodiff port ( using --lodiff ) then you WILL be forced into the hidiff port ( port 6000 ) which starts at diff2.5 and goes upwards from there ... meaning this - if you have more than 4cards ( and we will fix this in future releases ) and you DO NOT add the --lodiff parameter - you are on port 6000 and the diff WILL be too high for your rig to handle and as such - submit less shares tho at high diff rates ...

3) your results and posts of stats are great ... and PROVES that you are submitting VERY high difficulty shares - which is why the pool shows you doing 'less' work by submitted shares ...

4) you have supplied two of the three things that we need ... so - to resolve this without slinging the 'option' of stealing / dirt around - please let us know what your commandline parameters are - so that we can test PROPERLY ...

1) Actually I don't know who you are except you loud words and a nickname on the forum. For me and many others you have only them and nothing more. Just remember it.
2) I already wrote it but of course I set to lowdiff, and received 0.25 at the beginning of the test.
3) As I said before all results were received at difficulty 0.25-1.xxx. Ok fine. Yesterday I put 531Mh/s and the best hashrate that I saw was less then 400. I thought it was a mistake or wrong miner that I downloaded from another guy. Today I downloaded by your link and gave it a try with clean setup. Nothung changed.
4) I think that as far as you own the pool you can check everithing by yourself. But anyway thats it:
cwigm_x86.exe -a skunk -u abudfv2008.Rig5 -p 123 -i 25 --cpu-priority=3 --lodiff
cwigm_x86.exe -a skunk -u abudfv2008.Rig6 -p 123 -i 23,25.5 --cpu-priority=3 --lodiff

P.S. For testing purposes, your miner shows slightly better results than Spmod5. Something like 100vs99. Lase 0.9.8 shows even better results. 72.1 vs 69.5. It would be great to see these results on the pool.

[zer0k]

Awesome work and thank you for the new version
I'll let it run a while and gather some stats, but right off the bat it looks 2-3Mh/s quicker on my 1080 ti FE's!

Can you please rethink removing the api for the next version though?
Some of us like using that for remote monitoring etc.

[chrysophylax]

It's from too high sher diff. For some hidden reason, no one want change this...

No it is not.

Yes it is.

High difficulty leads to bigger fluctuations and thats all. But as you can see there are no fluctuations beyond real hashrate. So there are 2 explanations.
1) The reported hashrate is false. We can't check it as far as there is only one pool.
2) Stealing

1) you seem to forget WHO we are and WHAT we do - to even attempt an insult like that concoction of stealing ...

2) IF you have not set the miner to the lodiff port ( using --lodiff ) then you WILL be forced into the hidiff port ( port 6000 ) which starts at diff2.5 and goes upwards from there ... meaning this - if you have more than 4cards ( and we will fix this in future releases ) and you DO NOT add the --lodiff parameter - you are on port 6000 and the diff WILL be too high for your rig to handle and as such - submit less shares tho at high diff rates ...

3) your results and posts of stats are great ... and PROVES that you are submitting VERY high difficulty shares - which is why the pool shows you doing 'less' work by submitted shares ...

4) you have supplied two of the three things that we need ... so - to resolve this without slinging the 'option' of stealing / dirt around - please let us know what your commandline parameters are - so that we can test PROPERLY ...

1) Actually I don't know who you are except you loud words and a nickname on the forum. For me and many others you have only them and nothing more. Just remember it.
2) I already wrote it but of course I set to lowdiff, and received 0.25 at the beginning of the test.
3) As I said before all results were received at difficulty 0.25-1.xxx. Ok fine. Yesterday I put 531Mh/s and the best hashrate that I saw was less then 400. I thought it was a mistake or wrong miner that I downloaded from another guy. Today I downloaded by your link and gave it a try with clean setup. Nothung changed.
4) I think that as far as you own the pool you can check everithing by yourself. But anyway thats it:
cwigm_x86.exe -a skunk -u abudfv2008.Rig5 -p 123 -i 25 --cpu-priority=3 --lodiff
cwigm_x86.exe -a skunk -u abudfv2008.Rig6 -p 123 -i 23,25.5 --cpu-priority=3 --lodiff

P.S. For testing purposes, your miner shows slightly better results than Spmod5. Something like 100vs99. Lase 0.9.8 shows even better results. 72.5 vs 69.5. It would be great to see these results on the pool.

ok ...

if i sounded very harsh - its not intentionally about being harsh ... its about the idea that we are doing ANYTHING uncouth or underhanded - that is just not what we do ...

the results and figures - thats good ... but the hashrates are not being reflected on the pool? ...

hmmm ... so let me understand this correctly - and lets have a good look at this ...

the miner ( ie any miner you get ) will show the closest to the accurate hashrates due to it being the miner - being local - and being very very quick in determining the hashrates ... after all - its the miner thats producing the hashrates ( or processing cycles ) ...

the pools ( all of the pools ) work differently ... they estimate hashrates by averaging the submitted shares in a certain timeframe ... in this case - 5mins ... the pool estimates the hashrate over this given time using the shares submitted ... there is also another factor - which we are investigating ... there is also a module in the mpos pools that are called 'coin classes' ... these classes need to be built from the ground up - but most are not ...

once we find what class is meant to be built for skunkhash - it will become a more accurate measurement for hashrate on the pool itself ...

but there is the rub ... the stratum is accurate - and its the stratum that submits your shares ... the pool just does its best to measure those shares ... so in effect - you are not losing your hashrate or shares - they are just being displayed incorrectly ... hence the wild fluctuations on most pools in most algos ... but skunkhash is displaying much lower than what the miner is producing ... you are still hashing at the miner rate - but you are correct in saying that it would be nice if the pool displayed the results also - and not lower ...

lets look into this further ...

we appreciate your shedding light on this ...

#crysx

[chrysophylax]

Awesome work and thank you for the new version
I'll let it run a while and gather some stats, but right off the bat it looks 2-3Mh/s quicker on my 1080 ti FE's!

Can you please rethink removing the api for the next version though?
Some of us like using that for remote monitoring etc.

great to see ...

the removal of the current api was a necessary adjustment ...

we need to rebuild the api itself - and couldnt do so easily without the removal of the existing one ...

it is planned to bring it back in - but as to when - that is yet to be seen ... whether it is rebuilt or not though - we will let you know ...

tanx ...

#crysx

[abudfv2008]

the miner ( ie any miner you get ) will show the closest to the accurate hashrates due to it being the miner - being local - and being very very quick in determining the hashrates ... after all - its the miner thats producing the hashrates ( or processing cycles ) ...

the pools ( all of the pools ) work differently ... they estimate hashrates by averaging the submitted shares in a certain timeframe ... in this case - 5mins ... the pool estimates the hashrate over this given time using the shares submitted ... there is also another factor - which we are investigating ... there is also a module in the mpos pools that are called 'coin classes' ... these classes need to be built from the ground up - but most are not ...

once we find what class is meant to be built for skunkhash - it will become a more accurate measurement for hashrate on the pool itself ...

but there is the rub ... the stratum is accurate - and its the stratum that submits your shares ... the pool just does its best to measure those shares ... so in effect - you are not losing your hashrate or shares - they are just being displayed incorrectly ... hence the wild fluctuations on most pools in most algos ... but skunkhash is displaying much lower than what the miner is producing ... you are still hashing at the miner rate - but you are correct in saying that it would be nice if the pool displayed the results also - and not lower ...

lets look into this further ...

we appreciate your shedding light on this ...

#crysx

With new version 0.9.8 everything is fine. The hashrate is correctry reported by the pool.
I put 765Mh/s (Spmod5) and it shows now ~800 which corresponds with increased speed in your miner.
So the problem was with 0.9.7.1
Waiting for more hashrate from a new versions while there is still some time to mine SIGT.
Sorry if you consider me beeing rude. English is not my native language.

[chrysophylax]

the miner ( ie any miner you get ) will show the closest to the accurate hashrates due to it being the miner - being local - and being very very quick in determining the hashrates ... after all - its the miner thats producing the hashrates ( or processing cycles ) ...

the pools ( all of the pools ) work differently ... they estimate hashrates by averaging the submitted shares in a certain timeframe ... in this case - 5mins ... the pool estimates the hashrate over this given time using the shares submitted ... there is also another factor - which we are investigating ... there is also a module in the mpos pools that are called 'coin classes' ... these classes need to be built from the ground up - but most are not ...

once we find what class is meant to be built for skunkhash - it will become a more accurate measurement for hashrate on the pool itself ...

but there is the rub ... the stratum is accurate - and its the stratum that submits your shares ... the pool just does its best to measure those shares ... so in effect - you are not losing your hashrate or shares - they are just being displayed incorrectly ... hence the wild fluctuations on most pools in most algos ... but skunkhash is displaying much lower than what the miner is producing ... you are still hashing at the miner rate - but you are correct in saying that it would be nice if the pool displayed the results also - and not lower ...

lets look into this further ...

we appreciate your shedding light on this ...

#crysx

With new version 0.9.8 everything is fine. The hashrate is correctry reported by the pool.
I put 765Mh/s (Spmod5) and it shows now ~800 which corresponds with increased speed in your miner.
So the problem was with 0.9.7.1
Waiting for more hashrate from a new versions while there is still some time to mine SIGT.
Sorry if you consider me beeing rude. English is not my native language.

o ok ... thats great then ...

not rude at all ... the 'stealing' assumption - we dont take kindly to ... thats all ...

but all good ... we are all here for one purpose - and that is to make the whole mining experience a whole lot better WITHOUT the crap we all get from some other developers / ripoff merchants that actually DO exist ...

btw - your english fine ...

...

#crysx

[zer0k]

Pushing harder with this build and it's looking good so far

[zer0k]

Looking good on my 1060 as well

[preda]

why i dont trust? too many negative feedback?

[tpd09]

is there any monitoring tools or email notifications available?

below my hashes

[zer0k]

is there any monitoring tools or email notifications available?

below my hashes

Turn on the "monitor" on your worker settings