hello, this miner is for sell? or I can download somewere this miner?
thanks
Topic: ### A ChainWorks Industries (CWI) Project - CWIgm | Simple Powerful Stable - page 43. (Read 67732 times)
August 07, 2017, 10:30:44 PM
August 07, 2017, 08:03:49 PM
I just started testing out Denarius (DNR) mining at ChainWorks. First off I love the miner interface, has all the vital stats and color coded. My approximate speeds are:
Nvidia 1070 54 Mh/S
Nvidia 1080 75 Mh/S
Nvidia 1080Ti 92 Mh/s
These are slightly overclocked results, but I am very happy. Miners, come join in, we need the pool a little larger and you get faster hash rates then the standard public miner!
Nvidia 1070 54 Mh/S
Nvidia 1080 75 Mh/S
Nvidia 1080Ti 92 Mh/s
These are slightly overclocked results, but I am very happy. Miners, come join in, we need the pool a little larger and you get faster hash rates then the standard public miner!
August 07, 2017, 04:23:27 PM
is there any monitoring tools or email notifications available?
below my hashes
below my hashes
Turn on the "monitor" on your worker settings
ty
August 07, 2017, 04:22:07 PM
is there any monitoring tools or email notifications available?
below my hashes
below my hashes
Turn on the "monitor" on your worker settings
August 07, 2017, 04:20:31 PM
is there any monitoring tools or email notifications available?
below my hashes
below my hashes
August 07, 2017, 03:44:17 PM
why i dont trust? too many negative feedback?
August 07, 2017, 03:34:48 PM
Looking good on my 1060 as well
August 07, 2017, 02:52:13 PM
Pushing harder with this build and it's looking good so far 
August 07, 2017, 02:37:47 PM
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.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
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
August 07, 2017, 02:33:10 PM
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.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
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.
August 07, 2017, 01:35:39 PM
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.
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
August 07, 2017, 01:30:29 PM
It's from too high sher diff. For some hidden reason, no one want change this...
No it is not.Yes it is.
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 ...
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
August 07, 2017, 12:48:43 PM
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.
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.
August 07, 2017, 12:23:53 PM
It's from too high sher diff. For some hidden reason, no one want change this...
No it is not.Yes it is.
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 ...
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.
August 07, 2017, 11:52:23 AM
0.5 mh/s up. Mining great(better than 0.9.7.1) for now.
August 07, 2017, 11:46:18 AM
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
August 07, 2017, 11:39:22 AM
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.
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.
August 07, 2017, 11:04:23 AM
File identification
MD5 0cdf14aa526fe94193de9e5224dc5c04
Not match
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
August 07, 2017, 10:56:55 AM
File identification
MD5 0cdf14aa526fe94193de9e5224dc5c04
Not match
MD5 0cdf14aa526fe94193de9e5224dc5c04
Not match
August 07, 2017, 10:25:21 AM
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
Jump to: