doc: Update part of MINING, rename to MINING.md.

11 years ago · c061b4e405
3 changed files with 264 additions and 238 deletions
--- a/README.md
+++ b/README.md
@ -27,7 +27,7 @@ Documentation is available in directory `doc`. For details on several topics, se
 * `FAQ` for frequently asked questions;
 * `GPU` for semi-obsolete information on GPU configuration options and mining SHA256d-based coins;
 * `KERNEL.md` for OpenCL kernel-related information;
-* `MINING` for how to find the right balance in GPU configuration to mine Scrypt-based coins effectively;
+* `MINING.md` for how to find the right balance in GPU configuration to mine Scrypt-based coins effectively;
 * `windows-build.txt` for information on how to build on Windows.
 Note that **most of the documentation is outdated**. If you want to contribute, fork this repository, update as needed, and submit a pull request.
--- a/doc/MINING
+++ b/doc/MINING
@ -1,237 +0,0 @@
 While BTC donations are preferred, if you wish to donate to the author, Con
 Kolivas, in LTC, please submit your donations to:
 Lc8TWMiKM7gRUrG8VB8pPNP1Yvt1SGZnoH
 Otherwise, please donate in BTC as per the main README.
 ---
 Scrypt mining, AKA litecoin mining, for GPU is completely different to sha256
 used for bitcoin mining. The algorithm was originally developed in a manner
 that it was anticipated would make it suitable for mining on CPU but NOT GPU.
 Thanks to some innovative work by Artforz and mtrlt, this was proven to be
 wrong. However, it has very different requirements to bitcoin mining and is a
 lot more complicated to get working well. Note that it is a ram dependent
 workload, and requires you to have enough system ram as well as fast enough
 GPU ram. If you have less system ram than your GPU has, it may not be possible
 to mine at any reasonable rate.
 There are 5 main parameters to tuning scrypt, all of which are optional for
 further fine tuning. When you start mining, sgminer may fail IN RANDOM WAYS.
 They are all due to parameters being outside what the GPU can cope with.
 NOTE that if it does not fail at startup, the presence of hardware errors (HW)
 are a sure sign that you have set the parameters too high.
 DRIVERS AND OPENCL SDK
 The choice of driver version for your GPU is critical, as some are known to
 break scrypt mining entirely while others give poor hashrates. As for the
 OpenCL SDK installed, for AMD it must be version 2.6 or later.
 Step 1 on Linux:
 export GPU_MAX_ALLOC_PERCENT=100
 If you do not do this, you may find it impossible to scrypt mine. You may find
 a value of 40 is enough and increasing this further has little effect.
 export GPU_USE_SYNC_OBJECTS=1
 may help CPU usage a little as well.
 On windows the same commands can be passed via a batch file if the following
 lines are in the .bat before starting sgminer:
 setx GPU_MAX_ALLOC_PERCENT 100
 setx GPU_USE_SYNC_OBJECTS 1
 --intensity XX (-I XX)
 The scale goes from 0 to 42. The reason this is crucial is that too
 high an intensity can actually be 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 can start actually DECREASING
 your hashrate, or even worse, start producing garbage with HW errors
 skyrocketing, or locking up the system altogether. Note that if you do
 NOT specify an intensity, sgminer uses dynamic mode which is designed
 to minimise the harm to a running desktop and performance WILL be poor.
 The lower limit to intensity with scrypt is usually 8 and sgminer will
 prevent it going too low.
 SUMMARY: Setting this for reasonable hashrates is mandatory.
 --shaders XXX
 is an option where you tell sgminer how many shaders your GPU has. This
 helps sgminer 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 variants of these cards, and nvidia shaders are much
 much lower and virtually pointless trying to mine on. If this is not
 set, sgminer will query the device for how much memory it supports and
 will try to set a value based on that.
 SUMMARY: This will get you started but fine tuning for optimal performance is
 required. Using --thread-concurrency is recommended instead.
 GPU  Shaders
 7750 512
 7770 640
 7850 1024
 7870 1280
 7950 1792
 7970 2048
 6850 960
 6870 1120
 6950 1408
 6970 1536
 6990 (6970x2)
 6570 480
 6670 480
 6790 800
 6450 160
 5670 400
 5750 720
 5770 800
 5830 1120
 5850 1440
 5870 1600
 5970 (5870x2)
 These are only used as a rough guide for sgminer, and it is rare that this is
 all you will need to set.
 Optional parameters to tune:
 -g, --thread-concurrency, --lookup-gap
 --thread-concurrency:
 This tunes the optimal size of work that scrypt can do. It is internally tuned
 by sgminer to be the highest reasonable multiple of shaders that it can
 allocate on your GPU. Ideally it should be a multiple of your shader count.
 vliw5 architecture (R5XXX) would be best at 5x shaders, while VLIW4 (R6xxx and
 R7xxx) are best at 4x. Setting thread concurrency overrides anything you put
 into --shaders and is ultimately a BETTER way to tune performance.
 SUMMARY: Spend lots of time finding the highest value that your device likes
 and increases hashrate.
 -g:
 Once you have found the optimal shaders and intensity, you can start increasing
 the -g value till sgminer fails to start. This is really only of value if you
 want to run low intensities as you will be unable to run more than 1.
 SUMMARY: Don't touch this.
 --lookup-gap
 This tunes a compromise between ram usage and performance. Performance peaks
 at a gap of 2, but increasing the gap can save you some GPU ram, but almost
 always at the cost of significant loss of hashrate. Setting lookup gap
 overrides the default of 2, but sgminer will use the --shaders value to choose
 a thread-concurrency if you haven't chosen one.
 SUMMARY: Don't touch this.
 Related parameters:
 --worksize XX (-w XX)
 Has a minor effect, should be a multiple of 64 up to 256 maximum.
 SUMMARY: Worth playing with once everything else has been tried but will
 probably do nothing.
 Overclocking for scrypt mining:
 First of all, do not underclock your memory initially. Scrypt mining requires
 memory speed and on most, but not all, GPUs, lowering memory speed lowers
 mining performance.
 Second, absolute engine clock speeds do NOT correlate with hashrate. The ratio
 of engine clock speed to memory matters, so if you set your memory to the
 default value, and then start overclocking as you are running it, you should
 find a sweet spot where the hashrate peaks and then it might actually drop if
 you increase the engine clock speed further.
 Third, the combination of motherboard, CPU and system ram ALSO makes a
 difference, so values that work for a GPU on one system may not work for the
 same GPU on a different system. A decent amount of system ram is actually
 required for scrypt mining, and 4GB is suggested.
 Finally, the power consumption while mining at high engine clocks, very high
 memory clocks can be far in excess of what you might imagine.
 For example, a 7970 running with the following settings:
 --thread-concurrency 22392 --gpu-engine 1135 --gpu-memclock 1890
 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 sgminer.
 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 sgminer will try to
 find an optimal value
 sgminer -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. Mine 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 1141  --gpu-memclock 1875 -I 20
 for a hashrate of 745kH.
 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 22392) as slight changes in
 thread concurrency will happen every time if you don't specify one, and the tc
 to clock ratios are critical!
 Good luck, and if this doesn't work for you, well same old magic discussion
 applies, I cannot debug every hardware combo out there.
 Your numbers will be your numbers depending on your hardware combination and OS,
 so don't expect to get exactly the same results!
 ---
 While BTC donations are preferred, if you wish to donate to the author, Con
 Kolivas, in LTC, please submit your donations to:
 Lc8TWMiKM7gRUrG8VB8pPNP1Yvt1SGZnoH
 Otherwise, please donate in BTC as per the main README.
--- a/doc/MINING.md
+++ b/doc/MINING.md
@ -0,0 +1,263 @@
 # Mining scrypt
 ## Introduction
 Mining scrypt-based cryptocurrencies using GPUs is completely different
 to mining SHA256d (used in Bitcoin). The former was intentionally
 developed in a manner that (it was hoped) would make it suitable
 for mining on CPUs, but not GPUs. Thanks to some innovative work by
 _Artforz_ and _mtrlt_, this was proven to be wrong.
 However, it has very different requirements compared to SHA256d and
 is a lot more complicated to get working well. It is a RAM-dependent
 workload, and requires you to have enough system RAM as well as fast
 enough GPU RAM. What is "enough" depends on setup specifics.
 ## Catalyst drivers and OpenCL SDK
 The choice of driver version for your GPU is critical, as some are known
 to break scrypt mining entirely while others give poor hashrates. It is
 recommended that you first try with the latest stable version available.
 Latest driver distribution versions may aready include the AMD APP
 SDK, therefore presenting an OpenCL vendor conflict when building or
 running. Systems with NVidia cards and NVidia drivers may have a similar
 conflict. If this is the case, check which OpenCL vendor is used, and
 consider removing unneeded ones.
 ## Runtime environment
 Environment variables must be set to allow access from console /
 terminal / screen.
 On Linux:
 export DISPLAY=:0
 export GPU_MAX_ALLOC_PERCENT=100
 export GPU_USE_SYNC_OBJECTS=1
 On Windows:
 setx GPU_MAX_ALLOC_PERCENT 100
 setx GPU_USE_SYNC_OBJECTS 1
 ## Tuning
 When mining is started, sgminer may fail in various ways. This is often
 not a bug in the software, but rather misconfiguration. The failures may
 occur due to parameters being outside what the GPU can cope with (both
 too high and too low).
 All parameters are optional for fine tuning.
 **WARNING**: documentation below has not been reviewed to be up-to-date.
 --intensity XX (-I XX)
 The scale goes from 0 to 31. The reason this is crucial is that too
 high an intensity can actually be 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 can start actually DECREASING
 your hashrate, or even worse, start producing garbage with HW errors
 skyrocketing, or locking up the system altogether. Note that if you do
 NOT specify an intensity, sgminer uses dynamic mode which is designed
 to minimise the harm to a running desktop and performance WILL be poor.
 The lower limit to intensity with scrypt is usually 8 and sgminer will
 prevent it going too low.
 SUMMARY: Setting this for reasonable hashrates is mandatory.
 --shaders XXX
 is an option where you tell sgminer how many shaders your GPU has. This
 helps sgminer 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 variants of these cards, and nvidia shaders are
 much much lower and virtually pointless trying to mine on. If this is
 not set, sgminer will query the device for how much memory it supports
 and will try to set a value based on that.
 SUMMARY: This will get you started but fine tuning for optimal
 performance is required. Using --thread-concurrency is recommended
 instead.
 GPU  Shaders
 7750 512
 7770 640
 7850 1024
 7870 1280
 7950 1792
 7970 2048
 6850 960
 6870 1120
 6950 1408
 6970 1536
 6990 (6970x2)
 6570 480
 6670 480
 6790 800
 6450 160
 5670 400
 5750 720
 5770 800
 5830 1120
 5850 1440
 5870 1600
 5970 (5870x2)
 These are only used as a rough guide for sgminer, and it is rare that
 this is all you will need to set.
 --thread-concurrency
 This tunes the optimal size of work that scrypt can do. It is internally
 tuned by sgminer to be the highest reasonable multiple of shaders that
 it can allocate on your GPU. Ideally it should be a multiple of your
 shader count. vliw5 architecture (R5XXX) would be best at 5x shaders,
 while VLIW4 (R6xxx and R7xxx) are best at 4x. Setting thread concurrency
 overrides anything you put into --shaders and is ultimately a BETTER way
 to tune performance.
 SUMMARY: Spend lots of time finding the highest value that your device
 likes and increases hashrate.
 -g
 Once you have found the optimal shaders and intensity, you can start
 increasing the -g value till sgminer fails to start. This is really only
 of value if you want to run low intensities as you will be unable to run
 more than 1.
 SUMMARY: Don't touch this.
 --lookup-gap
 This tunes a compromise between ram usage and performance. Performance
 peaks at a gap of 2, but increasing the gap can save you some GPU
 ram, but almost always at the cost of significant loss of hashrate.
 Setting lookup gap overrides the default of 2, but sgminer will use the
 --shaders value to choose a thread-concurrency if you haven't chosen
 one.
 SUMMARY: Don't touch this.
 Related parameters:
 --worksize XX (-w XX)
 Has a minor effect, should be a multiple of 64 up to 256 maximum.
 SUMMARY: Worth playing with once everything else has been tried but will
 probably do nothing.
 Overclocking for scrypt mining: First of all, do not underclock your
 memory initially. Scrypt mining requires memory speed and on most, but
 not all, GPUs, lowering memory speed lowers mining performance.
 Second, absolute engine clock speeds do NOT correlate with hashrate. The
 ratio of engine clock speed to memory matters, so if you set your memory
 to the default value, and then start overclocking as you are running it,
 you should find a sweet spot where the hashrate peaks and then it might
 actually drop if you increase the engine clock speed further.
 Third, the combination of motherboard, CPU and system ram ALSO makes a
 difference, so values that work for a GPU on one system may not work for
 the same GPU on a different system. A decent amount of system ram is
 actually required for scrypt mining, and 4GB is suggested.
 Finally, the power consumption while mining at high engine clocks,
 very high memory clocks can be far in excess of what you might
 imagine. For example, a 7970 running with the following settings:
 --thread-concurrency 22392 --gpu-engine 1135 --gpu-memclock 1890 was
 using 305W!
 ## Example: tuning a 7970
 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 sgminer.
 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 sgminer
 will try to find an optimal value
    sgminer -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. Mine 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 1141  --gpu-memclock 1875 -I 20
 for a hashrate of 745kH.
 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 22392) as
 slight changes in thread concurrency will happen every time if you don't
 specify one, and the tc to clock ratios are critical!
 Good luck, and if this doesn't work for you, well same old magic
 discussion applies, I cannot debug every hardware combo out there.
 Your numbers will be your numbers depending on your hardware combination
 and OS, so don't expect to get exactly the same results!