This PR adds a Docker Image to improve portability. We can use that image for both Windows and Linux machines.

How it works

You can test a preview generated image with the following command on your machine:

docker run \
  -v <path-to-your-tmp-dir>:/mnt/harvester \
  -v <path-to-your-final-dir>:/mnt/farm \
  odelucca/chia-plotter \
    -t /mnt/harvester/ \
    -d /mnt/farm/ \
    -p <pool-key> \
    -f <farm-key>

Of course, you can provide whatever arguments you want after the image name.

Also, you can make an alias, like:

alias chia-plotter="docker run \
  -v <path-to-your-tmp-dir>:/mnt/harvester \
  -v <path-to-your-final-dir>:/mnt/farm \
  odelucca/chia-plotter"

And call it with:

chia-plotter <args>

I've run a few tests, and it seems that it has a small performance cost. I was not able to define the exact percentage of the performance decrease yet, but still I think that is a pretty good alternative for running the plotter in Windows machines.

Future improvements

I see two important future improvements, they are:

1. We need to host this image in a proper Docker repository
2. We could create a simple script (maybe inside the plotter itself?) where it could identify the remaining farm disk storage and automatically work to fill it up. By doing so, we could simply launch new containers for each harvester memory / rig

So I'm using dual Xeon (8 cores, 16 threads each) server with 64G of ram and running Windows 2019 server. I start it with the following command (alpha version 0.2):

.\chia_plot.exe -p "key" -f "key" -n 1 -r 24 -u 7 -t E:\directory\ -d D:\directory\

What I get as a result is:

Final Directory: D:\directory\
Number of Plots: 1
Process ID: 7128
Number of Threads: 24
Number of Buckets: 2^7 (128)

And after that process is killed and does not continue.

I tried with lower number of threads (went even down to 4).

Was looking for help and got same configuration from a friend with same end result. Process killed and he's also not able to find a way to make it work.

Any ideas?

Getting some compiling errors, is this info helpful:

-- Configured operating system: MACOSX
-- Configured GMP: /opt/homebrew/lib/libgmp.a
-- Compiler flags:  -Wall   -O3 -funroll-loops -fomit-frame-pointer -pthread
-- Linker flags: -L/Applications/Chia-arm/maxplotter/chia-plotter/build/_deps/relic-src/src/low/gmp/  -static
-- Configured /Applications/Chia-arm/maxplotter/chia-plotter/build/_deps/relic-src/include/relic_conf.h.in
SODIUM_FOUND in src/CMakeLists.txt
-- Configuring done
-- Generating done
-- Build files have been written to: /Applications/Chia-arm/maxplotter/chia-plotter/build
[  0%] Building CXX object CMakeFiles/test_disk_sort.dir/test/test_disk_sort.cpp.o
[  0%] Built target arith_objs
[  2%] Built target blstmp
[  4%] Built target blake3
clang: error: unsupported option '-fopenmp'
[  6%] Built target fse
make[2]: *** [CMakeFiles/test_disk_sort.dir/test/test_disk_sort.cpp.o] Error 1
make[1]: *** [CMakeFiles/test_disk_sort.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Scanning dependencies of target chia_plotter
[  6%] Building C object CMakeFiles/chia_plotter.dir/lib/chacha8.c.o
[  7%] Linking C static library libchia_plotter.a
[ 92%] Built target relic_s
[ 92%] Built target chia_plotter
make: *** [all] Error 2

This automatically builds a Docker image every time you commit, and pushes it to Docker Hub with the commit hash as the tag and sets it to 'master'. Every time you create a GitHub release, it will tag that with its git tag and sets the 'latest' tag to it. Also, pull requests will trigger a build but will not push. (for obvious reasons.) See it in action here.

You need to add some GitHub Secrets for it to work properly. Go to repo Settings, Secrets, and add DOCKERHUB_USERNAME and DOCKERHUB_TOKEN. After that, it will work properly.

I have an issue,it seens no makefile OS:ubuntu18.04 cmake version:3.20.3 ,this is CLI print:

• The CXX compiler identification is unknown CMake Error at CMakeLists.txt:3 (project): No CMAKE_CXX_COMPILER could be found.

  Tell CMake where to find the compiler by setting either the environment variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH.

-- Configuring incomplete, errors occurred! See also "/chia-plotter/build/CMakeFiles/CMakeOutput.log". See also "/chia-plotter/build/CMakeFiles/CMakeError.log". make: *** No targets specified and no makefile found. Stop. root@yui-virtual-machine:/chia-plotter#

cmake error log:

Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed. Compiler: CMAKE_CXX_COMPILER-NOTFOUND Build flags: Id flags: --target=arm-arm-none-eabi;-mcpu=cortex-m3

The output was: No such file or directory

Can anyone solved it?

regards!

From user TER on discord:

Spec = AMD 5950x, 64GB RAM 3200mhz, 2TB Nvme SSD

Setting 1: -r 16, 128 buckets Finish in 2116 seconds

Setting 2: -r 32, 128 buckets Finish in 2162 seconds

Setting 3: -r 20, 512 buckets Finish in 2462 seconds But interestingly, Phase 1 down from 1000~ seconds to 654 seconds. Phase 3 went from 650 seconds to 1576 seconds. So total time still the same.

Setting 4 : -r 20, 128 buckets Finish in 2113 seconds

I was wondering, what I did wrong in my Setting 3, as the Phase 1 improved by 40%, but Phase 3 dropped by 60%, which end up with the same total time.

/Volumes/null/chia-plotter/include/chia/phase3.hpp:48:24: error: no matching function for call to 'min' const auto count = std::min(L_position - L_offset, L_buffer.size()); ^~~~~~~~ /usr/local/opt/llvm/bin/../include/c++/v1/algorithm:2594:1: note: candidate template ignored: deduced conflicting types for parameter '_Tp' ('unsigned long long' vs. 'unsigned long') min(const _Tp& __a, const _Tp& __b)

correction seems to be: const auto count = std::min<unsigned long>(L_position - L_offset, L_buffer.size());

Hi !

First and foremost, I've run a few tests yesterday with your plotter. The speed is impressive! My rig takes ~6h to plot using Chia default plotter, and with your library, it took only 1h10min (6x faster).

Anyway, during my tests yesterday I tried two scenarios:

• Serial plotting
• Parallel plotting

While serial plotting, it took 1h10min, but while parallel plotting (with proper stagger minutes) it took 3h30min (running 3/4 plots at the same time)

So, my question is, since we assume this plotter optimizes the resource usage. Does it make sense to try to parallel plot? In my simple test scenario, it seems that while parallel plotting the plot time increased at the same rate. So, IMHO, it seems that we optimize the plotting so much that parallel plotting doesn't make sense.

I would like to know your opinion regarding this.

First, thank you for this fantastic plotter! Increased my time even over the optimized pechy version of chiapos by almost 50%!

Now, my issue/request: When you do chia-plotter --help, it says: "-d, --finaldir arg Final directory (default = tmpdir)", but if you don't use the -d option, leaving it to default to tmpdir, and use the -G toggle to alternate tmpdir and tmpdir2 with each run, the final destination does not stay consistent with the currently running tmpdir, instead it stays as whatever the original tmpdir was.

The reason this matters is, I'm running tmpdir on one NVME drive, and tmpdir2 on a separate NVME drive for better throughput. I toggle the tmpdirs so that the wear on the NVMEs is more even. But when the final copy takes place, I want the destination to be on the same device that the plot was produced (the current tmpdir), so that no actual copy needs to take place, it's just a rename. Instead, what I'm getting is that the first, third, fifth runs are kept on the same drive with an instant rename, while the second, fourth, sixth runs are forced to copy from what was my tmpdir2 device on the odd numbered runs to my odd-tmpdir device, adding a couple of minutes and unnecessary 100gb write to my every other plot. I have cron jobs set up to properly archive from both tmpdir and tmpdir2 when plots are found there, and everything would work beautifully if plots created when tmpdir2 alternated to become the tmpdir would stay where they are for the final copy, but the way it is, the completed plots are always forced to wind up in the original tmpdir.

Thanks for any help!

Just wanted let you know! Nice work! The server was rather busy at the time too so I guess I can get around 10% better time. Plotted on raid5 with 6 x 800gb enterprise sas ssd's. got nvme too but didn't run on them now.

I'm not sure how to put in the pool key etc yet but I suppose that's coming :) In testnet its apparently possible to plot for pools now, I'm going to replot at soon as it get released and hopefully with your code instead.

I was able to stack the original plotter and get one every 1h, I think I should be able to stack this 2 maybe 3 times :)

(27ebfcbf0a47ee3f57ad48811e50d64db72676db)

Phase 1 took 2176.96 sec
real    36m17.068s
user    344m11.493s
sys     27m20.482s

Phase 2 took 1610.95 sec
real    26m51.067s
user    105m8.773s
sys     8m52.344s

Phase 3 took 1371.42 sec, wrote 21877156374 entries to final plot
real    22m51.629s
user    137m53.501s
sys     20m29.217s

Phase 4 took 129.688 sec, final plot size is 108835549588 bytes
real    2m9.796s
user    9m27.843s
sys     0m37.823s

Hello.

I have a problem with the Mad Max plotter. I've been testing it for 6 days and it always fails. Crashes without registration error and in any phase. Also I tested with many combinations of parameters. I have the lastest commit from github.

I have 3 PCs for plots. Specs: Ubuntu 20.04 32 Gb mem Intel I5 10400 (6c/12Th) Tmp drive: 2x1 TB NVMe WD 750 black (RAID 0) Dst drive: HDD 10 TB Seagate

Logs

PC 1: [P4] Finished writing C2 table Phase 4 took 63.1196 sec, final plot size is 108820004972 bytes Total plot creation time was 2761.72 sec (46.0287 min) Started copy to /media/dtanel/hdd1plot/plot-k32-2021-06-15-17-42-ce5581aa1b3d7cefbff21e297d515f6f3f66529abd288df0abf2d4>Crafting plot 5 out of 6 Process ID: 27037 Number of Threads: 10 Number of Buckets: 2^7 (128) Pool Public Key: 928a308d319b9144c66258e504afc5513e0af5da995b4a805fe1a2dca092e37d162d4402e95ac9cf06701d1dfc2654a6 Farmer Public Key: 8f81d7a136514c4e2445573387623c3bf13c7610d963e39815ecb0bda98c5ffc95e627ab3e642f155d0f85c4ca12e1f8 Working Directory: /mnt/ssdtemp/ Working Directory 2: /mnt/ssdtemp/ Plot Name: plot-k32-2021-06-15-18-28-9cfc1805abf1ef8eb3377fdc389c03912b0647f4e40e56645bd79f1ed2a7d552 [P1] Table 1 took 23.6587 sec [P1] Table 2 took 198.889 sec, found 4295039052 matches

PC 2: Number of Plots: 2 Crafting plot 1 out of 2 Process ID: 3252846 Number of Threads: 12 Number of Buckets: 2^7 (128) Pool Public Key: 928a308d319b9144c66258e504afc5513e0af5da995b4a805fe1a2dca092e37d162d4402e95ac9cf06701d1dfc2654a6 Farmer Public Key: 8f81d7a136514c4e2445573387623c3bf13c7610d963e39815ecb0bda98c5ffc95e627ab3e642f155d0f85c4ca12e1f8 Working Directory: /mnt/ssdtemp/ Working Directory 2: /mnt/ssdtemp/ Plot Name: plot-k32-2021-06-15-18-00-7544723d5d6dbebafff23b862445a2768805cb1d6c8b33cc7f9f8f4db3497f07 [P1] Table 1 took 20.3757 sec [P1] Table 2 took 187.388 sec, found 4295043619 matches [P1] Table 3 took 216.747 sec, found 4295123903 matches [P1] Table 4 took 265.005 sec, found 4295096255 matches [P1] Table 5 took 260.14 sec, found 4295125307 matches [P1] Table 6 took 249.603 sec, found 4295090098 matches [P1] Table 7 took 195.129 sec, found 4294939112 matches Phase 1 took 1394.51 sec [P2] max_table_size = 4295125307 [P2] Table 7 scan took 15.5494 sec [P2] Table 7 rewrite took 32.9628 sec, dropped 0 entries (0 %) [P2] Table 6 scan took 39.874 sec [P2] Table 6 rewrite took 67.0465 sec, dropped 581374701 entries (13.5358 %) [P2] Table 5 scan took 38.4818 sec [P2] Table 5 rewrite took 63.9578 sec, dropped 762078716 entries (17.7429 %) [P2] Table 4 scan took 38.0322 sec [P2] Table 4 rewrite took 63.7838 sec, dropped 828922210 entries (19.2993 %) [P2] Table 3 scan took 37.7558 sec [P2] Table 3 rewrite took 62.6074 sec, dropped 855189544 entries (19.9107 %) [P2] Table 2 scan took 37.6382 sec [P2] Table 2 rewrite took 63.1996 sec, dropped 865585616 entries (20.1531 %) Phase 2 took 568.038 sec Wrote plot header with 268 bytes [P3-1] Table 2 took 51.7436 sec, wrote 3429458003 right entries [P3-2] Table 2 took 44.3415 sec, wrote 3429458003 left entries, 3429458003 final [P3-1] Table 3 took 67.7006 sec, wrote 3439934359 right entries [P3-2] Table 3 took 46.3265 sec, wrote 3439934359 left entries, 3439934359 final

PC 3: Crafting plot 5 out of 6 Process ID: 61559 Number of Threads: 10 Number of Buckets: 2^8 (256) Pool Public Key: 928a308d319b9144c66258e504afc5513e0af5da995b4a805fe1a2dca092e37d162d4402e95ac9cf06701d1dfc2654a6 Farmer Public Key: 8f81d7a136514c4e2445573387623c3bf13c7610d963e39815ecb0bda98c5ffc95e627ab3e642f155d0f85c4ca12e1f8 Working Directory: /mnt/ssdtemp/ Working Directory 2: /mnt/ssdtemp/ Plot Name: plot-k32-2021-06-15-18-31-3c67e66c7b417e01e54c1cdbacc9e1ff4805e5171c68839ad2fb73949841f204 [P1] Table 1 took 24.6473 sec

Can you help me? Thank you

Recently I Entered the world of Chia (I was about to Farm Chia plots after 1 weeks of wallet sync);

I am using Ubuntu-22.04 (Running Natively on a SSD) Chia Blockchain version 1.5.1 (GUI Version).

Recently I had a notification on the Ubuntu showing up a system update notification (which included an update for chia on the preview) and I updated and restarted the system. After that the Chia Blockchain started showing the MadMAx plotter was not installed when plotting a new plot.

I tried uninstalling the Chia Blockchain app and reinstalling it, and tried various command shown on the internet to install the MadMAx plotter, but I was not able to resolve it. So at last I erased my system and reinstalled the Ubuntu-22.04 again (Sync started from first) and downloaded the Chia app from official page using terminal: https://github.com/Chia-Network/chia-blockchain/wiki/INSTALL#ubuntudebian, and its the GUI Version again but the error still continuous. All the images added here are taken after fresh installation of ubuntu-22.04. The system I am using is only for chia not for any other purpose!

Website Links I have visited:

1. How To Install MadMAx Plotter on Ubuntu 20.04 | Incredigeek

2. 1.2.11 missing Mad Max plotter in list

I am not sure what to do, please someone help me. Thank You very much,

Eagerly Waiting for your replay,

[root@localhost chia-plotter]# git pull Username for 'https://github.com': xxx Password for 'https://[email protected]': remote: Repository not found. fatal: repository 'https://github.com/dendil/chia-plotter.git/' not found [root@localhost chia-plotter]#

the -K option is not always applied when running phase 2 in a rewrite cycle (even subphases). restarting the program sometimes helps. I can not clearly catch the cause of this bug. if the parameter works, then rewriting the tables takes about twice as long as scanning. if the parameter is ignored, then 6 times more. at the same time, in terms of processor load, I observe a significant decrease in employment.

Below are examples of launch and logs:

===============================

C:\Users\GMND\AppData\Local\chia-blockchain\app-1.5.0\resources\app.asar.unpacked\daemon\madmax\chia_plot.exe -k 32 -x 8444 -n -1 -r 8 -u 256 -v 256 -K 4 -t D:\TEMP\ -2 R:\ -d D:\CHIA_NFT_PLOTS\FARM_1\ -c XXX -f XXX

==============SLOW================= [P2] max_table_size = 4294967296 [P2] Table 7 scan took 10.4885 sec [P2] Table 7 rewrite took 85.6975 sec, dropped 0 entries (0 %) [P2] Table 6 scan took 24.8612 sec [P2] Table 6 rewrite took 163.096 sec, dropped 581566470 entries (13.5478 %) [P2] Table 5 scan took 24.2158 sec [P2] Table 5 rewrite took 155.927 sec, dropped 762292550 entries (17.7534 %) [P2] Table 4 scan took 24.3306 sec [P2] Table 4 rewrite took 153.72 sec, dropped 829137030 entries (19.3073 %) [P2] Table 3 scan took 23.8456 sec [P2] Table 3 rewrite took 153.344 sec, dropped 855283939 entries (19.9147 %) [P2] Table 2 scan took 24.0242 sec [P2] Table 2 rewrite took 152.228 sec, dropped 865677337 entries (20.156 %) Phase 2 took 998.292 sec

=============SPEED================== [P2] max_table_size = 4295026397 [P2] Table 7 scan took 10.5786 sec [P2] Table 7 rewrite took 27.3296 sec, dropped 0 entries (0 %) [P2] Table 6 scan took 25.0182 sec [P2] Table 6 rewrite took 47.7223 sec, dropped 581323905 entries (13.5349 %) [P2] Table 5 scan took 24.3874 sec [P2] Table 5 rewrite took 44.4134 sec, dropped 761974286 entries (17.741 %) [P2] Table 4 scan took 23.8291 sec [P2] Table 4 rewrite took 43.9112 sec, dropped 828893369 entries (19.2989 %) [P2] Table 3 scan took 24.3002 sec [P2] Table 3 rewrite took 43.5669 sec, dropped 855091557 entries (19.9091 %) [P2] Table 2 scan took 23.9598 sec [P2] Table 2 rewrite took 45.9016 sec, dropped 865614536 entries (20.154 %) Phase 2 took 387.812 sec

Had no idea how to describe this in a proper way so here is the background: Although I know spindowns of harddisks is a controversial topic: I want to let my chia harddisks spin down. Af first I was thinking of making k39 plots, but that's not really feasible. Therefore I want to put (k33 or k34) plots with the same filter index on the same drive. By doing so the disks have a lot of time to spin down.

So here is the real question: Is it possible to create plots with a constant filter index? So I can choose on beforehand?

AMD 5950x 128GB 3600 2x1.6TB PM1735 Clear Linux kernel 5.12 I have problem with k33 and k34 plots. As i observed the main difference starts from [P2] Table 6 rewrite If it goes SLOW than, as per Htop, all [P2] Table x rewrites are Single Core 100% and other cores 10-20% [P2] max_table_size = 8591960036 [P2] Table 7 scan took 37.1078 sec [P2] Table 7 rewrite took 62.7559 sec, dropped 0 entries (0 %) [P2] Table 6 scan took 43.7843 sec [P2] Table 6 rewrite took 346.423 sec, dropped 1162409851 entries (13.5306 %) [P2] Table 5 scan took 42.7258 sec [P2] Table 5 rewrite took 317.952 sec, dropped 1523678697 entries (17.737 %) [P2] Table 4 scan took 43.0958 sec [P2] Table 4 rewrite took 315.809 sec, dropped 1657525624 entries (19.2956 %) [P2] Table 3 scan took 41.9618 sec [P2] Table 3 rewrite took 320.874 sec, dropped 1710002810 entries (19.9067 %) [P2] Table 2 scan took 41.8325 sec [P2] Table 2 rewrite took 320.281 sec, dropped 1731051201 entries (20.1521 %) Phase 2 took 1951.04 sec If it goes FAST than all cores are 70-90% used [P2] max_table_size = 8591485063 [P2] Table 7 scan took 27.2468 sec [P2] Table 7 rewrite took 56.8793 sec, dropped 0 entries (0 %) [P2] Table 6 scan took 45.1812 sec [P2] Table 6 rewrite took 90.4128 sec, dropped 1162401340 entries (13.5309 %) [P2] Table 5 scan took 43.7353 sec [P2] Table 5 rewrite took 86.8796 sec, dropped 1523755776 entries (17.7379 %) [P2] Table 4 scan took 42.9656 sec [P2] Table 4 rewrite took 85.4762 sec, dropped 1657598359 entries (19.2965 %) [P2] Table 3 scan took 42.7092 sec [P2] Table 3 rewrite took 84.9902 sec, dropped 1710037887 entries (19.9072 %) [P2] Table 2 scan took 42.5686 sec [P2] Table 2 rewrite took 84.6988 sec, dropped 1731088017 entries (20.1523 %) Phase 2 took 750.125 sec per final i have difference Total plot creation time was 4306.52 sec (71.7754 min) and Total plot creation time was 2983.01 sec (49.7169 min) Hope it helps to find the problem. Best regards