One small change to work well with previous ones.
Number of warnings now is 151, down from 157.
Still a long way to go. Most of the serious warnings are related to variables in miner.h, which is so intertwined with everything else that I fear of breaking something or making performance worse if I touch miner.h too much.
This reverts commit 8dd1c2d4af.
Introduced a security bug: since CCAN/opt is used to parse the JSON
config (something it is not meant to do), it was possible to specify
the default of
"api-listen":false
in .conf and expect the API to be disabled. However, since CCAN/opt
does not check for parameters to OPT_WITHOUT_ARG, this got set to
true anyway, and enabled the API on a (possibly unfirewalled) network.
For this reason, configuration options are not named uniformly.
This should have been reverted as soon as it became known:
4c4b909be6 (Fri Feb 28)
Sorry for that.
It looks like there's an exploit that abuses said command, but it is still not clear exactly how.
There's also an additional message when the reconnect happens: "WARNING: POTENTIAL CLIENT.EXPLOIT!", but it requires you to be actively monitoring your log to catch it, and in which case you already get a "Reconnect requested from Pool 0 to 127.0.0.1" message.
Note that disabling 'client.reconnect' might affect some pools that rely on the feature, like pools that you lease your rig to.
Oh and this is dry-coded. :)
WIP!
Use a string instead of a state-machine-ey kernel selection mechanism
where kernel names have to be predefined. This should allow just dropping
new kernels into dir `kernel` without bloating the code in three other
places.
Is in dire need of a cleanup, function parameter check, edge case check -
all the usual testing.
In particular, checking these definitions/keywords:
* enum cl_kernels
* kname
* [c]gpu[s]->kernel (and similar)
* memory cleanup after strdup()?..
* chosen_kernel
* queue_scrypt_kernel
* strbuf
* initCl
Also squashed:
config: add log messages to set_algo() and set_nfactor().
algorithm: use set_algorithm_nfactor() when setting default nfactor in set_algorithm().
Otherwise algorithm->n defaults to 0.
P.S. Did I already mention how this could have been C++?..
Had two bugs:
1. Will not compile due to unknown algorithm_t size.
2. nfactor is set to 0 (bad calling, fix later).
So squashed two commits:
1. algorithm: move algorithm_t definition to header.
2. config: if --nfactor is specified, properly set algorithm->nfactor.
Doc in `doc/configuration.md` (has to be started sometime, no?).
Configuration function has to be lamely-named set_algo(), because
set_algorithm() is already declared in algorithm.h (prevent namespace
conflict).
algorithm has to be added as global variable due to the way the
callback is done (by CCAN/opt, which in itself is nice).
This can be cleaned up significantly by (at least) introducing a
global configuration struct, but there is no reason to do it now
just for this - better a wholesale manana.
Current help contains conflict statements regarding intensity
priorities.
Per commit d11df698d1:
- rawintensity overrides both xintensity and intensity
- xintensity overrides intensity
The config file is written poorly: first off, not all available options
are written (they have to be written manually, since there's no struct
enumeration); then, default values are not commented out.
Pool state machine is incomplete, and enabled_pools is not increased if
pool state is not explicitly set to "enabled" in config. However,
there is no reason why the user should not be allowed to disable
all pools.
enabled_pools is a bookkeeping variable, and bookkeeping is cumbersome.
Rather than trying to fix this regression, get rid of another place
where enabled_pools is used.
Closes https://github.com/veox/sgminer/issues/75
Previous defaults (before 10/30) were optimised for Bitcoin that has
a much higher average block time. Optimise for Litecoin (currently
largest scrypt network.)
Not pushing it further down so as not to scare people with dropping
hashrates.
Thanks to MissedOutOnBTC @ freenode for testing.
Closes https://github.com/veox/sgminer/issues/22
Closes https://github.com/veox/sgminer/issues/51
Using j_a_i allows us to get rid of accounting vars like total_poolnames,
and pool names don't get mixed up if they're not specified for some pools.
It would still be desirable to show the URL as a pool name if poolname is not
set.
Use `#defined(...)` instead of `#defined ...`.
Remove comments about issues - anyone removing those lines can check blame
to see why they were added.
Add tonobitc to AUTHORS.md.
Introduced by commit 87e5f35745
The cast/ref/deref is performed wrong and breaks share/best share display.
It is not the value of target that should be increased, but its address.
If all else fails, add an `#ifdef _MSVC_VER`; we should avoid it if possible.
In either case, constructs like `&(*(((uint64_t *)target) + 24))` must be
explained (in a comment).
moved enable_pool(), disable_pool() and other functions related to
state. These could probably be factored out altogether.
Pool state default is now "enabled" - it was previosly "disabled",
but there was an unconditional function call to enable all pools
in main() previously. It was factored out by joe's earlier commits,
so not visible in this one.
This setting allows to set the GPU intensity value directly without any modifiers, it does not
get any more raw than this! Look at the xintensity description raw for examples of regular
intensity values. You can also set this value through the ncurses interface by pressing:
G -> A -> select device id -> enter value.
Minor xintensity code cleanup as well.
Conflicts:
driver-opencl.c
miner.h
sgminer.c
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
