Topic: ### A ChainWorks Industries (CWI) Project - CWIgm | Simple Powerful Stable - page 50. (Read 67732 times)

there seems to be a lot of issue with later drivers ...

earlier ones seem to work better and more stable ...

but that is possibly because nVidia themselves are preparing the code / drivers for the move to CUDA90 ...

the x32 version is compiled in the same machine AND the same format - except 32Bit dependencies ...

will see what happens when the next few version come out ... there will be a couple of changes ...

#crysx

a bit slower but noticeable (2.5% - 3% slower)
but yes, it seems more stable. Im running latest drivers (384.94)

...

pools are a pain - but a necessary pain i think ...

not many can solo at this hashrate ...

bugga - x32 seems to be crashing more often ... im wondering if the driver is causing any issues? ...

x64 is lower hashrate - but much more stable - correct? ...

#crysx

yup - ok ...

then the default intensities really are the highest they should go - with the potential for the higher end cards to be able to push a little more ...

makes sense ...

#crysx

yep i know how it works, no worries here
btw. the x86 miner has completely frozen my computer twice in a row. Going back to the x64 ver

yup ...

at just recently going to about 3gh currently also ...

seen yiimp? ... 13blocks ( one orphan ) at 120GH ...

how lucky do you feel? ...

even hashbag with 21GH only just hit 2blocks and zpool with 12gh hit 4blocks ...

so its sparsely spread - and 'luck' is on no ones side at the moment ...

remember though - that when we DO hit a block - the dividends to each miner is higher ... its just not as often as the higher hashrate pools ... which give a lower dividend - only a little more often due to the pools ... so its about even anyway ... the coin emission is the same network wide - so it really is a 'luck' think ...

the only thing that IS definite - is that the higher the hashrate in a pool - the higher CHANCE of solving a block ... there is still no guarantee ...

#crysx

-i 25 driver crash

more than eleven hours since last block found, the pool is being a bit unlucky

pushing the x64 version with i26 gives the ~81.6 for a 1070 and 1080ti OC both (1080 is founders edition)
i cant push x86 besides default intensity (24) but it gives 2-3Mhs more

at over a terahash ( 1.1TH last i looked ) network hashrate - thats pretty much the base ...

a few hours hashing will not yield very much at all ... when considering the smaller hashrate we have on the pool compared to one or two others that have the majority ...

tho over a day or two - it should bring some blocks in ...

yiimp seems to have the highest hashrate - and only brings in a few blocks with the amount of hashrate they have ...

all par for the course with this ...

when we ( CWI-theFARM ) first started - we were hitting so many blocks SOLO ... now? ... forget it ...

#crysx

those are good figures ...

stability is good ...

but share rate is not ...

we will have a look at the stratum - and see if we can drop the level of aggressive diff change ...

#crysx ...

and again ...

x32 a little faster in hashrate and just as stable as the x64 version - on default intensities ...

what happens when you push them with higher intensities and oc? ...

#crysx

ok ...

thats what we estimated ...

x32 runs faster than x64 - but its surprising that it is not as stable at high intensity ...

tanx ...

#crysx

no worries ...

the main difference with the miners is this ...

nVidia miners have a code it uses ( CUDA ) - and AMD cards have a codebase they use ( OpenCL ) ... they are not interchangeable ... so any miner you use needs to be able to compute these codebases ... which is why most miners are separated by the cards they are designed for ...

nVidia codebase also CAN use OpenCL for computing hashfunctions - but its no where near as efficient as using its CUDA codebase ... which is why you sometimes see one miner that can process for both cards - but usually AMD better than nVidia in OpenCL ...

of course - the nVidia and AMD devs can explain that in MUCH better detail - and obviously a LOT more accurate than i ...

#crysx

I ran two rigs for a while couple of hours ago and earned 0.0000000 SIGT, that does not seen quite right ?

share submission will slow down - yes ...

as the stratum continuously adjusts ( its a little aggressive - but reliable ) the difficulty in the share goes up also - slowing the share submission down ...

higher difficulty shares have more chance of solving - than lower difficulty shares ... but the average should stablaize the longer the stratum has the miner connected and share submission is going ...

thats one of the reasons you see such huge fluctuations in hashrate at times on almost any pool you mine on ... pools work differently to miners for example ... pools average the hashrate - meaning they average the shares submitted between a certain amount of time to get the 'average' hashrate ...

the stratum itself is always adjusting diff - going up to reach its target diff - and going down to do the same ... thats what vardiff ( variable difficulty ) is all about ... so as your miner hashes - stratum adjusts accordingly ... sometimes its a little 'over aggressive' and increases the diff a little too high - but the shares that get submitted are higher difficulty shares at a slower rate ( which is fine ) - and as such - the stratum lowers the diff ... its constant ... all stratums do that - but this one is a custom stratum built for CWI ... it was built to be more robust and react to heavy hashrates much quicker ( its aggressiveness ) and 'ease' back to a lower diff when share submission slows back down ...

but with no invalid shares - CWIgm is doing well and the sigt daemon is running perfectly currently ...

#crysx

yup ...

shares are higher difficulty after a while depending on how much hash you have - with network difficulty playing a part in this also ..

the hashrate itself per card will never be the same at any one time or another - but the deviance 'shouldnt' be massive swings ... the share hashrate ( the yes! ) will show you the overall combined hashrate that the share had when it was submitted ...

you will find that the individual hashes per card do swing tho ...

#crysx

tanx ...

a number of algos are slated tho it will be a process we dont take lightly ...

the skunkhash algo was the initial - and testing is ongoing for the time being ...

#crysx

ok ...

so at higher intensity - all good on x64 ...

but unstable with the x32 binary on high intensity - does it run ok at default intensity on x32? ...

#crysx

you know - that actually pretty good ...

we are a little surprised by that - even though we knew it would work - as CWIgm was not really designed for the maxwell cards ... especially on cuda80 ...

is it the x32 or x64 binary you are using? ...

#crysx