question: no `-2` (temp2) configuration ? about plotng HOT 10 CLOSED

set UseTargetForTmp2 to true

from plotng.

How to set a path to TEMP2?
You only have a line for True or false to enable disable it, but how to set a target? on windows

from plotng.

I like to ask why would you want to set TEMP2 to be anything other than the target directory?

from plotng.

I like to ask why would you want to set TEMP2 to be anything other than the target directory?

Hi,
The software is made this way its not locked by design so devs intended for it to be like this.
it helps with endurance, the writes are spread across as many drives as posible.
Also since I plot on 8 SATA RAID0, the Phase 4 is moved out to that NVMe RAID and so it doesnt hurt the otehr plots and then its copied from NVMe to target HDD again without bothering the main plots.

I get better results and it helps with SSD endurance since its all spread as much as posible

from plotng.

If there no more issue, I will close this issue in 24hr

from plotng.

i would like to second this as a good idea of a feature. There are two scenarios where specifying -2 could be useful.

1. Need a different final stage drive to increase speed. For instance the temp drive is fast nvme. It does final stage to a SATA SSD to free up the nvme for the next plot running in parallel (or save space). And then final destination goes from the -2 to a slow hard dick.

2. I read that depending on platform, (windows or linux? weird?) the -2 directory coudl be the source or the destination or both. This way a user can explicitly force it to match.

from plotng.

I like to ask why would you want to set TEMP2 to be anything other than the target directory?

To greatly improve plots-per-day on the given hardware :)

In the context of chia plots create... the IO patterns for -t require the fastest R/W random IO capable storage, while the IO patterns for -2 require only modest parallel high sequential write capabilities (one-thread-per-parallel-job). -d has almost no performance requirement but does require large amounts of space to accumulate completed plots.

I cannot fit any more PCIe flash devices in my largest plotting system so I use the 3TB for -t. Then for -2 I use an 8x2.5" 10k SAS ZFS array that handles the 19 parallel jobs without any IO wait (by setting sync=disabled zfs parameter). -d is a single large 3.5" SATA HDD that gets filled up then sneakerneted to main harvester box. This is a typical configuration for a lot of matured ploting systems. If I didn't do it this way, I could only fit approx 12 or less parallel jobs on the 3TB flash array, and the slow SATA drive could never handle 18 parallel write jobs. With a separate -2 I'm able to complete 40+ plots/day vs maybe 28 I would get w/o using the ZFS array for -2.

I have hacked around the limitation by setting UseTargetForTmp2 then writing a script that checks for the existence of any *.plot files in -2/-d then copies them to my actual destination drive. The script is not ideal however. I still have to manually check how much space is available on the final target drive, since it is not reported in plotng at all, which limits the usefulness of plotng as a complete dashboard. The final target drive often fills up when I miss checking it directly, grinding the whole process to a halt if I can't clean it up fast enough once I notice the ZFS array filling up in plotng (reported as target dir).

However, a painful reality is the built-in separate -2 and -d parameter feature in chia plots create... only has knowledge about itself, so when a copy occurs from -2 to -d in the final stage of the chia process, it can overlap with another parallel plotting process. This is minimized if we have our staggers dialed-in perfectly, but with the ability of plotng to prevent jobs from firing based on the max-phase-1 parameter (an awesome feature btw- thanks !) when it is << than max-parallel, they still occasionally walk on each other, which grinds the whole process to a halt, requiring a whole restart of the stagger.

Ideally, we could create a new parameter in plotng for Temp2Directory and pass this path to chia plots create... for both the -2 and -d, then come up with a way for plotng to handle the copying of completed plots from Temp2Directory to TargetDirectory (which would now be untethered from chia entirely). Running the Temp2Directory -> TargetDirectory copy single-threaded and outside of chia in this way ensures that the target drive (which is almost always going to be a single large spinning disk) doesn't get overwhelmed by parallel sequential writes, plus frees plotng to begin the next plot job immediately after the plot is completed since -t is now free of space and ready for work from a new plot process.

@maded2 - what's your thoughts on this ?

UseTargetForTemp2 doesn't work without an outside-process hack to shuttle the plots, but then having the -2 and -d parameters passed directly to the chia plots create... process isn't ideal either because there's no assurance that parallel jobs don't clobber each other on the final target drive (plus ties up the chia process with copying the plot when it could be plotting on the now-empty -t expensive flash space sitting idle).

Does the architecture of plotng allow having the daemon process handle copying completed plots from a combined -2,-d directory into a final directory ? This is literally the only missing piece of the puzzle in plotng, at least for me. I would love the ability to maybe kill a job directly from the dashboard, and have the daemon delete all the temp files and kill the chia process, but that's just icing on the cake... this copy process is a major pain point for a lot of people. ChiaCo really should have had their daemon process handle the copying instead of the chia processes, then none of us would be in this situation :)

I wish there was an easy and obvious solution.

from plotng.

PlotNG can be/is that daemon process. However, it takes significant amount of effort to write a robust system to copy files and make sure it is correctly copied before removing the original.

I personally uses rsync in a script to do that.

from plotng.

PlotNG can be/is that daemon process. However, it takes a significant amount of effort to write a robust system to copy files and make sure it is correctly copied before removing the original.

There were 2 proposed solutions, the ideal one to just have PlotNG copy the plots, and the second-best one of configuring / monitoring free space on the true final target drive that the out-of-process script/rsync/whatever we create is coping to. Since 1 is too much of an undertaking, how about 2 ? This would mean PlotNG behavior behind the scenes is the same, but a new Temp2Directory parameter is introduced. It could be set to default of null, and the system works as it does now so all user configs continue to work w/o changes. But if Temp2Directory is not null, PlotNG could then use Temp2Directory exactly as it currently uses the TargetDirectory now when UseTargetForTmp2 is set true, then PlotNG would add free space monitoring for it and the now-new TargetDirectory (which PlotNG doesn't actually use, but is used by our external solution).

This solves the drive-monitoring problem for everyone and still allows those who have a physically separate -2 file system to function well with PlotNG. Or maybe you have an even better idea ? 🤷‍♂️ 😄

from plotng.

you know what, you're right that this is probably too much effort to build into plotng for relatively little benefit... I've settled on just using dfc in a tmux array to each of the plotters which also allows monitoring any drives I want and I just have to name them accordingly to know which are critical to plotting or not...

So just gonna close this out 👍

from plotng.