OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[cablepair]

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.

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

--gpu-dyninterval <arg> 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

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.

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

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

[DeathAndTaxes]

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

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.

[cablepair]

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

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.

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

Looking at the higher variance number doesn't make much sense

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

[kano]

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%

[cablepair]

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%

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

[kano]

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

[DeathAndTaxes]

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

Let me put it simpler.  Your wrong.  

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)

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.

[The00Dustin]

ck, if you can give me a hint as to how to compile a 32-bit version on a 64-bit linux machine, I can provide cypress kernels for l4 along with l8 from SDK 2.1.

Cannot do. You can only make 32 bit kernels from running on 32 bit OS I'm afraid.

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

[P_Shep]

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

Thank yoooooou

[spiccioli]

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

[The00Dustin]

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.

[P_Shep]

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.

[Diapolo]

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

Are you specifiying any -k switch? You could try -k phatk, -k poclbm, -k diakgcn or -k diablo ... perhaps one of em gives good perfrmance, until Con fixes the current glitch, which seems to come from a rather small change in all kernels.

Dia

[echris1]

cgminer + diablo + p2pool = awesome  

oh, and also ANUBIS, that just makes everything pretty =)

Finally have all the control (fan, clock, etc) without losing any performance or having to fiddle with SDK versions.

Donation sent, keep up the good work.

[-ck]

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

Make sure you're using the slightly upgrade 2.3.0-1

If you still have a hashrate drop like that then you're doing the SDK2.6 dance. cgminer -n will tell me what openCL you're using.

[spiccioli]

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

Make sure you're using the slightly upgrade 2.3.0-1

If you still have a hashrate drop like that then you're doing the SDK2.6 dance. cgminer -n will tell me what openCL you're using.

ckolivas,

tomorrow I'll test it,

this is what cgminer -n says right now:

Code:

[2012-02-23 22:14:58] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2012-02-23 22:14:58] CL Platform 0 name: AMD Accelerated Parallel Processing
[2012-02-23 22:14:58] CL Platform 0 version: OpenCL 1.1 AMD-APP-SDK-v2.5 (793.1)
[2012-02-23 22:14:58] Platform 0 devices: 2
[2012-02-23 22:14:58] GPU 0 ATI Radeon HD 5800 Series hardware monitoring enabled
[2012-02-23 22:14:58] Setting GPU 0 engine clock to 830
[2012-02-23 22:14:58] Setting GPU 0 memory clock to 150
[2012-02-23 22:14:58] Setting GPU 0 voltage to 1.005
[2012-02-23 22:14:58] GPU 1 ATI Radeon HD 5800 Series hardware monitoring enabled
[2012-02-23 22:14:58] Setting GPU 1 engine clock to 830
[2012-02-23 22:14:58] Setting GPU 1 memory clock to 150
[2012-02-23 22:14:58] Setting GPU 1 voltage to 1.005
[2012-02-23 22:14:58] 2 GPU devices max detected

[-ck]

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.

Make sure you're using the slightly upgrade 2.3.0-1

If you still have a hashrate drop like that then you're doing the SDK2.6 dance. cgminer -n will tell me what openCL you're using.

ckolivas,

tomorrow I'll test it,

this is what cgminer -n says right now:

Code:

[2012-02-23 22:14:58] CL Platform 0 version: OpenCL 1.1 AMD-APP-SDK-v2.5 (793.1)

All good, you're on 2.5. You probably got the dud kernel in the first packaged release which is why I upgraded to 2.3.0-1

I'll probably release a 2.3.1 pretty soon today, reverting a few of the kernel changes that were dubious and based on what diablo and others said. I should have trusted myself 

[-ck]

cgminer + diablo + p2pool = awesome  

oh, and also ANUBIS, that just makes everything pretty =)

Finally have all the control (fan, clock, etc) without losing any performance or having to fiddle with SDK versions.

Donation sent, keep up the good work.

Thanks much appreciated. 

[The00Dustin]

ck, was the change in 2.3.0-1 for phatk?  I assumed it was, but noticed the kernel version number didn't change (unless I eyed it wrong), if my observation is correct, then anyone who downloaded 2.3.0 and then 2.3.0-1 would not get a new kernel if the 2.3.0(not-1) kernel was there already with the same name.

[-ck]

ck, was the change in 2.3.0-1 for phatk?  I assumed it was, but noticed the kernel version number didn't change (unless I eyed it wrong), if my observation is correct, then anyone who downloaded 2.3.0 and then 2.3.0-1 would not get a new kernel if the 2.3.0(not-1) kernel was there already with the same name.

Yes, I wanted to rush out the new package to stop people from downloading the original one ASAP so I didn't even change the version number on the kernel which is bad of me I know.