hossbeast / autominer Goto Github PK

history files, perf files, rates files - gracefully wrap past 64k files back to 0.

The files are named like printf("%05u", counter)

To make it easier for users, launch nicehash-aggregator from autominer-mine when necessary. This solves the base case, for users that only run a single autominer instance.

For users that run multiple copies of autominer with different profiles, use a lock to avoid running multiple instances of nicehash-aggregator.

Retain the ability to run nicehash-aggregator independently, and make that the recommendation for users that run multiple autominers under different profiles.

Hi,

Was checking out your autoswitcher. Looking nice but: Have a few remarks for now (Ubuntu 16.04).
#!/bin/env gives issues -> #!/usr/bin/env

Needed to install:
sudo apt-get install libjson-xs-perl

First start nicehash-aggegrator searches for non-existent directories:
.autominer/config) : No such file or directory
.autominer/data/rates/nicehash/samples) : No such file or directory

Did this manually.

It seems that nicehash-aggegrator needs to run indefenenitly?

Hope it helps.

PS Where do you expect the miners to live?

autominer maintains a history of activity, divided into intervals. Over the course of a single interval, autominer was pursuing one particular mining option, which consists of a market, pool, miner, and algo. This history is represented as a stream, and is identified by the profile.

In addition, autominer maintains several partial streams, which are identified by attributes that correspond to the mining option.

• per miner
• per worker
• per algo/miner
• per pool/market
• per nicehash address
• per miningpoolhub username

Each stream ise also associated with the profile.

This enables post-hoc analysis that follows these streams, for example, autominer stats will let you restrict its query to only those intervals in which a particular algo was being mined, with a particular miner.

Some miners have the same name, also, frequently you have to compile miners from source, so it's not always convenient to install the miner application and make it available in $PATH. Support config keys which specify /path/to/miner/executable.

coalesce adjacent periods where the same algo/miner/market was running

I want to enable pplns pool mining too, with a pool service like miningpoolhub.

The prediction of profit is straightforward but quite different from nicehash.

Have you thought about releasing a dockerfile to spin it up with the miners etc, would really make deployment easy.

Hi @hossbeast
What is the differences between "hossbeast/autominer" and "autominer/autominer", which is placed on
https://github.com/autominer/autominer

Thanks in advance!
Best,
Aro28

For interpolation into the stratum url

e.g. usa / eu / jp, etc

show graphs of performance over time.

should stay in the console.

Nicehash has an api

stats.provider?addr=

which reports the hashing speed as measured by nicehash. It's refreshed every 30 seconds, but its not clear what time period its reporting. I can only guess its the trailing 30 seconds.

autominer currently uses hashing speed as reported locally, by monitoring the miner directly. The speed reported by nicehash is probably more useful. Also, I could compare the two and possibly alert the operator of a misconfiguration that will lead to choosing a suboptimal mining strategy.

autominer-mine only needs to load the newest N history files per miner/algo in order to satisfy the --samples parameter. This will reduce startup time.

Boosting is a feedback mechanism from the actual rewards of mining some option over an interval, to the prediction of rewards for mining that same option in the future.

The goal is to enhance the accuracy of predictions to improve overall rewards. Another important outcome is to enable autominer to automatically de-prioritize mining options which aren't working for one reason or another (pools go down, miner executables break, etc).

The boost factor should decay over time, so that predictions tend back towards unmodified (a boost factor of 1.0).

Configuration knobs will include number of samples to use in calculating the boost, duration of time for which a sample remains relevant to the boost, and a padding factor (the larger the padding factor, the more the boost will trend towards 1.0)

Because nicehash works as a market that matches buyer and sellers, using trailing average price to switch can lead to suboptimal choices for sellers.

(If nicehash was an actual intermediary, buying all hashrate at some price and reselling to buyers at a markup, this would not be the case. But that's not how nicehash works, and it would be impossible anyway, since sellers have to include the payout address in blocks which they mine).

For example, It's possible for demand to be 100% satisfied for a particular algo, and yet for the average price paid to be high. In this case, miners that are already hashing that algo are getting a good rate, but new miners will get a much lower rate than the average, including possibly zero.

I define "opportunity price" as the average price on offer for the top 10% of unsatisfied demand. Using this metric as a guide for switching is more likely to avoid switching to an algo which is already saturated with sellers.

for interpolation into the username parameter, e.g. "-u ."