Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 637. (Read 5805546 times)

... and I made a mistake
I might as well correct it:

Shares are 'difficulty' more likely, not 2^32

So current difficulty is 1376302.2678864, so they are approx 1.4million times more likely (not 4.3billion times)

an explanation from someone I know for a fact is smarter than I am !
 
I understand exactly what everyone is saying and I already knew that shares and mhash are a function of each other, I dont think mhash comes from some magical place - i get it dude I really do!

let me put it real simple - you guys are too smart for your own good you over intellectualize everything

all I was trying to say is (again yes I know its a function of mhash) the shares are what matters, the shares are what pays the electric bill, the shares are what makes this all worth while - I have found in my personal experience it is more helpful to really pay attention to the amount of shares you are submitting on any given day than to totally focus on the mhash, mhash can be deceiving at times (yes I know it all evens out) - has anyone ever been watching cgminer when the pool goes hay wire (happens a lot with pools that pool hop or share selling service) and all of the sudden that 5870 that was just humming along nicely went from showing 435.5/429.3MH/s is now showing 730.3/239.2MH/s and no shares are getting through at all? ok yeah its all a function of mhash it will even out eventually but right now in that moment the only thing I care about is am I making money? because obviously the fact that now my 5870 is magically giving me 700 mhash on a single thread its costing me money and not making me any (no shares = no money)

one thing I find interesting, I know that everything in the bitcoin world when it comes to mining, hashrates, network speed, solved blocks, difficulty whatever it all evens out at the end - its just such a perfectly designed thing where everything balances out given enough time - however as pretty and perfect as that is there are a lot of individual variables that people experience every day - because as individual miners we have hard ware failures and power outages and we tweak things and change things and break things - I know mathematically everything is perfect but in real life things can very a great deal.
 
thank you kano for that I am not sure anyone else could of put it so eloquently

Accepted share rate (U:) is a function of your MH/s

If you double your MH/s you will (very) roughly double your U:
If you halve your MH/s you will (very) roughly halve your U:

Due to the statistical variance of pseudo random events (find a share), the relationship between the two is not exact.

The easiest way to think of it is exactly the same as blocks in the block-chain - that everyone should already know but I'll repeat:
The average is about 1 every 10 minutes but they often appear 800% of that (80 minutes)
(or even as quickly as 'seconds')
Thus over a very long period of time if the network hash power never changed, you would expect it to average out to 10 minutes per block

A share is the same with ONLY one difference: in a normal pool they are 2^32 times more likely.

Thus your U: can jump around in the same manner - but it is related to the hash rate in the same way as the block-chain block time is related to the world network hash rate (until the next difficulty change)

What this all means is that yes you're U: will jump around following behind your MH/s

HOWEVER, your U: is the average over all time (since cgminer started) so it does not change as quickly as your MH/s (5s)

Edit: though I have not done the mathematics to prove it in any way, I find with my measly 725MH/s that it takes about an hour to get a reasonable estimation of U: that is within about +/-10%

if I am wrong than I stand corrected - but before I can believe that please explain this

I change -I 9 to -I d

(a) CGMINER disables threads
(b) the mhash does NOT change
(c) less shares are being sent to the pool

<---- I have no idea what your point is here

I mean really when it comes down to it as a miner (which I am), what is the #1 metric you are looking for accepted shares

you dont get paid by mhash you get paid by the amount of accepted shares you are submitting, so why on earth (when deciding how to configure your miner) would the mhash be more important than the amount of accepted shares?

edit:  by the way you talk you are probably much smarter than I am - but I am a common sense kind of guy - and the bottom line here is $$$ not the amount of nonces hashed in a second

That is not correct.  MH/s is the number of actual nonces hashed in the last second.  Shares is going to be subject to more variance.  Both are equally affected by intensity.  Looking at the higher variance number doesn't make much sense.

when playing with intensities in cgminer its more important to compare amount of accepted shares in a given time than mhash. If threads are disabled due to lower intensity your going to be sending less shares and still running at the same speed so thats the metric you should be looking at

Thanks for the explanations guys. I'll play a bit with the kernel when I have some free time, if I get any improvement I'll tell. I have experience with C but not much with OpenCL, but I'll probably have to get into it for my job... 

I just noticed you are using a 4850 to mine and drive the desktop.  That is kinda an edge case.  The computational power on the 4850 is so low (relatively speaking) that it is likely outside the bounds of any adjustment calculations. 

hmm, my friend with a 5870 is saying that --gpu-dyninterval does effect his intensity. but for me, it seems to do nothing at all. with gpu-dyninterval 1 i still have lag in windows but if i use intensity -2 the lag goes away and i only lose about 5mh/s.  i guess ill stick to just using static intensity for now

That is true, I thought it would be better the above way, but think about it ... most of the time only 1 branch is checked and therefore processed. If you always check 2 branches, this will slow things down. It has to be mentioned, that if in a work-group, let's
say of size 256, a positive nonce is found, all 3 branches are checked and this slows down execution of ALL work-items in that particular work-group. So because a positive nonce is seldom, Cons current approach is the right one.

I found out in internal tests with diakgcn, that any() is indeed slower :-/.

Dia

It's a fairly sensitive tuning tool. The difference between the default 7 and 1 should be quite significant to the interface. Don't get too hung up on what the intensity setting reported is since that's done once every 5 seconds but at dyninterval of 1 the value is updated 1000 times per second. 1 is very interactive desktop with lower hashrate, 1000 for example is higher hashrate less dynamic dekstop.

To save ckolivas from more frustration maybe I can help.

vbs:  AMD (and I assume Nvidia) GPU take a horrible hit on branches.  The number of total checks is irrelevant.  What matters is the number of branches on the main path.

Only one in 4.3 billion hashes will be a share thus 99.999999976716935634613037109375% of the time any subsequent share checks are never executed.  Optimizing the path which occurs one in 4.3 billion executions is silly right?

We want to make the one that occurs 4.29999999999 billlion out of 4.3 billion attempts as fast as possible.  Given the massive (and I do mean massive forget what you think you know about C++ compilers on x86 hardware) hit that AMD GPU take when it comes to branches that means making the main path have as few branches as possible. 

Neither of your code snippets do that.

--gpu-dyninterval Set the refresh interval in ms for GPUs using dynamic intensity

i've been playing with this and i guess i just don't understand how it works. when i set it to 20 it stays at 4 intensity and when i set it to 1 it goes back and forth between 3 and 4 intensity.  so there is a difference between --gpu-dyninterval 1 and --gpu-dyninterval 20 but its barely even noticeable and you can't use negative numbers.  i have a radeon 4850 btw

Heh, you're not a coder are you? That's still two branches unless it's positive on the first branch.

Ok, one unrolled branch then! 

Updated the 2.3.0 package with -1 extension which includes a fixed phatk kernel. Links in top post. This shouldn't affect other kernels...

If it ends up affecting other kernels, I'll have to release a full new version tomorrow.

lol
ty

Read what it says at startup when you run dynamic intensity... sigh.

awesome update. the new kernel gives me a +2% increase in mh/s.  
i have a suggestion.
i like how you can set the intensity to d and it changes the intensity to maintain desktop interactivity. but its just a little bit too intense for me in windows but is perfect while playing world of tanks (weird, i thought gaming would be more intense)  so i keep having to change the intensity depending on what i'm doing.

my suggestion is that you make an option to set the intensity to d -2  or d -1  or something. so the intensity is still dynamic but is 1 or 2 less (or more) than d.
some people might want to use d +1 or d +2. who knows?  for me, intensity of d -1 would be perfect.

Yeah and people were bashing me when I was screaming Nvidia.

ATI will probably never fix these bugs in their SDK and drivers.

CPU bug, SDK 2.6, 8 GPU hardcoded limit, needs to be linked to xserver at all times.

If only Nvidia would wake up and see that we are waiting for the 4608 shader dual GPU.

Hopefully the integer performance is much better this time around and they implement a variation of BFI_INT or bitalign.

So when will you release the fixed cgminer ?

Thank you !