Browse Source

Merge commit 'e62cb4e' into cg_merges_20130523a

Conflicts:
	README.scrypt
Luke Dashjr 12 years ago
parent
commit
c3a13a6bc8
1 changed files with 67 additions and 3 deletions
  1. 67 3
      README.scrypt

+ 67 - 3
README.scrypt

@@ -51,9 +51,9 @@ disastrous with scrypt because it CAN run out of ram. High intensities
 start writing over the same ram and it is highly dependent on the GPU, but they
 start writing over the same ram and it is highly dependent on the GPU, but they
 can start actually DECREASING your hashrate, or even worse, start producing
 can start actually DECREASING your hashrate, or even worse, start producing
 garbage with HW errors skyrocketing. Note that if you do NOT specify an
 garbage with HW errors skyrocketing. Note that if you do NOT specify an
-intensity, cgminer uses dynamic mode which is designed to minimise the harm
+intensity, BFGMiner uses dynamic mode which is designed to minimise the harm
 to a running desktop and performance WILL be poor. The lower limit to intensity
 to a running desktop and performance WILL be poor. The lower limit to intensity
-with scrypt is usually 8 and cgminer will prevent it going too low.
+with scrypt is usually 8 and BFGMiner will prevent it going too low.
 SUMMARY: Setting this for reasonable hashrates is mandatory.
 SUMMARY: Setting this for reasonable hashrates is mandatory.
 
 
 --shaders XXX
 --shaders XXX
@@ -62,7 +62,7 @@ is a new option where you tell BFGMiner how many shaders your GPU has. This
 helps BFGMiner try to choose some meaningful baseline parameters. Use this table
 helps BFGMiner try to choose some meaningful baseline parameters. Use this table
 below to determine how many shaders your GPU has, and note that there are some
 below to determine how many shaders your GPU has, and note that there are some
 variants of these cards, and Nvidia shaders are much much lower and virtually
 variants of these cards, and Nvidia shaders are much much lower and virtually
-pointless trying to mine on. If this is not set, cgminer will query the
+pointless trying to mine on. If this is not set, BFGMiner will query the
 device for how much memory it supports and will try to set a value based on
 device for how much memory it supports and will try to set a value based on
 that.
 that.
 SUMMARY: This will get you started but fine tuning for optimal performance is
 SUMMARY: This will get you started but fine tuning for optimal performance is
@@ -162,7 +162,71 @@ For example, a 7970 running with the following settings:
 was using 305W!
 was using 305W!
 
 
 ---
 ---
+TUNING AN AMD RADEON 7970
+Example tuning a 7970 for Scrypt mining:
 
 
+On Linux run this command:
+export GPU_MAX_ALLOC_PERCENT=100
+or on Windows this:
+setx GPU_MAX_ALLOC_PERCENT 100
+in the same console/bash/dos prompt/bat file/whatever you want to call it,
+before running BFGMiner.
+
+First, find the highest thread concurrency that you can start it at. They should
+all start at 8192 but some will go up to 3 times that. Don't go too high on the
+intensity while testing and don't change gpu threads. If you cannot go above
+8192, don't fret as you can still get a high hashrate.
+
+Delete any .bin files so you're starting from scratch and see what bins get
+generated.
+
+First try without any thread concurrency or even shaders, as BFGMiner will try to
+find an optimal value
+bfgminer -I 13
+
+If that starts mining, see what bin was generated, it is likely the largest
+meaningful TC you can set.
+Starting it on mine I get:
+scrypt130302Tahitiglg2tc22392w64l8.bin
+
+See tc22392 that's telling you what thread concurrency it was. It should start
+without TC parameters, but you never know. So if it doesn't, start with
+--thread-concurrency 8192 and add 2048 to it at a time till you find the highest
+value it will start successfully at.
+
+Then start overclocking the eyeballs off your memory, as 7970s are exquisitely
+sensitive to memory speed and amazingly overclockable but please make sure it
+keeps adequately cooled with --auto-fan! Do it while it's running from the GPU
+menu. Go up by 25 at a time every 30 seconds or so until your GPU crashes. Then
+reboot and start it 25 lower as a rough start. One example runs stable at 1900
+memory without overvolting. Overvolting is the only thing that can actually
+damage your GPU so I wouldn't recommend it at all.
+
+Then once you find the maximum memory clock speed, you need to find the sweet
+spot engine clock speed that matches it. It's a fine line where one more MHz
+will make the hashrate drop by 20%. It's somewhere in the .57 - 0.6 ratio range.
+Start your engine clock speed at half your memory clock speed and then increase
+it by 5 at a time. The hashrate should climb a little each rise in engine speed
+and then suddenly drop above a certain value. Decrease it by 1 then until you
+find it climbs dramatically. If your engine clock speed cannot get that high
+without crashing the GPU, you will have to use a lower memclock.
+
+Then, and only then, bother trying to increase intensity further.
+
+My final settings were:
+--gpu-engine 1157  --gpu-memclock 1900 -I 20
+for a hashrate of 725kH.
+
+Note I did not bother setting a thread concurrency. Once you have the magic
+endpoint, look at what tc was chosen by the bin file generated and then hard
+code that in next time (eg --thread-concurrency 22336) as slight changes in
+thread concurrency will happen every time if you don't specify one, and the tc
+to clock ratios are critical!
+
+Your numbers will be your numbers depending on your hardware combination and OS,
+so don't expect to get exactly the same results!
+
+---
 If you wish to donate to the author of scrypt support, Con Kolivas, please send
 If you wish to donate to the author of scrypt support, Con Kolivas, please send
 your donations to:
 your donations to: