All of this is credited to ArGee of RGMiner, he did the initial ground work for this setting.
This new setting allows for a much finer grained intensity setting and also opens up for dual gpu threads on devices not previously able to. Note: make sure to use lower thread-concurrency values when you increase cpu threads.
Intensity is currently used to spawn GPU threads as a simple 2^value setting.
I:13 = 8192 threads
I:15 = 32768 threads
I:17 = 131072 threads
I:18 = 262144 threads
I:19 = 524288 threads
I:20 = 1048576 threads
Notice how the higher settings increase thread count tremendously.
Now enter the xintensity setting (Yes, I am a genius with my naming convention!).
It is simply a shader multiplier, obviously based on the amount of shaders you got on a card, this should allow the same value to scale with different card models.
6970 with 1536 shaders: xI:64 = 98304 threads
R9 280X with 2048 shaders: xI:64 = 131072 threads
R9 290 with 2560 shaders: xI:64 = 180224 threads
R9 290X with 2816 shaders: xI:64 = 163840 threads
6970 with 1536 shaders: xI:300 = 460800 threads
R9 280X with 2048 shaders: xI:300 = 614400 threads
R9 290 with 2560 shaders: xI:300 = 768000 threads
R9 290X with 2816 shaders: xI:300 = 844800 threads
It's now much easier to control thread intensity and it potentially allows for a uniform way of setting the intensity on your system. I'm very interested in constructive feedback, as I do not have access to a lot of different card models.
This change has been tested on 6970, R9 290, R9 290X - all with equal or a little better speeds than regular intensity setting after a little tuning, but your mileage may vary. Don't fret it, if this doesn't work for you, the regular intensity setting is still available.
Conflicts:
driver-opencl.c
sgminer.c
The names will be used throughout the display in the program, when not set "Pool 1" will
simply be used instead. The names are not exposed through API yet, it's on my TODO list.
Use "poolname" like this:
{
"poolname" : "Example pool",
"url" : "stratum+tcp://example.com:8080",
"user" : "y",
"pass" : "x"
},
Conflicts:
sgminer.c
util.c
This may be useful in certain scenarios. However, server load from keepalive
is increased 6-fold if code is hard-changed from 30 to 5. So, provide it as
an option instead, and use the previous value as a default (30).
Explanation from
015c064396
Kevin's middlecoin fix, CURL TCP keepalive constants lowered:
CURLOPT_TCP_KEEPIDLE from 45 to 5 and CURLOPT_TCP_KEEPINTVL from 30 to
5. Before it'd trigger a keepalive packet after 45 seconds of connection
idle time and then again every 30 seconds. Now it triggers a keepalive
packet after 5 seconds of connection idle time and then again every 5
seconds.
It makes the client more resilient against coin switching pools or just
pools with connection issues in general. It will however add a tiny bit
pressure to the pool server; but a TCP keepalive probe is only about
60-80 bytes, so I don't think it is an issue.
It is exactly what it says, now you can finally put that Frankenrig configuration in one file.
The parameter follows the same design as gpu-engine and gpu-memclock.
Changed GPU status line from "A:xxxxx R:xxx" to "R:0.0%". It shows (rejected/(accepted+rejected))*100, which is the percentage of rejections for a GPU. Total accepted and rejected in top status is unchanged.
GPU status lines now show both threads and intensity.
It is possible to switch back to full date and time on each log line with "--log-dateformat 1". The short time-only format is default with the value of 0.
Log with short time-only format looks like:
[23:59:59] Accepted 389c47d1 Diff 1.16K/512 GPU 0 pool 0
[00:00:16] Log date is now 2013-12-22
[00:00:16] Stratum from pool 0 detected new block
[00:00:33] Accepted 7a4950a4 Diff 536/512 GPU 0 pool 0
Removing it means existing shell scripts fail unless they are updated
to remove passing the option. Instead, just print a deprecation
warning.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This software shall not support USB devices. They should be handled
by different software. Inter-software compatibility (such as stats
pulling) should be maintained on an API level.
Martin Danielsen