Building the next-generation STH Aeon Docker Image

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Patrick

Administrator
Staff member
Dec 21, 2010
12,511
5,792
113
CES 2018 is great, but a bit mind-numbing due to its size and the fact that very few major products on the server side get released during the show. I was thinking about our mining images and the fact that we have AV1 and priv (av2) images and that that seems unnecessary.

As a result, I want to make a next-gen STH Aeon Docker image that has a few features:
  • AV1 and AV2 in a unified image
  • Auto selection with manual override of AV1 or AV2
  • Auto selection with manual override of number of threads
  • Auto selection with manualAV1 override for the STH Aeon Pool like the current images
  • Support for worker names (defaulting hostnames) for when we change software
A few thoughts I had about doing this:
  • We found that running one instance per NUMA node is most effective. Therefore we are using --cpuset-cpus. Is this the correct behavior?
  • Do we need to have an accompanying setup script and put threads/ NUMA node logic in there? For example, for all of my machines, I use a launch script which makes editing parameters for each machine extremely easy (see https://forums.servethehome.com/index.php?resources/how-to-start-mining-monero-in-docker.34/ for the Monero version)
  • The flip side is that we could just make a lot of xmrig auto-configuration with numactl and such in the Docker container.
  • Do we want to update to a newer (albeit slower) version of xmrig to get the API for polling workers and open up Docker ports for this?
  • In a script, we could have sysctl vm.nr_hugepages=128 to ensure proper performance and other parameters.
Resources for the project:
Any other thoughts or suggestions are welcome. The end-state should be something much easier to deploy.
 

archangel.dmitry

Active Member
Sep 11, 2015
224
40
28
US
I would rather have a check for "vm.nr_hugepages" with corresponding message. soft and hard memlock need to be checked as well.

Not sure if additional API is worth some loss in hashrate. Especially with the new patches coming in.
 

MiniKnight

Well-Known Member
Mar 30, 2012
3,072
973
113
NYC
If you're biasing for bigger Kubernetes clusters then I'd want everything to be in the docker image.

People that have big Kubernetes clusters that are doing this also have many of the same machines. Even if it is 400 machines of 4 types it isn't too bad to set profiles for each with the CLI inputs.

Changing to a version that defaults to AV2 but you can CLI add AV1 is a good idea.
 

jims2321

Active Member
Jul 7, 2013
184
44
28
One other change you might look at is having a setup/install script that scans the hardware or prompts the user for their hardware configuration, and then pulls down the appropriate docker image. Cpu only uses xmrig, cpu/gpu pulls down a miner that would allow cpu/gpu mining (xmr-stak or such). One other thought is allow split mining. Allow some of the docker images to mine monero, and other aeon.