Requirements make perfect sense and will generally be universal. 1000 series should work I think but likely would be a lot less efficient.
Maybe you could try it on either Rocky Linux / CentOS or Debian. A lot of people are reporting that Ubuntu is the slowest for both MM and BB (for about 10-20% or so).
Also, there is a bit of plotting activities for MMX project. Maybe you could add support for it (really small code changes - 20 lines or so).
if linux kernel is gcc 11 based, arc_plot should be good to run on all of them. lol
I have tried to run it on Rocky Linux 9.1, but it immediately barfs. Would be nice if you could recompile for RHEL branch and have both for download.
could you send me the err msg?
Here you go:
[jacek@i9 arc]$ ./arc_plot --help
./arc_plot: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by ./arc_plot)
...
[jacek@i9 arc]$ sudo find / -name libstdc++.so*
/usr/lib/gcc/x86_64-redhat-linux/11/32/libstdc++.so
/usr/lib/gcc/x86_64-redhat-linux/11/libstdc++.so
/usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.29
/usr/share/gdb/auto-load/usr/lib64/__pycache__/libstdc++.so.6.0.29-gdb.cpython-39.opt-1.pyc
/usr/share/gdb/auto-load/usr/lib64/__pycache__/libstdc++.so.6.0.29-gdb.cpython-39.pyc
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.29-gdb.py
[jacek@i9 arc]$ sudo strings /usr/lib64/libstdc++.so.6 | grep GLIBC
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.14
GLIBC_2.6
GLIBC_2.33
GLIBC_2.4
GLIBC_2.18
GLIBC_2.16
GLIBC_2.32
GLIBC_2.17
GLIBC_2.3.2
GLIBC_2.34
GLIBCXX_DEBUG_MESSAGE_LENGTH
By the way, this is on Rocky Linux 9.1 (CentOS replacement). Fedora is kind of Ubuntu on Debian side, so it has newer libs. Rocky / CentOS are more for long-term, so unless really massaged, it may be hard to get the latest libs installed. (Just run yum update, and all is up to date.)
The dev has already have two issues open for statically linking libraries.
He closed one, so fingers crossed he just injects the libraries into the binary so it works on more systems.
1 Like
Yeah, both Ubuntu and Fedora always have the latest libs. Those that are running either Debian or CentOS are kind of SOL. I donāt think that asking people to switch to the latest Ubuntu is going to work. I am on the CentOS side, so would have to be really hard pressed to switch to Fedora; however, would not consider switching to either Debian or Ubuntu side.
This plotter is still in a pre-production phase, so using libs that are more common should rather be a norm. I would not mind running better instrumented builds, rather than trying to have a gain of few seconds and going through extra motions to make it run. Of course, statically linked libs would solve this as well.
This is not correct, arch / gentoo have the latest libs.
This is compiled against a ancient version of gcc that only rolling releases still have in their repos.
There is literally no downside to statically link libraries for releases.
If someone is on void or some real weirdo distro, they can set their library path when launching the app and compile against the version it needs.
release 0.6.2 just published. your issue should be solved. enjoy. 
I try that. But I believe I make something wrong.
ARC_PLOT CPU + GPU plotter version: 0.6.2.1 git_commit:[b9bb3ab] **
Final Directory: /media/ed/5825B1FB399647B8/
Stage Directory: /media/ed/5825B1FB399647B8/temptest/
Number of Plots: 1
GPU plotting 1 out of 1 (2022/12/12 19:40:04)
Found cpu ram size: 528114860
Found gpu: 2
Found gpu ram size: 12723945472
using gpu 0:[ Quadro K6000 ] for plotting.
Process ID: 8471
Number of Threads: 48
Number of Buckets P1: 2^8 (256)
Number of Buckets P3+P4: 2^8 (256)
Pool Puzzle Hash:
kkkkkk
Farmer Public Key:
kkkkkkk
Working Directory: /media/ed/5825B1FB399647B8/temptest/
Working Directory 2: /media/ed/5825B1FB399647B8/temptest/
Plot Name:
plot-k32-2022-12-12-19-40-5f5b2738ebc256522330a56bae92b8f1eed2d54dfe55705888950fbbeee24a97
** Phase 1: creating plot **
[P1] Table 1 took 9.2623 sec
[P1] Table 2 took 8.96563 sec, found 0 matches
[P1] Table 3 took 2.91473 sec, found 0 matches
[P1] Table 4 took 2.99847 sec, found 0 matches
[P1] Table 5 took 2.59342 sec, found 0 matches
[P1] Table 6 took 2.27233 sec, found 0 matches
[P1] Table 7 took 1.47615 sec, found 0 matches
Phase 1 took 31.5897 sec
And the final plot size is only 8.7kB.
current arc_plot support GPU cuda compatibility > 7.5. K6000 is 5.2.
1 Like
V0.6.5 support 8 gpu plotting. Is that real?
But how can you have 8 gpu in pc? Add 4 thunderbolt card so have 8 Th4 port and connect 8 external GPU?
1 Like
PCIe risers like the ones they use in mining rigs would be easiest. I donāt think this option is intended for people who donāt have the hardware already (itād be silly to buy $7,000 in GPUs to plot).
2 Likes
TH4 at least have 40G band width, riser usually only pcie1.0x1, that wonāt work for plotting
1 Like
is it possible in lower ram with gpu plotting ?!
above post already answered this question.
see live result of arc plot
1 Like
I finally get those rams and test the arc plot
system :
cpu - 3900x
ram -128g 3600 cl 18
nvme - mp600xtpro 1tb
gpu - rtx 3090 msi
mm time 34m
arc plot 14 min
the test is good but i have problem the terminal suddenly close every 2-3 plot and i have to open again an west the time of plotting
1 Like
Interestingā¦ but I saw from the 3090 benchmark on Github, that this gpu should only take 9 minutes. (the processor used is not specified, I donāt know how much the processor affects. But yours is an excellent processor, so strange that it takes 50% more!
1 Like