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

Enabling / disabling pools via the API... how do we know the current state?
Presumably, status=alive tells us if we can communicate with the pool, and not that it enabled.

My 5830 doesn't appear to have dropped at all.  If it did, it dropped 5 MH/s from 318 to 313, but my U looks really good for now, so I doubt it was 318 before (but that's only on 380 shares, so U doesn't mean much yet, as was just discussed).  I am running 2.3.0-1 with phatk (default for cypress) -w256 -v2.  You may not be having SDK 2.6 issues, but I wish cgminer could tell which SDK a kernel was compiled with since said issues seemingly haven't gone away yet.

I've just tested 2.3.0 on a dual underclocked/undervolted 5870s rig and I went from 370 down to 330 MH/s per card.

This is with -g 1 --submit-stale -I 6

spiccioli

Can BFL (or more generically, FPGA) count be added to the API?

Thank yoooooou

The answer I was looking for was add -m32 to CFLAGS, but that's OK, I found it.    Also, after doing that I did have to change LFLAGS to point at the 32bit version of the SDK, and this still wouldn't have worked if I didn't have all of the 32-bit libraries installed as well, so I guess the answer you should have given me was "Cross compiling isn't supported in my configure script, but you can try adding -m32 to CFLAGS, YMMV."

Let me put it simpler.  Your wrong.  


Couple points:

1) If a pool going haywire retroactively changes your avg since start well you got a lot bigger problems.  The second number is hashrate since start it is # of hashes / elapsed time.  So after 20-30 min in it shouldn't change significantly within a few seconds.

2) That has nothing to do with intensity.  If you change intensity it will change mhashes.  It will also change shares BUT shares rate ("U:") has roughly 4 magnitudes more variance for a given time period.

So looking at share rate in the short term may mean you are simply looking at noise.

For example
start cgminer -let it run 2 minutes check U rate.
now stop cgminer
fart, yes far.
start cgminer -let it run 2 minutes check U rate.

Tada farting must affect share rate. It is entirely possible the two values will differ by 20% or more.  Farting (or lack of farting) boosts share rates 20%!  

So you seeing a major change in share rate doesn't mean anything unless you are waiting a very very very long time.  Share rate (U) really only stabilizes after 10K or so shares.  I would say 20K to 50K would be better.  So unless you are setting intensity and waiting half a day to make sure the results are valid using share rate in the short term is useless.

Of course none of this has anything to do with your original claim.
If you change intensity you should see a change in MH/s.  Period.  If you aren't then something is wrong.  If a pool goes offline and that retroactively changes your prior MH/s average (yes the second # is the average since starting) then something is wrong.  You shouldn't rely on your conclusions for anything.

... 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.