miner cant run on 2miner pool algo mtp and x16rv2 please fix this
Hi! Can you describe your issues please? I don't have any problems with 2miners myself when testing. miner stop when initialize gpu... i use this miner with awesome miner... I myself use TeamRedMiner with awesome miner on 2miner for MTP. Right click the miner in awesome miner and run diagnostics and check/post the error. i already run diagnostic and it say cannot run the miner diagnostic close.... What are the command line arguments? |
|
|
|
miner cant run on 2miner pool algo mtp and x16rv2 please fix this
Hi! Can you describe your issues please? I don't have any problems with 2miners myself when testing. miner stop when initialize gpu... i use this miner with awesome miner... I myself use TeamRedMiner with awesome miner on 2miner for MTP. Right click the miner in awesome miner and run diagnostics and check/post the error. |
|
|
|
How do i execute a command b4 OC is applied?
Today the overclocking is applied first, then "Execute additional commands before starting the mining software" and finally the mining software is started. This order cannot be changed. Can you please let me know the scenario where the commands must be executed first and I can look into it in more detail? Thanks! DMed you the details |
|
|
|
miner cant run on 2miner pool algo mtp and x16rv2 please fix this
Running for weeks on 2miner for MTP and can confirm it works fine. What errors are you getting? |
|
|
|
|
How do i execute a command b4 OC is applied?
|
|
|
|
Since the hashrate of X16rv2 is a range, has anybody some numbers for Vega64? Just to compare a bit, thanks!
 https://ibb.co/vstL6hhResults on Vega 64: Cards : 6x Vega 64, Air Cooled, Samsung Memory, Reference Design Core : 1135mhz(p3) Mem : 500mhz(p1) Volt : 825mV SOC : 599mhz Timing mod : None, x16rv2 needs no memory tuning Hashrate : 24.2 mh/s (Average After 43 minutes of mining) Power : 195-200 watts |
|
|
|
We're all on TRM man, topic is dead Hi,
Please add Cryptonight-zum-lite
Thanks in advance
The CN variants are dead now in general, thanks to Monero and their cpu/nvidia friendly new algo At least i always added small algos for you guys when you asked. Not only the profitable ones, but i tried helping small projects too. Thank dude. Greatly appreciate the small algos support from you. Escpecially the crazy times when a new algo would pop up weekly   |
|
|
|
|
Is it possible to have Awesome miner installed on two systems and sync setting, control the remote rigs?
|
|
|
|
Feature Request: - Sort Pool list via coins
- Add external application OC for AMD Vega via OverdrivenTool, pretty simple cli
- Or, Add support for selecting min fan RPM and P state selection in Vega OC in AM
Thanks for the suggestions. As Awesome Miner has a Native Overclocking feature - that one will be the main focus for overclocking. It's however fully possible to manually configure any command line to be executed when starting the mining software. Earlier this year AMD introduced a concept of a Fan Curve in their drivers and Awesome Miner supports this as well via the GPU clocking dialog. It allows to define 5 different fan speed levels depending on the temperature, making it possible to use for both setting the minimum and maximum fan speed. Awesome Miner is currently setting the GPU Clock/Voltage and Memory Clock/Voltage on the high performance P-state (P7 for the GPU, P2 or P3 for Memory). Is there a scenario where the Vega doesn't go to P7 correctly during mining? Yes, there are situations where to save power it is preferable to mine using a lower p state either in GPU or memory. Also, in the dashboard via HTTP API, <font>(used in custom progress field) is not being converted from HTML tags to Text, rather being shown as raw text. |
|
|
|
Feature Request: - Sort Pool list via coins
- Add external application OC for AMD Vega via OverdrivenTool, pretty simple cli
- Or, Add support for selecting min fan RPM and P state selection in Vega OC in AM
|
|
|
|
No idea what you are referring to.. we didn't created the miners.  This is ur github right?? https://github.com/LightBitDev/LightBit/blob/master/src/crypto/yespower/yespower.c#include "yespower.h"
int yespower_hash(const char *input, char *output)
{
yespower_params_t params = {
.version = YESPOWER_1_0,
.N = 2048,
.r = 32,
.pers = "LITBpower: The number of LITB working or available for proof-of-work mining",
.perslen = 73
};
return yespower_tls(input, 80, ¶ms, (yespower_binary_t *) output);
} This is CPUChain : https://github.com/cpuchain/cpuchain/blob/master/src/crypto/yespower/yespower.c#include "yespower.h"
int yespower_hash(const char *input, char *output)
{
yespower_params_t params = {
.version = YESPOWER_1_0,
.N = 2048,
.r = 32,
.pers = "CPUpower: The number of CPU working or available for proof-of-work mining",
.perslen = 73
};
return yespower_tls(input, 80, ¶ms, (yespower_binary_t *) output);
} Apparently replacing CPU with LITB results in an additional 1 charaction and hence ur Personalisation string is now 75 instead of 73 characters. Im just explaining the post from the cpu-optiminer dev, if u use the actual 73 characters (aka, cutting the last 2 letters ), this coin is minable with the offical cpu-optiminer as well !!! Aah now I get it. Thanks for the kind answer. Will definitely forward this information to our dev. But we are listed on 4 pools now and they already modified the miner to support it. Thanks again for the information. Thanks to the cpu-optiminer dev too. No need for a new miner, the official cpu-optiminer works fine cpuminer.exe -a yespower -N 2048 -R 32 -K "LITBpower: The number of LITB working or available for proof-of-work mini" -o stratum+tcp://XXX -u YYY Note how the personalisation string cuts off with just 73 chars instead of the full string. |
|
|
|
No idea what you are referring to.. we didn't created the miners. This is ur github right?? https://github.com/LightBitDev/LightBit/blob/master/src/crypto/yespower/yespower.c#include "yespower.h"
int yespower_hash(const char *input, char *output)
{
yespower_params_t params = {
.version = YESPOWER_1_0,
.N = 2048,
.r = 32,
.pers = "LITBpower: The number of LITB working or available for proof-of-work mining",
.perslen = 73
};
return yespower_tls(input, 80, ¶ms, (yespower_binary_t *) output);
} This is CPUChain : https://github.com/cpuchain/cpuchain/blob/master/src/crypto/yespower/yespower.c#include "yespower.h"
int yespower_hash(const char *input, char *output)
{
yespower_params_t params = {
.version = YESPOWER_1_0,
.N = 2048,
.r = 32,
.pers = "CPUpower: The number of CPU working or available for proof-of-work mining",
.perslen = 73
};
return yespower_tls(input, 80, ¶ms, (yespower_binary_t *) output);
} Apparently replacing CPU with LITB results in an additional 1 charaction and hence ur Personalisation string is now 75 instead of 73 characters. Im just explaining the post from the cpu-optiminer dev, if u use the actual 73 characters (aka, cutting the last 2 letters ), this coin is minable with the offical cpu-optiminer as well !!! |
|
|
|
Hey, how do i run a specific gpu alone or how do i disable certain gpus at command line?
--cgpuid is what you need Could u share the full line using --cgpuid 5 still runs all my cards (0-5). |
|
|
|
|
Hey, how do i run a specific gpu alone or how do i disable certain gpus at command line?
|
|
|
|
Im not sure how the dead device detection as sick works. I 'think' AM is rebooting my rigs without cause.
Awesome Miner uses the API data from the mining software to find out if the mining software considers a device to be dead/sick. Could you please send me the API report (toolbar: Tools -> API Report) for this miner when it's in this state? Thanks! Hey did some testing with the miner dev. The miner will declare the GPU as dead after testing it for 10-20 seconds, but AM will declare as Sick in the first signs of trouble. Suggestions: - AM logs could show which GPU(bus ID or something) went sick
- It would be preferable if AM could route the "Dead device detection" for TeamRedMiner via the miner commands
--watchdog_script=reboot.bat where the reboot command could be stored in the reboot.bat.[/li]
These are just suggestions and not sure which is the optimal method. My reasoning is : AM reboots on GPU death so soon that miner doesnt log the error(needed to debug the crash) and AM doesnt save in its own logs neither the GPU that crashed nor the API response on crash. |
|
|
|
Im not sure how the dead device detection as sick works. I 'think' AM is rebooting my rigs without cause. Rig: 6x Vega 64 running TeamRedMiner Log from Miner: [2019-08-06 12:41:44] Pool europe.cryptonight-hub.miningpoolhub.com share accepted. (GPU0) (a:1690 r:0) (378 ms)
[2019-08-06 12:41:46] Pool europe.cryptonight-hub.miningpoolhub.com share accepted. (GPU0) (a:1691 r:0) (377 ms)
[2019-08-06 12:43:56] Initializing GPU 0.
[2019-08-06 12:43:57] Initializing GPU 1.
[2019-08-06 12:43:58] Initializing GPU 2.
[2019-08-06 12:44:00] Initializing GPU 3.
[2019-08-06 12:44:01] Initializing GPU 4.
[2019-08-06 12:44:02] Initializing GPU 5.
[2019-08-06 12:44:03] Watchdog thread starting. The miner has a built in watchdog, and im pretty sure if a GPU had crashed the miner watchdog would have picked it up before AM does. Note how the shares are submitted till 12:41:46 and then a reboot of rig, so no log for 2 mins and miner starts again Log from Awesome Miner: 06/08/2019 12:41:56 PM.132 [022] [ S][ManagedMiner#7 - Vega Rig] Dead device detection: Sick
06/08/2019 12:41:56 PM.132 [022] [ S]Rule execute: Dead device detection, miners: [Vega Rig, 192.168.100.33]
06/08/2019 12:41:56 PM.144 [022] [ S][ManagedMiner#7 - Vega Rig] Run Miner Command: Reboot
06/08/2019 12:41:56 PM.145 [022] [ S]Rule execution done: Dead device detection
Based on the above logs, 10 seconds after the last shares the rigs is marked as sick  Log from Remote Agent: 06-08-2019 12:41:52 PM.950 [009] [ManagedMiner#7 - Vega Rig] : ProcessMiner
06-08-2019 12:41:52 PM.950 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"config"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"summary"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"privileged"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"devs"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"pools"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"coin"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"stats"}
06-08-2019 12:41:54 PM.841 [020] MinerService.AddMinerCommand
06-08-2019 12:41:54 PM.841 [020] [ S]MinerService.AddMinerCommand from client: 192.168.100.29:33439, Reboot
06-08-2019 12:41:54 PM.841 [020] [ S]Command request: Reboot
06-08-2019 12:41:54 PM.841 [007] [ S][ManagedMiner#7 - Vega Rig] Execute command: Reboot
06-08-2019 12:41:54 PM.841 [007] [ S]Reboot of Managed Miner initiated
06-08-2019 12:41:54 PM.904 [007] [ S]Miner commands left to process: 0
Last share by miner : 12:41:46 Last stats query by AM : 12:41:52 Declared sick and reboot init : 12:41:54 I have no clue how this is happening. Since i am pretty sure TRM watchdog would pop the dead GPU and log it before AM !! |
|
|
|
Awesome Miner version 6.7.4 ( Development preview of 6.8 )
ASIC mining
- Antminer S15/T15 power mode configuration
Features
- Keystrokes can be sent to mining software via the rule actons. Configurable via the Miner Command action.
Mining software
- CpuMiner-Opt 3.9.6.2
- Phoenix Miner integration improved to display share information per GPU
- Nanominer integration updated for RandomHash algorithm
Can the keystrokes be sent without rules ? like from a menu in the console tab? |
|
|
|
|
Show Posts
