@xmagmax First I must say I'm not an expert, second different PC would have diffrent setting depend on devices it have.
Now that been said, to me your setting is a bit odd. Youe first value, which is 1, is the platform number that start from 0, 1 ,2 and so on. Normally it should be 0 because we only have 1 platform, at least mine is. The second value is the open GL device number, which also start from 0, 1 ,2 and so on. Open GL device would include all the CPU and GPU you have in your system, depend on the machine. You have to use bat file with "gpuPlotGenerator setup" command to check and decide which device you're going to use. gpuPlotGenerator setup command also tell you the rest value, but bare in mine these value are the potential max value your machine can handle. If, when plot and gpuPlotGenerator crash, you have to reduce these value (by haft).
In my case, I use RX480 8GB VRAM to plot. My setting values are 0 0 8096 32 4096 (my GPU is devidce 0, and my PC has 16 GB of RAM). I was able to plot 10TB Seagate int.HDD SATA3 in around 30Hrs, 8TB WD ext.HDD USB3 in around 26hrs, all in direct mode. But 8TB Seagate Backup plus HUB ext.HDD USB3 is an odd ball for me. Even with same setting, it took me over 5days to finish, don't know why.
So what I do to speed things up and reduce the chance of PC crash before finish plotting is to split in to smaller plot. I plot a 1GB plot onto a 1GB SSD then copy to the actual mining HDD, one at the time until finish the whole HDD.
Great work! Its working on Linux for me. For some reason it does sometimes fail halfway through quoting "error creating thread", but the actual program says that it can be restored from x step, how do you restore the plotting?
the stagger value directly relates to the amount of memory allocated to the plotting process. Nonces are computed sequentially (with 4096 sequential scoops in them), but writing a file with stagger 1
produces a 256 MiB ( 1024 * 4096 * 64Bytes) file that stored nonces like this:
0,1,2,..,4095 (1024x total)
which is very unfortunate for mining, as a lot of seeks have to be performed.
While mining, we're interested in a specific scoop in all nonces - this hardens Burst against GPU/ASIC attacks.
Therefore, the perfect organization of this example file would be
This organziation allows the miner process to read 1024 scoops needed for the particular block to be solved in one go, a sequential read of 1024 * 64 Bytes = 64 KiB, as opposed to 1024 * 64 Bytes and 1023 seeks in between (head movement).
So the plotter process computes as many nonces as fit the configured memory limit. Upon writing into the file,
all scoops 0 are collected and written sequentially,
repeat for the remaining 4095 scoops.
if you allocated 32 MiB to the plotter, the internal structure of the file is:
... (repeated for a total of 8 times).
The plotter can therefore only plot a multiple of 128 nonces (in this example).
gpuplot has another "tweak" - it uses twice the memory for a shadow copy to allow for parallel computing and file I/O.
If your stagger value is less than, say, 8 MiB (131,072), your disk may not operate optimally because it spends more time seeking then reading. You then need to optimize your file, that is: reorganize from
But there is a variant on this, and it trades compute power against IO
using the gpuplot terminology: you may plot in "direct" or "buffere" mode.
"buffer mode" was example 1 above.
"direct mode" computes file-length times the scoop 0 and writes them out.
Then it computes file-length times the scoop 0 to 1, discards 0, writes all scoop 1 out.
Repeat until finished (4096 scoops).
The problem is, scoops (64 Bytes) can not be computed "individually" but only as part of a whole nonce (4096 * 64 Bytes).
If you plot a 1 TiB file ( 1 TiB = 4,194,304 nonces ) every single scoop needs 256 MiB ( 1 TiB / 4096 ).
If you assign 4 GiB memory to gpuplot, 16 scoops can be computed in one go ( 4 GiB / 256 MiB ).
No double buffering here, as computing is slow - you throw away ~127 of 128 results - you keep only the requested 16 out of computed 4096 values.
(I think it aborts right after hitting the wanted scoop, hence 127/128 and not 255/256, a 50% speedup).
This scenario only makes sense if your IO is a lot slower than computation (most users : single disk and potent GPU).
The plotter can therefore only plot a multiple of 16 nonces (in this example).
another variant is xplotter, which has a fast mode of pre-allocating a sequential file of the target size on NTFS.
wplot (?) pre-allocated a continous file by writing out <target-size> zeroes (to have it physically sequential on disk) and then seeking in this file for writing a fully optimized file (length==stagger).
It then computes nonces as usual (scoops 0..4095), aggregates them according to available memory, and then writes out a fully optimized file by doing the seeks for perfect placement.
If we still have 4 GiB memory for plotting, the granularity is 256 ( 1 TiB / 4 GiB ).
I'm looking into developing this for supporting low power arm devices such as the Raspberry Pi
Hey, this may be what I'm looking for. I'm an unraid user as well.
Is this using the latest version of XPlotter as the plotter?
Do you also have the Blago miner in a Docker?
I will be given this a try and send some Burst your way.
If I want to plot my 8tb drive, i start from 35,962,880? Because the the last file started at 6963200 and had 28999680 nonces plotted. My friend is telling me I start at 35962880+1, but I believe otherwise.
Afaik, there's no penalty for having a gap betwixt your nonces, but there is a loss of burst-mining capacity for an overlap. So why not just start plotting at the next (convenient & memorable) round number?