Bitcoin Forum
December 08, 2016, 04:11:22 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 [212] 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4823181 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
kentrolla
Hero Member
*****
Offline Offline

Activity: 504


View Profile
February 23, 2012, 02:29:10 PM
 #4221

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

1481213482
Hero Member
*
Offline Offline

Posts: 1481213482

View Profile Personal Message (Offline)

Ignore
1481213482
Reply with quote  #2

1481213482
Report to moderator
1481213482
Hero Member
*
Offline Offline

Posts: 1481213482

View Profile Personal Message (Offline)

Ignore
1481213482
Reply with quote  #2

1481213482
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481213482
Hero Member
*
Offline Offline

Posts: 1481213482

View Profile Personal Message (Offline)

Ignore
1481213482
Reply with quote  #2

1481213482
Report to moderator
1481213482
Hero Member
*
Offline Offline

Posts: 1481213482

View Profile Personal Message (Offline)

Ignore
1481213482
Reply with quote  #2

1481213482
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 23, 2012, 02:35:33 PM
 #4222

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

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. 
Vbs
Hero Member
*****
Offline Offline

Activity: 504


View Profile
February 23, 2012, 02:57:33 PM
 #4223

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...  Tongue
cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
February 23, 2012, 02:58:21 PM
 #4224

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 23, 2012, 03:04:30 PM
 #4225

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
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
February 23, 2012, 03:14:33 PM
 #4226

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

Quote
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 Smiley - 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
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
February 23, 2012, 03:30:59 PM
 #4227

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%

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
February 23, 2012, 04:08:16 PM
 #4228

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
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
February 23, 2012, 04:24:43 PM
 #4229

... and I made a mistake Smiley
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)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 23, 2012, 04:33:46 PM
 #4230

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

Quote
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
Hero Member
*****
Offline Offline

Activity: 806


View Profile
February 23, 2012, 04:50:44 PM
 #4231

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.  Wink  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
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
February 23, 2012, 05:50:03 PM
 #4232

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

Thank yoooooou Smiley
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
February 23, 2012, 06:19:19 PM
 #4233

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
Hero Member
*****
Offline Offline

Activity: 806


View Profile
February 23, 2012, 06:31:07 PM
 #4234

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
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
February 23, 2012, 07:23:08 PM
 #4235

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
Hero Member
*****
Offline Offline

Activity: 769



View Profile WWW
February 23, 2012, 08:08:51 PM
 #4236

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

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
echris1
Full Member
***
Offline Offline

Activity: 124


View Profile
February 23, 2012, 09:03:58 PM
 #4237

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
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
February 23, 2012, 09:10:59 PM
 #4238

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
February 23, 2012, 09:16:23 PM
 #4239

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
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
February 23, 2012, 09:19:46 PM
 #4240

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  Wink

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 [212] 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!