mirror of
https://github.com/GOSTSec/sgminer
synced 2025-01-14 08:48:01 +00:00
Update scrypt readme with newer information and to match changes in code.
This commit is contained in:
parent
c24ffa1520
commit
576e22bf71
@ -1,5 +1,5 @@
|
||||
If you wish to donate to the author, Con Kolivas, in LTC, please submit your
|
||||
donations to:
|
||||
While BTC donations are preferred, if you wish to donate to the author, Con
|
||||
Kolivas, in LTC, please submit your donations to:
|
||||
|
||||
Lc8TWMiKM7gRUrG8VB8pPNP1Yvt1SGZnoH
|
||||
|
||||
@ -7,7 +7,6 @@ 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.
|
||||
@ -18,11 +17,10 @@ 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, 2 of which you MUST set, and
|
||||
the others are optional for further fine tuning. When you start scrypt mining
|
||||
with the --scrypt option, cgminer will fail IN RANDOM WAYS. They are all due
|
||||
to parameters being outside what the GPU can cope with. Not giving cgminer a
|
||||
hint as to your GPU type, it will hardly ever perform well.
|
||||
There are 5 main parameters to tuning scrypt, all of which are optional for
|
||||
further fine tuning. When you start scrypt mining with the --scrypt option,
|
||||
cgminer will 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.
|
||||
@ -36,13 +34,31 @@ 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.
|
||||
|
||||
--intensity XX (-I XX)
|
||||
|
||||
Just like in bitcoin mining, scrypt mining takes an intensity, however the
|
||||
scale goes from 0 to 20 to mimic the "Aggression" used in mtrlt's reaper. 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. Note that if you do NOT specify an
|
||||
intensity, cgminer 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 cgminer will prevent it going too low.
|
||||
SUMMARY: Setting this for reasonable hashrates is mandatory.
|
||||
|
||||
--shaders XXX
|
||||
|
||||
is a new option where you tell cgminer how many shaders your GPU has. This
|
||||
helps cgminer 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.
|
||||
pointless trying to mine on. If this is not set, cgminer 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.
|
||||
|
||||
GPU Shaders
|
||||
7750 512
|
||||
@ -76,35 +92,24 @@ These are only used as a rough guide for cgminer, and it is rare that this is
|
||||
all you will need to set.
|
||||
|
||||
|
||||
--intensity XX
|
||||
|
||||
Just like in bitcoin mining, scrypt mining takes an intensity, however the
|
||||
scale goes from 0 to 20 to mimic the "Aggression" used in mtrlt's reaper. The
|
||||
reason this is crucial is that too high an intensity can actually be
|
||||
disastrous with scrypt because it CAN run out of ram. Intensities over 13
|
||||
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. The low level detail is that intensity is
|
||||
only guaranteed up to the power of 2 that most closely matches the thread
|
||||
concurrency. i.e. a thread concurrency of 6144 has 8192 as the nearest power
|
||||
of two above it, thus as 2^13=8192, that is an intensity of 13.
|
||||
|
||||
|
||||
Optional parameters to tune:
|
||||
-g, --thread-concurrency, --lookup-gap
|
||||
|
||||
-g:
|
||||
Once you have found the optimal shaders and intensity, you can start increasing
|
||||
the -g value till cgminer fails to start. Rarely will you be able to go over
|
||||
about -g 4 and each increase in -g only increases hashrate slightly.
|
||||
|
||||
--thread-concurrency:
|
||||
This tunes the optimal size of work that scrypt can do. It is internally tuned
|
||||
by cgminer 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.
|
||||
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 cgminer 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
|
||||
@ -112,6 +117,18 @@ 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 cgminer 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.
|
||||
|
||||
--vectors XX (-v XX)
|
||||
Vectors are NOT used by the scrypt mining kernel.
|
||||
SUMMARY: Does nothing.
|
||||
|
||||
|
||||
Overclocking for scrypt mining:
|
||||
@ -123,20 +140,23 @@ 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. Unless you wish to run with a
|
||||
dynamic intensity, do not go over 13 without testing it while it's running to
|
||||
see that it increases hashrate AND utility WITHOUT increasing your HW errors.
|
||||
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.
|
||||
|
||||
Suggested values for 7970 for example:
|
||||
export GPU_MAX_ALLOC_PERCENT=100
|
||||
--thread-concurrency 8192 -g 4 --gpu-engine 1135 --gpu-memclock 1375
|
||||
|
||||
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!
|
||||
|
||||
---
|
||||
|
||||
If you wish to donate to the author, Con Kolivas, in LTC, please submit your
|
||||
donations to:
|
||||
While BTC donations are preferred, if you wish to donate to the author, Con
|
||||
Kolivas, in LTC, please submit your donations to:
|
||||
|
||||
Lc8TWMiKM7gRUrG8VB8pPNP1Yvt1SGZnoH
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user