may i ask a question?
http://imgur.com/nqvoz8N
what is the "Job not found" and "Invalid nonce" means?
and my bat is
cwigm -c sigt -u pp688039.pp688039 -p x --lodiff --max-temp=70
pause
thanks
Topic: ### A ChainWorks Industries (CWI) Project - CWIgm | Simple Powerful Stable - page 27. (Read 67732 times)
August 13, 2017, 06:15:50 AM
August 13, 2017, 05:37:57 AM
Try without --lodiff
August 13, 2017, 04:35:42 AM
My bat file:
Code:
timeout \t 5
cwigm -c sigt -u username.Miner03 -p x --lodiff --max-temp=75
pause
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.
But that is not the reason the pool shows no mining. The pool shows my hashrate at 0 even my miner is on and running.
August 13, 2017, 03:08:46 AM
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.
August 13, 2017, 02:41:56 AM
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?
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
August 13, 2017, 02:34:33 AM
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
August 13, 2017, 02:31:50 AM
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?
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
August 13, 2017, 02:27:17 AM
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?
with 70% tdp i get nearly 30MH per gpu, you are going to make it work wth any pool after the beta ends right?
August 13, 2017, 02:21:53 AM
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!
August 13, 2017, 02:10:23 AM
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!
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
August 13, 2017, 01:19:29 AM
August 13, 2017, 01:14:51 AM
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!
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
August 13, 2017, 01:01:10 AM
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!
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
August 13, 2017, 12:39:12 AM
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
August 12, 2017, 11:34:35 PM
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.
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
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.
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.
PL 70, core +150, mem -502, fan 75, intensity 24
but why on other miner they're stable?
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
August 12, 2017, 11:24:59 PM
what happened to pool site cant login...
August 12, 2017, 11:06:47 PM
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?
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?
August 12, 2017, 10:53:35 PM
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.
PL 70, core +150, mem -502, fan 75, intensity 24
but why on other miner they're stable?
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....
August 12, 2017, 10:39:51 PM
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.
PL 70, core +150, mem -502, fan 75, intensity 24
but why on other miner they're stable?
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
August 12, 2017, 10:29:31 PM
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.
PL 70, core +150, mem -502, fan 75, intensity 24
but why on other miner they're stable?
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.
Jump to: