Bitcoin Forum
December 11, 2016, 04:31:48 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 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 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4827809 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.
mmortal03
Legendary
*
Offline Offline

Activity: 1395


View Profile
February 05, 2012, 06:05:01 AM
 #3561

Also, on a related note, maybe your processor can get 8MH/s and the 8MH/s extra isn't even coming from the video card.  If that is the case, cutting the CPU frequency in half would lower it to a 4 MH/s gain at a still much more expensive MH/W (although realistically, even if it is the GPU getting that, running the CPU 100% at half frequency will probably still draw enough power to make it a net loss).

Are you theorizing that my CPU is explicitly doing some of the work, as if I was CPU mining, or do you mean something more nuanced than that? I didn't think my CPU would be used for explicit mining unless I had it specifically enabled to do so. I'm carrying out the U experiments that you guys suggested as we speak, btw.
1481430708
Hero Member
*
Offline Offline

Posts: 1481430708

View Profile Personal Message (Offline)

Ignore
1481430708
Reply with quote  #2

1481430708
Report to moderator
1481430708
Hero Member
*
Offline Offline

Posts: 1481430708

View Profile Personal Message (Offline)

Ignore
1481430708
Reply with quote  #2

1481430708
Report to moderator
1481430708
Hero Member
*
Offline Offline

Posts: 1481430708

View Profile Personal Message (Offline)

Ignore
1481430708
Reply with quote  #2

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

Posts: 1481430708

View Profile Personal Message (Offline)

Ignore
1481430708
Reply with quote  #2

1481430708
Report to moderator
gnar1ta$
Donator
Hero Member
*
Offline Offline

Activity: 756


View Profile
February 05, 2012, 06:06:31 AM
 #3562

That rig runs fairly cool so I'll try overnight without auto-fan.  Here is the rest of the errors from 2.2.1 sessions - I just lowered clock speeds for the different sessions.

Code:
[2012-02-02 18:22:19] Thread 1 idle for more than 60 seconds, GPU 1 declared SICK!
[2012-02-02 18:22:19] Attempting to restart GPU
[2012-02-02 18:22:19] Thread 2 still exists, killing it off
[2012-02-02 18:22:19] Thread 3 still exists, killing it off
[2012-02-02 18:22:19] Thread 2 restarted
[2012-02-02 18:22:20] Thread 3 restarted
[2012-02-02 18:22:21] Accepted 00000000.40372a1e.d75ae9ba GPU 0 thread 0 pool 0
[2012-02-02 18:22:21] Thread 2 being disabled
[2012-02-02 18:22:21] Thread 3 being disabled

[2012-02-02 17:58:17] Thread 3 idle for more than 60 seconds, GPU 3 declared SICK!
[2012-02-02 17:58:17] Attempting to restart GPU
[2012-02-02 17:58:17] Thread 6 still exists, killing it off
[2012-02-02 17:58:17] Thread 7 still exists, killing it off
[2012-02-02 17:58:18] Thread 6 restarted
[2012-02-02 17:58:19] Thread 7 restarted

[2012-02-03 21:19:13] Thread 4 still exists, killing it off
[2012-02-03 21:19:13] Thread 5 still exists, killing it off
[2012-02-03 21:19:14] Thread 4 restarted
[2012-02-03 21:19:14] Accepted 00000000.0cd03974.6e1c40e3 GPU 0 thread 1 pool 0
[2012-02-03 21:19:14] Thread 5 restarted
[2012-02-03 21:19:15] Thread 4 being disabled
[2012-02-03 21:19:16] Thread 5 being disabled

[2012-02-03 20:47:14] Thread 2 idle for more than 60 seconds, GPU 2 declared SICK!
[2012-02-03 20:47:14] Attempting to restart GPU
[2012-02-03 20:47:14] Thread 4 still exists, killing it off
[2012-02-03 20:47:14] Thread 5 still exists, killing it off
[2012-02-03 20:47:14] Thread 4 restarted
[2012-02-03 20:47:15] Accepted 00000000.b422fb13.d18b69ee GPU 1 thread 3 pool 0
[2012-02-03 20:47:15] Thread 5 restarted
[2012-02-03 20:47:15] Accepted 00000000.8db73352.22b376e6 GPU 0 thread 1 pool 0
[2012-02-03 20:47:16] Thread 4 being disabled
[2012-02-03 20:47:16] Thread 5 being disabled

[2012-02-04 17:29:18] Thread 2 idle for more than 60 seconds, GPU 2 declared SICK!
[2012-02-04 17:29:18] Attempting to restart GPU
[2012-02-04 17:29:18] Thread 4 still exists, killing it off
[2012-02-04 17:29:18] Thread 5 still exists, killing it off
[2012-02-04 17:29:19] Thread 4 restarted
[2012-02-04 17:29:19] Thread 5 restarted
[2012-02-04 17:29:20] Thread 4 being disabled
[2012-02-04 17:29:20] Thread 5 being disabled

Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
February 05, 2012, 09:00:30 AM
 #3563

The pool where donations were going was hacked and I'm considering moving all my shares to p2pool as well now. I have grave concerns about centralising work to pools and increasingly see p2pool - or something like it - as the solution for bitcoin's future strength, going back to its decentralised nature as its strength. This means I won't realistically have a way of accepting small hashrate contributions donations with --donation that I can reasonably support. So after much angst I have decided that I will be deprecating the donations feature in upcoming versions and go back to the previous donation model of as-and-when you feel like it.

I thank those who have used the --donation feature greatly till now. It averaged around 400Mh/s over that time and at least kept me "mining" while my own mining rig was dead for over a month.

I recommend people disable --donation now and restart their miners for I don't know what will happen to hashes going to the pool during this instability (it is going offline for 24+ hours likely).

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

Activity: 868


luck is just a share away


View Profile
February 05, 2012, 09:03:46 AM
 #3564

The pool where donations were going was hacked and I'm considering moving all my shares to p2pool as well now. I have grave concerns about centralising work to pools and increasingly see p2pool - or something like it - as the solution for bitcoin's future strength, going back to its decentralised nature as its strength. This means I won't realistically have a way of accepting small hashrate contributions donations with --donation that I can reasonably support. So after much angst I have decided that I will be deprecating the donations feature in upcoming versions and go back to the previous donation model of as-and-when you feel like it.

I thank those who have used the --donation feature greatly till now. It averaged around 400Mh/s over that time and at least kept me "mining" while my own mining rig was dead for over a month.

I recommend people disable --donation now and restart their miners for I don't know what will happen to hashes going to the pool during this instability (it is going offline for 24+ hours likely).


+1 for choosing p2pool!
i never used --donation anyways Wink but had send you some btc some month ago.
Peao
Sr. Member
****
Offline Offline

Activity: 431



View Profile
February 05, 2012, 11:45:12 AM
 #3565

I use these flags
Code:
-I 8 --gpu-engine 950,850,830,950 --gpu-memclock 850,180,180,850  --auto-fan --temp-target 75 --temp-overheat 82

How do I check it's detecting right?  It lists in the same order as 2.1.2. --gpu-reorder worth checking?
I can't see anything wrong with that. Without --gpu-reorder it uses the same order as 2.1.2 would have detected. I guess you'd know pretty quickly if it was setting the wrong speed on the wrong device and...

[2012-02-05 00:01:17] GPU 0 AMD Radeon HD 6800 Series hardware monitoring enabled
[2012-02-05 00:01:17] GPU 1 ATI Radeon HD 5900 Series hardware monitoring enabled
[2012-02-05 00:01:17] GPU 2 ATI Radeon HD 5900 Series hardware monitoring enabled
[2012-02-05 00:01:17] GPU 3 AMD Radeon HD 6800 Series hardware monitoring enabled

looks pretty convincing. So I'm at a loss for why it should be any worse.

Note also that you are having it being disabled and reading OFF. There is only one place in the code where cgminer does this itself - when it hits the thermal cutoff limit. Now it is possible there is some code convolution issue going on somehow that makes the fan not rise when one of the GPUs is being restarted. Note that your bug report shows thread 2 being idle (which would be GPU 1) and then it proceeds to disable threads 4 and 5 (being GPU 2)... Interesting... I'll audit the code, but perhaps try it without auto-fan on, setting what you know to be a safe static fan speed and see if the problem persists.

ck, I'm having the same "OFF" problem described, in rigs with 5970 and 5870:

https://bitcointalk.org/index.php?topic=28402.msg727748#msg727748

The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
February 05, 2012, 11:51:54 AM
 #3566

Also, on a related note, maybe your processor can get 8MH/s and the 8MH/s extra isn't even coming from the video card.  If that is the case, cutting the CPU frequency in half would lower it to a 4 MH/s gain at a still much more expensive MH/W (although realistically, even if it is the GPU getting that, running the CPU 100% at half frequency will probably still draw enough power to make it a net loss).
Are you theorizing that my CPU is explicitly doing some of the work, as if I was CPU mining, or do you mean something more nuanced than that? I didn't think my CPU would be used for explicit mining unless I had it specifically enabled to do so. I'm carrying out the U experiments that you guys suggested as we speak, btw.
Only as one (very unlikely) possibility.  I have read that the 100% cpu bug is because AMD offloads some of the work to the processor to make a game run even faster (so why couldn't it do the same thing with hashing), but I have also read that it is how AMD was making sure the processor was instantly ready when the video card finishes its task (in which case it wouldn't be doing that).
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
February 05, 2012, 12:02:49 PM
 #3567


Note also that you are having it being disabled and reading OFF. There is only one place in the code where cgminer does this itself - when it hits the thermal cutoff limit. Now it is possible there is some code convolution issue going on somehow that makes the fan not rise when one of the GPUs is being restarted. Note that your bug report shows thread 2 being idle (which would be GPU 1) and then it proceeds to disable threads 4 and 5 (being GPU 2)... Interesting... I'll audit the code, but perhaps try it without auto-fan on, setting what you know to be a safe static fan speed and see if the problem persists.

ck, I'm having the same "OFF" problem described, in rigs with 5970 and 5870:

https://bitcointalk.org/index.php?topic=28402.msg727748#msg727748


I have a theory as to how this might be happening now, and it involves cards that may well be getting sick occasionally, and have committed some code to the git tree for it. It would be interesting for you to run your cards with the old version overnight that doesn't have this problem, and then after it has run for an extended period, go into the GPU menu and see if any of the GPUs have been re-initialised at any time or if the "Last initialised" time is close to the main "Started" time at the top.

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

Activity: 518



View Profile
February 05, 2012, 12:38:54 PM
 #3568

Stability testing continuing. Will post some updates soon but I need to do the benchmarking and stability testing.
Vbs
Hero Member
*****
Offline Offline

Activity: 504


View Profile
February 05, 2012, 12:58:44 PM
 #3569

I had two rigs today with "dead" status on the gpu's (5850's on win x64), with error messages saying "Failed to reinit GPU thread" and "Thread <#> no longer exists" on 2.2.1. The strange thing is that it seems to have actually happened at the same time in both rigs (they were mining on the same pool, different workers, reported both dead for 10h). Could this be related to some pool communication bug?
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
February 05, 2012, 01:09:19 PM
 #3570

I had two rigs today with "dead" status on the gpu's (5850's on win x64), with error messages saying "Failed to reinit GPU thread" and "Thread <#> no longer exists" on 2.2.1. The strange thing is that it seems to have actually happened at the same time in both rigs (they were mining on the same pool, different workers, reported both dead for 10h). Could this be related to some pool communication bug?
Yep, it sure could.

(no, I have no idea where or how though)

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

Activity: 72


View Profile
February 05, 2012, 03:17:33 PM
 #3571

Im runnung Debian 6...

I gave up messing with init scripts that start screen sessions and put this in my /etc/rc.local instead
Code:
su - user -c "/path/to/cgminer/start/script.sh"

Quote
Oh, and i use command line arguments, because either on windows or linux, even after saving the config, it ignores me Sad (cgminer always asks for input)

This is usually because you have a syntax error in your config.  You can see what the errors are if you specify the config.

Code:
cgminer -c ~/.cgminer/cgminer.conf

I don't know why it is built this way.  IMO, when you fail to parse a config, you should fail out, not act like there was no config.

Thx about the config, i fixed it, much nicer now XD

--
Putting

Code:
su - rcocchiararo -c "/home/rcocchiararo/bitcoin/startcg.sh"

in rc.local seems to do nothing.

Running that from a "root terminal" (inside rcocchiararo GUI loggin) nets me a CPU mining session

Code:
[2012-02-05 12:18:17] Error: Getting Device IDs (num)
[2012-02-05 12:18:17] clDevicesNum returned error, none usable
[2012-02-05 12:18:17] Started cgminer 2.1.2

My script has:

Code:
#!/bin/bash
export AMDAPPSDKROOT=/opt/AMD-APP-SDK-v2.4-lnx32/
export AMDAPPSDKSAMPLESROOT=/opt/AMD-APP-SDK-v2.4-lnx32/
export LD_LIBRARY_PATH=${AMDAPPSDKROOT}lib/x86:${LD_LIBRARY_PATH}

export DISPLAY=:0

cgminer 2>>/var/log/cgminer.log


Maybe something from my "exports" is not ok ? i mean, just running "cgminer" from a terminal with my user (rcocchiararo) makes it work. (i once had the exports in .bashrc, but i no longer do).

also, i believe, at least on my debian system, it wont work to have that in rc.local, because it would be similar to double clicking my script and telling it to "run" instead of "run in terminal". If i do that, this is what happens:

Code:
[2012-02-05 12:02:55] Started cgminer 2.1.2
[2012-02-05 12:02:56] Long-polling activated for http://pit.deepbit.net:8332/listenChannel
Error opening terminal: unknown.

I tried using rc.local to launch screen, but similar things happen, i THINK i got it to run, but it was only with CPU (manually i can confirm it, unless i run it from my users terminal).

Maybe the fact that root is unable to login with GUI in debian (at least debian 6) causes cgminer some headaches ?

I tried:

Code:
su - rcocchiararo -c "/usr/bin/screen -dmS Miner /home/rcocchiararo/bitcoin/startcg.sh rcocchiararo"

Still, the last "rcocchiararo" seems to do nothing, because i changed that to "pepe" and i even ran:

Code:
/usr/bin/screen -dmS Miner /home/rcocchiararo/bitcoin/startcg.sh pepe

And the user who was running cgminer according to "top" was the one who launched the command (rcocchiararo, not pepe).

Im runnung Debian 6

With the following script, i understand that i get the same thing you indicated:

Code:
#! /bin/sh
### BEGIN INIT INFO
# Provides:          cgminer
# Required-Start:    $all
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: mining
# Description:       Start BTC Mining
### END INIT INFO

script
  sleep 15
  cd /home/rcocchiararo/bitcoin
  exec /usr/bin/screen -dmS Miner su -c /home/rcocchiararo/bitcoin/startcg.sh rcocchiararo
end script

This won't work as a sh script because the script keyword is an Upstart conf file function. You would want to take out both script/end script. I don't know offhand if Debian has Upstart but if it does then the best practice would be to use that by putting this as a conf file in /etc/init. If it doesn't then you could rewrite it as a script by removing the "script / end script" and taking out exec so it just calls screen. I don't think exec is a sh command either. Upstart conf file is not the same as a script.

The cgminer config writer doesn't write a fully working config unfortunately. You have to tweak some values - particularly zero ones. My version here does actually write a working config even with engine/memory values that work. But my version of the code is considered too dangerous by ckolivas to include in the mainline since it reads current ADL values to put in the config. There may be instances/cards where it causes problems - for my 5830s it works ok.

I thought that might be the case, thats why i tried with and without script/exec, and i still failed Sad

-------------

EDIT: success!

Finally, by setting a "startup application" to run:

Code:
/usr/bin/screen -dmS Miner /home/rcocchiararo/bitcoin/startcg.sh rcocchiararo

Now my home server mines after rcocchiararo auto logins (that was already configured, but without screen, i had the "no terminal" issue.
gnar1ta$
Donator
Hero Member
*
Offline Offline

Activity: 756


View Profile
February 05, 2012, 04:35:29 PM
 #3572

Note also that you are having it being disabled and reading OFF. There is only one place in the code where cgminer does this itself - when it hits the thermal cutoff limit. Now it is possible there is some code convolution issue going on somehow that makes the fan not rise when one of the GPUs is being restarted. Note that your bug report shows thread 2 being idle (which would be GPU 1) and then it proceeds to disable threads 4 and 5 (being GPU 2)... Interesting... I'll audit the code, but perhaps try it without auto-fan on, setting what you know to be a safe static fan speed and see if the problem persists.

Running 10+ hours without auto-fan and no errors. I'll update if I get one, but looks promising.

Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 05, 2012, 05:37:16 PM
 #3573

Also, on a related note, maybe your processor can get 8MH/s and the 8MH/s extra isn't even coming from the video card.  If that is the case, cutting the CPU frequency in half would lower it to a 4 MH/s gain at a still much more expensive MH/W (although realistically, even if it is the GPU getting that, running the CPU 100% at half frequency will probably still draw enough power to make it a net loss).
Are you theorizing that my CPU is explicitly doing some of the work, as if I was CPU mining, or do you mean something more nuanced than that? I didn't think my CPU would be used for explicit mining unless I had it specifically enabled to do so. I'm carrying out the U experiments that you guys suggested as we speak, btw.
Only as one (very unlikely) possibility.  I have read that the 100% cpu bug is because AMD offloads some of the work to the processor to make a game run even faster (so why couldn't it do the same thing with hashing), but I have also read that it is how AMD was making sure the processor was instantly ready when the video card finishes its task (in which case it wouldn't be doing that).

No.  No hashing is offloaded to CPU.  If you enable CPU mining it will operate as a seperate OpenCL device.  100% CPU bug isn't work being done it is just clock cycles being wasted.
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
February 05, 2012, 10:36:45 PM
 #3574

Getting funny behaviour disabling a GPU within cgminer from current git:

Code:
GPU 0: 11.9 / 12.4 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:1
64.5 C  F: 30 1.000000E+00: 550 MHz  M: 800 Mhz  V: 1.000V  A: 99% P: 0%
Last initialised: [2012-02-05 23:29:14]
Intensity: 1
Thread 0: 5.8 Mh/s Enabled ALIVE
Thread 1: 6.2 Mh/s Enabled ALIVE

[E]nable [D]isable [I]ntensity [R]estart GPU [C]hange settings
Or press any other key to continue
GPU 0: 11.9 / 12.4 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:1
64.5 C  F: 30 1.000000E+00: 550 MHz  M: 800 Mhz  V: 1.000V  A: 99% P: 0%
Last initialised: [2012-02-05 23:29:14]
Intensity: 1
Thread 0: 5.8 Mh/s Disabled ALIVE
Thread 1: 6.2 Mh/s Disabled ALIVE

[E]nable [D]isable [I]ntensity [R]estart GPU [C]hange settings
Or press any other key to continue
[2012-02-05 23:29:25] Thread 1 being disabled
[2012-02-05 23:29:25] Thread 1 being re-enabled
[2012-02-05 23:29:26] Thread 0 being disabled
[2012-02-05 23:29:26] Thread 1 being disabled

This isn't 100% reproducible so far (happened 4/5 tries) - is this known/expected?

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
February 05, 2012, 11:49:13 PM
 #3575

Getting funny behaviour disabling a GPU within cgminer from current git:

Code:
GPU 0: 11.9 / 12.4 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:1
64.5 C  F: 30 1.000000E+00: 550 MHz  M: 800 Mhz  V: 1.000V  A: 99% P: 0%
Last initialised: [2012-02-05 23:29:14]
Intensity: 1
Thread 0: 5.8 Mh/s Enabled ALIVE
Thread 1: 6.2 Mh/s Enabled ALIVE

[E]nable [D]isable [I]ntensity [R]estart GPU [C]hange settings
Or press any other key to continue
GPU 0: 11.9 / 12.4 Mh/s | A:0  R:0  HW:0  U:0.00/m  I:1
64.5 C  F: 30 1.000000E+00: 550 MHz  M: 800 Mhz  V: 1.000V  A: 99% P: 0%
Last initialised: [2012-02-05 23:29:14]
Intensity: 1
Thread 0: 5.8 Mh/s Disabled ALIVE
Thread 1: 6.2 Mh/s Disabled ALIVE

[E]nable [D]isable [I]ntensity [R]estart GPU [C]hange settings
Or press any other key to continue
[2012-02-05 23:29:25] Thread 1 being disabled
[2012-02-05 23:29:25] Thread 1 being re-enabled
[2012-02-05 23:29:26] Thread 0 being disabled
[2012-02-05 23:29:26] Thread 1 being disabled

This isn't 100% reproducible so far (happened 4/5 tries) - is this known/expected?
Yeah it just passes through the check for "dynamic" and might enable/disable once or twice before doing the right thing in the end. It does end up disabled doesn't it?

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

Activity: 373


View Profile WWW
February 05, 2012, 11:52:23 PM
 #3576

Yeah it just passes through the check for "dynamic" and might enable/disable once or twice before doing the right thing in the end. It does end up disabled doesn't it?

That it does. Just looks a little strange.

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
February 06, 2012, 12:02:47 AM
 #3577

Yeah it just passes through the check for "dynamic" and might enable/disable once or twice before doing the right thing in the end. It does end up disabled doesn't it?

That it does. Just looks a little strange.
I'll make it prettier

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

Activity: 322


We are bees, and we hate you.


View Profile
February 06, 2012, 12:50:45 AM
 #3578

Just started using this over GUI, and I must say, I am very impressed.
I bumped up from 1.8Ghash to 2.1. The improvement was definitely worth the few seconds of setup.  Grin

Donations are welcome!
1BEES19ds5gEnRBoU1qNFPfjRXe94trMG3
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile
February 06, 2012, 01:23:22 AM
 #3579

OK. So AFAIK there are 5 kernel settings we have to adjust here :

BFI_INT ( where can I see if this is on / off ? )
Fastloop ( where can I see if this is on / off ? )

Vectors
Worksize
Intensity

What is the long8 at the end of the .bin produced ?

Thanks !
TheHarbinger
Sr. Member
****
Offline Offline

Activity: 378


Why is it so damn hot in here?


View Profile
February 06, 2012, 01:35:55 AM
 #3580

OK. So AFAIK there are 5 kernel settings we have to adjust here :

BFI_INT ( where can I see if this is on / off ? )
Fastloop ( where can I see if this is on / off ? )

Vectors
Worksize
Intensity

What is the long8 at the end of the .bin produced ?

Thanks !

Honestly, unless you are running 7000 series cards, you can leave all these at their defaults with the exception of "Intensity", which should be set to "d" for you desktop monitor, and 8 for dedicated mining cards.

12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
Pages: « 1 ... 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 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 ... 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!