[Specs:]

I had my 'rig' running well since January, all new components. I had the components precariously placed on my patio table indoors (no frame, just lying loose) - ran without problem. With the nice weather here, it was time to bring the patio table outside so I powered the rig down and dismantled everything.

I got a new shelving unit (wood), so started to put things together again. I attached the mainboard ATX power connector (standard 24 pin), but forgot to attach the ATX CPU power connector (8pin), didn't add any GPUs/risers yet. I hit the power switch, the CPU fan turned for less than a second, then the system shut down. I then noticed I forgot the CPU power connector - so I connected it. Now it won't power on at all, no fan movement whatsoever.

Nothing looks 'wrong' on the motherboard. I tried it with a single PSU. Switched to the other PSU. I tried a backup power switch. Attached a monitor and USB keyboard. Tried shorting the CMOS reset jumper. Nothing yet.

Specs:
Biostar BTC+ 8GPU motherboard
2 EVGA 850W P2 PSUs

- not a factor (yet?)
6x asus rog 1070 GPUs
PCIe risers

Any ideas?

[aiostratum-proxy]

aiostratum-proxy is a new, open source stratum protocol (and altcoin derivatives) mining proxy. Its focus on being extensible/modular is one of its greatest strengths: users can create new aiostratum-proxy coin/algos 'plug-ins' or 'modules' without having to modify aiostratum-proxy itself.

Originally built as a learning exercise to better understand stratum protocol(s) and the mining ecosystem, I now think that others will benefit by making aiostratum-proxy available for everyone to use.

The goal for aiostratum-proxy is to make it the easiest solution for any coin/algorithm pool proxying needs, via the creation of JSONRPC (the stratum base 'language') modules.

More information available at the aiostratum-proxy Github repository.

Current Status:

As mentioned, aiostratum-proxy is new, and is looking for some testing beyond what I've thrown at it. Current coin/algo support is Equihash-only (more to come, given community interest). Constructive feedback is needed and appreciated.

Donations:

There is no dev fee. However, I eat food and need to support those around me - devs need to make money too. Consider it incentive to maintain and continue developing aiostratum-proxy. So if you use this proxy, donate using the addresses below:

• BTC: 1BS4QYAFiya4tsjyvHeY945biKnDj6bRA4
• LTC: LTN1LPGnJjHMKq4DcuQYifQgLfT4Phmn9d
• ETH: 0x4B005e68D323bdABD8eeD1D415117Ff1B57b3EC5
• BTCP: b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg
• ZCL: t1eoqTqyatJzL2rErW83waZLQHZLKuipMbi

Don't have any of the above? I'll look into getting an address in your choice currency.

Features:

The intention for aiostratum-proxy was to be feature-comparable with existing mining proxies, yet extensible without forking to add support for other coins.

• Configure multiple proxies to run at the same time (ie. mine same/different coins on same/different pools)
• Each proxy configuration supports multiple fallback pools
• Each proxy supports up to 65536 miner connections, each mining a separate nonce space (dependent on coin & miner support)
• Supports plaintext and secure connections (TLS/SSL) for both miner and pool connections
• Easily implement new coin/algorithm JSONRPC 'stratum-like' protocols as dynamically-loaded (via config file), external Python3 modules

Supported Coins/Algos:

• Equihash
• ... it's a bit lonely here, let's add some more maybe?

How you can help:

• Test!
• Create coin/algo modules (submit pull requests)
• Find bugs (File them on Github)
• Donate (see above!)
• Spread the word to coin dev teams, pool operators, other miners
• ... share your ideas for improvement

Requirements & Compatibility:

aiostratum-proxy is written using Python3's non-blocking async/await syntax - so Python 3.5 or greater is required.

It runs on Linux and macOS, and should work on Windows (send in reports, please).

Installation:

Read all of the Installation and Usage sections before proceeding with installing.

It's best to always refer to the aiostratum-proxy Github repository for source code and updated installation and usage instructions - but for the eager miners out there... installation is pretty simple:

Code:

pip install aiostratum-proxy

... but you probably really want to use Python virtual environments to contain the installation, rather than installing globally:

Code:

# this will create a directory 'containing' the Python3 virtual environment
python3 -m venv aiostratum_proxy

cd aiostratum_proxy

# this will install the aiostratum-proxy package
bin/pip install aiostratum-proxy

# verify the installation by checking the package version
bin/aiostratum-proxy --version

# view the built-in command-line help
bin/aiostratum-proxy --help

As you can see, installation creates a new command-line shortcut called aiostratum-proxy.

Usage:

A YAML config file is needed for the proxy to run (learn more about YAML); you can generate one:

Code:

bin/aiostratum-proxy --generate-config > proxy-config.yaml

Open and edit the generated proxy-config.yaml in a text editor. To run aiostratum-proxy, pass it your edited config file:

Code:

bin/aiostratum-proxy --config proxy-config.yaml

While you probably should always generate and edit your own config using the above instructions, here's a couple of sample configs for mining Bitcoin Private (BTCP) - to show you how simple they can be. Remember to modify addresses, usernames, passwords to use your own:

Code:

proxies:
- worker_class: aiostratum_proxy.protocols.equihash.EquihashWorkerProtocol
  pool_class: aiostratum_proxy.protocols.equihash.EquihashPoolProtocol

  listen:
  - host: ''
    port: 10666

  pools:
  - host: pool2.btcprivate.org
    port: 3032
    account_name: b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg
    account_password: x

The above uses the included Equihash support, defines a single unsecured port for miners to connect to and a single pool to proxy to. Simple, but not very secure or robust. Let's try again, adding in secure connections and a fallback pool:

Code:

proxies:
- worker_class: aiostratum_proxy.protocols.equihash.EquihashWorkerProtocol
  pool_class: aiostratum_proxy.protocols.equihash.EquihashPoolProtocol

  listen:
  - host: ''
    port: 10666
  - host: ''
    port: 10667
    ssl: true
    ssl_cert_file: <full path to your self-signed SSL/TLS cert file>
    ssl_cert_key_file: <full path to your self-signed SSL/TLS cert KEY file>

  pools:
  - host: pool2.btcprivate.org
    port: 3032
    account_name: b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg
    account_password: x
  - host: btcp.suprnova.cc
    port: 6825
    ssl: true
    account_name: wetblanket
    account_password: mypw

The above uses the included Equihash support, defines 2 ports for miners to connect to (1 of them being SSL/TLS secured) and 2 pools to proxy to (the second being the fallback).

Authorization Setting Notes:

Handily, aiostratum-proxy will automatically extract the worker name from each miner's authorization (when it connects) and appends it to the account_name config setting before authorizing with the pool. This allows you to continue per-miner hash/share rate tracking at the pool level. (Thanks Doftorul for the feedback!)

Step by step explanation:

• Miner connects to aiostratum-proxy with randomletters.worker1
• aiostratum-proxy extracts worker1 from the miner's auth
• aiostratum-proxy appends worker1 to the config file pool account_name setting giving us b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg.worker1
• aiostratum-proxy requests authorization from the pool for b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg.worker1
• Miner is authorized, stats are tracked at the pool as desired

Note that you CAN optionally put a worker name in the config file pool account_name setting (ie. b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg.worker1, but this will cause miner-specific worker names to be ignored. You might want this in a larger farm setup, perhaps.

Release Notes:

1.0.2 2018/07/13

• Fixing keepalive issue
• Added debug statement to help detect miner/proxy misconfiguration

1.0.1 2018/07/12

• Adding in worker socket keepalive configuration

1.0.0 2018/03/22

• Initial release

Future Ideas/Thoughts:

This section contains some ideas that may not get implemented - it depends on community feedback.

• Improve documentation
• Consider immediate reply to miner share submissions instead of waiting for pool response
• Complete mining.set_extranonce support
• Consider additional authentication improvements (currently miners aren't authenticated)
  
  • authenticate miners locally within proxy via config
  • authenticate miners via passthru to pool; would require per-pool mappings of username/password for fallback pools in config?
• Add HAProxy PROXY protocol support
• Collect stats (for console display/API purposes)
• Create stats JSON API endpoint
• More coin/algo support
  • Complete Bitcoin/Litecoin/etc stratum module (aiostratum_proxy.protocols.stratum.StratumPoolProtocol & aiostratum_proxy.protocols.stratum.StratumWorkerProtocol)
  • Ethereum (ETH) protocol(s) support?
• ... share your thoughts/ideas

This topic has been moved to Mining software (miners) - I didn't realize something much more specific to protocol implementation existed. Someday, I'll learn my way around BCT.

https://bitcointalk.org/index.php?topic=2768236.0

This topic has been moved to Pools (Altcoins), because the conversation and members there should be more relevant.

https://bitcointalk.org/index.php?topic=2768236.0

[I'm wondering if all 4 protocols are still needed/used - is it necessary to implement them all in a proxy? What about if one was implementing a pool?]

As an exercise, I'm toying with building a stratum proxy. I know they already exist, but I'm looking to experiment with some more recent tech and this seems like a good project.

This BCT thread is a good starting point for the stratum protocol. Along with the 'canonical' stratum protocol google doc and slushpool's stratum overview, there's a fair bit to digest. Definitely not a true spec, but enough to work with.

The 'spec' defines 4 transports: Socket transport, Websocket, HTTP Poll, and HTTP Push (which is a variation of HTTP Poll). I get the feeling that much has changed since stratum was first introduced, so I'm wondering if all 4 protocols are still needed/used - is it necessary to implement them all in a proxy? What about if one was implementing a pool? For example, if miners have moved towards supporting plain TCP Socket transport only, there's no point in implementing the other 3 transports.

 - Let me know if there's a better forum board for this post - I'll move it if needed.

In North America, how the hell does one get ahold of GPUs? I'm looking for 1070s but everything's been sold out for a while now. I realize not many people will be willing to share their sources/methods, but seriously: how are people still able to source hardware?

Maybe I'm too noob.

On Ubuntu Linux 16.04, 6x GTX 1070s, doesn't matter what miner I'm using. Related to overclocking probably.

• can't Ctrl-C to quit process
• can't kill -9 the process
• can't successfully reboot the server (ssh disconnects, but I can't reconnect afterwards)

The only thing that will let me back in is physically powering down the system by holding the power button down for a few seconds (I have no reset button) and starting the system back up. Then I can ssh back into it.

Can anyone help me with what's going on here? How to address it? It happens randomly. Is there anything I can do to prevent this? I'm sure lowering my overclock setting would help, but normally I'd just restart the miner to continue mining.

[does it really matter that much? Are 1070 variants that different from one another in heat distribution, overclocking, etc? Can I order another 8 1070s of any brand/model that is more available and I'll generally be happy, mining-wise?]

I'm pretty new to mining. I picked up 6 Asus ROG Strix 1070s (8G, not O8G) for my first rig because they're supposed to run quiet and perform well - I'm happy with them, but my experience is limited. Anyhow, I ordered another 2 of them to max out the rig at 8 GPUs. I run Ubuntu 16.04 headless - ssh all the way.

As many of you know, getting your hands on 1070 GPUs these days as a small time operator is hard - particularly if you're focusing on a particular brand and model! I originally spent quite a bit of time researching hardware & understanding the power requirements, but I'm wondering - does it really matter that much? Are 1070 variants that different from one another in heat distribution, overclocking, etc?

Can I order another 8 1070s of any brand/model that is more available and I'll generally be happy, mining-wise? (I'm not a gamer, so I don't care for the hardware in any other way other than perhaps potential resale value)

However, as many of you know, getting your hands on 1070 GPUs these days as a small time operator is hard - particularly if you're focusing on a particular brand and model!

Random notes:

• I like the idea of having each rig be uniform (ie. same cards).
• I like the idea of multiple fans - seems better that the founder's edition design.
• I'm aware of Samsung vs Micron memory.
• Quiet is good, but not the most important thing.

Bonus, random questions:

• Is there any way to determine if I have Micron memory in Linux? Yes, I know about GPU-Z on Windows.
• Is there any way to upgrade the 1070 bios in Linux?

I don't have anything particularly against Windows, it would just be handier to be able to accomplish this without. I've read I can run a (slow) never-ending trial install of Windows from a USB stick to handle these operations, so that's an option too.

I've put together an `ethminer` Python3-based process wrapper to monitor output and restart as necessary. This lets you increase overclock settings a bit more as it will restart on CUDA error output and generally be a bit more hands off your rigs. Not sure if it works on Windows (I've only tested on Ubuntu 16.04) It doesn't work on Windows; see notes below - sorry!

Code:

import os
import signal
import subprocess
import sys

try:
   TIMEOUT_NO_ACTIVITY_SECONDS = int(os.getenv('TIMEOUT_NO_ACTIVITY_SECONDS', 60))
except:
   TIMEOUT_NO_ACTIVITY_SECONDS = 60


class MinerException(Exception):
    pass


class TimeoutException(Exception):
    pass


def timeout_handler(signum, frame):
    raise TimeoutException("No activity from etnminer for {} seconds".format(TIMEOUT_NO_ACTIVITY_SECONDS))


def execute(cmd):
    signal.signal(signal.SIGALRM, timeout_handler)

    shutdown = False
    while not shutdown:
        proc = subprocess.Popen(cmd,
                                bufsize=0,
                                stdout=subprocess.PIPE,
                                stderr=subprocess.STDOUT,
                                universal_newlines=True)

        try:
            signal.alarm(TIMEOUT_NO_ACTIVITY_SECONDS)
            for line in iter(proc.stdout.readline, ""):
                line = line.strip()
                print(line)
                if line.startswith('CUDA error'):
                    raise MinerException('****** Restarting due to CUDA error')
                signal.alarm(TIMEOUT_NO_ACTIVITY_SECONDS)
        except (MinerException, TimeoutException) as e:
            print('\n\n', str(e), '\n\n')
        except KeyboardInterrupt:
            shutdown = True

        signal.alarm(0)

        proc.send_signal(signal.SIGINT)
        proc.stdout.close()

        try:
            proc.wait(timeout=15)
        except subprocess.TimeoutExpired:
            print("Miner didn't shutdown within 5 seconds")
            proc.kill()


if __name__ == "__main__":
    execute(sys.argv[1:])

It starts ethminer in a subprocess; it then:

• checks ethminer output for CUDA error (usually related to overclocking memory errors) and
• detects long waits/delays for output (sometimes ethminer gets hung waiting for server to respond, etc)

If either happens, the wrapper will kill the ethminer subprocess and restart it.  To use it, download the script and use it like this:

Code:

python3 emwrapper.py ethminer -v 9 -U <farm/stratum, worker options, etc>

Change the number of seconds to wait for ethminer to output text (ie. hanging/freeze/delay detection) by setting the TIMEOUT_NO_ACTIVITY_SECONDS environment variable (defaults to 60 seconds):

Code:

TIMEOUT_NO_ACTIVITY_SECONDS=300 python3 emwrapper.py ethminer -v 9 -U <farm/stratum, worker options, etc>

• Note that Python2 is not supported as it does not have `subprocess.TimeoutExpired`
• Note that Windows is not supported as it does not have `signal.alarm`
• If this helped you, please send a small ETH donation to 0x4B005e68D323bdABD8eeD1D415117Ff1B57b3EC5
• If you have any questions/comments/issues/fixes with this, post a comment below

[Edit: I'm a dope, yet again. I completely ignored the SATA -> VGA/PCIe adapters that come with the risers. Problem solved.]

Edit: I'm a dope, yet again. I completely ignored the SATA -> VGA/PCIe adapters that come with the risers. Problem solved.


Just received the following components for my first rig:

• biostar TB250-BTC+ (8xGPU)
• 6x Asus ROG GTX 1070 (will be 8 in total in a few weeks)
• 8x risers ver007
• 2x EVGA 850w P2 80+ Platinum rated
• mainboard power connector splitter to power on both PSUs at the same time
• 4GB ram
• other stuff, not important to the problem...

Being new to the scene, I misjudged:

• the number of VGA/PCIe (6 and 6+2 pin) power cables these PSUs have (just 4) and support AND
• the fact that both the GPU AND the risers need power

I totally assumed that if you powered the GPU directly, you didn't need to power the riser. Ok, my bad - I'm a dufus. I need 8 VGA/PCIe connectors so each PSU can power 4 risers and 4 GPUs. Each PSU only supports 4 cables, but 2 of the cables have both 8pin (6+2) and 6pin connectors (but too close together to reach both GPU and riser!).

How can I salvage this situation and get my rig up and running?

• Power splitters? Unsure of safety here - can I power both a riser and a GPU from a single VGA power cable?
• Obviously return the PSUs and get a higher/pricier model

BTW, been a long time lurker on BCT, this is my first post. BCT has been super helpful, thanks to everyone!

Cheers!