Futureproof plotting settings for K33+

I think this should be:

  temporary_directory: 
       - D:\
       - E:\
  temporary2_directory:

You can use temp 2, but it does something different from the normal temp. Starting phase 3 it writes the compressed file to this directory and then completes phase 4 there. Useful in specific cases, but in your case I think you just want to use both drives to plot on

Personally I would set max_phase_1 to 2 or 3, stagger hard to say with k33, but more than 3 minutes. I use 45 mins for k32 (also on 3900x)

Thanks a lot!
Actually, is this stagger to be set as a min. to the minutes needed to copy the ready plot to the external drive? I suppose when the plot is ready, it would be transfered from the SSD to my external drive, and if another plot starts during this period of time, it will give an error, right?

well not an error, but slows everything down yes. so you are right that you wan to keep that as minimum time with a little room to spare.
I also use the stagger to just spread out the plots so there is a more balanced load on the system.

For instance if i just run 6 plots at the same time using 8 threads for phase 1, my cpu load is really high and even the noctua u12A has a hard time keeping it below 75c, phase 2,3,4 is like a background task in comparison. Phase 3 on the other hand is also very I/O heavy
So i like to spread it out a bit, but some people also get good results with minimal stagger. every system is a bit different so jjust have to see what works for you

1 Like

Hi, OK. I will try this one and share here the results:

  • name: testworker
    max_plots: 50
    farmer_public_key:
    pool_public_key:
    temporary_directory:
  • D:\
  • E:
    temporary2_directory:
    destination_directory: F:\ (My external HDD of 28TB)
    size: 33
    bitfield: true
    threads: 8
    buckets: 128
    memory_buffer: 8000
    max_concurrent: 6
    max_concurrent_with_start_early: 7
    initial_delay_minutes: 0
    stagger_minutes: 60
    max_for_phase_1: 2
    concurrency_start_early_phase: 4
    concurrency_start_early_phase_delay: 0
    temporary2_destination_sync: false
    exclude_final_directory: false
    skip_full_destinations: true
    unix_process_priority: 10
    windows_process_priority: 256
    enable_cpu_affinity: false

Did someone who knows more than I tell you that for your setup 8 threads is better than 4? Usually 4 is best, but I know that there are exceptions.
Seems to me that 8 threads would make the concurrent phase one problem worse.

Iā€™m not sure if the OP has the right mindset here. The following is pure speculation, just my 2 cents.

The primary reason to increase the minimum k size would be to prevent a grinding attack where you create a new plot (or possibly just phase 1) such that the plot automatically passes the filter. If you read the docs, itā€™s not really clear if this type of attack would ever be more profitable than simply creating the plots and farming like weā€™re doing today. But letā€™s say it is profitable at some point in the future.

This attack doesnā€™t become feasible until phase 1 can be run in less than 30 seconds. Iā€™m sure thereā€™s still some optimization to be squeezed out of the plotting process, but otherwise weā€™re just waiting for Mooreā€™s Law to reduce the time. If the best anyone has done so far is 1 hour, then I think weā€™re at least a decade away from that 120x improvement (7 doublings).

The decision to increase the minimum k size would extremely disruptive, so it would not be taken lightly. There would likely be a 1+ year advanced notice so that everyone would have ample time to replot.

Hereā€™s where my speculation comes in. If the network increases the minimum k to 33, that decision would only be valid for 18-36 months. This is because of Mooreā€™s Law and the fact that it takes about twice as long to create a k33 as a k32. So it would make much more sense to bump up the minimum by 3 to k35 so the new plots would still be viable for at least 5 years and at most 24 years. Therefore, plotting k33s simply to future-proof your system isnā€™t a great option.

Again, pure speculation. What do you think?

as mentioned in this thread, there is a link to a plotter that does phase 1 in 20 minā€¦
and this approach can lead to GPU assisted plotters with additional speed improvements.

The need for k33ā€™s sooner than later are indeed speculation that the plotter speeds will advance faster than anticipated.

You have a valid point that k33ā€™s may get skipped at that time and we move to k35ā€™s for example since pretty much everyone needs to replot when k32ā€™s become obsolete.

1 Like

Ah, sorry I missed that as I scanned the thread. So only 5 or 6 doublings would be necessary before the attack could potentially be performed. I still think it would make more sense to leapfrog a few kā€™s when the time does come to increase the value, though. As long as consumer hardware in the future is capable of creating e.g. a k35.

I plot nothing but K33s. If Chia economics actually work out and Iā€™m still in the game then I will start pumping out K34s.

I do not anticipate a skip to K34s or better, but I do think we will get to K33s sooner than most have expected ā€¦ seems to me that the network size needs to double again before a switch from K33s to K34s is needed. If the network is still expanding at that rate then we are doomed so Iā€™m not going to worry about it much, lolz!

No, thatā€™s not how it works. The need to increase the minimum k size will be because of the grinding attack I mentioned earlier. It has nothing to do with the network size.

1 Like

Interesting ā€¦ youā€™ve spurred me to research further ā€¦

Youā€™ll find it in Chiaā€™s consensus doc:

.
Hereā€™s the relevant part:

Short range replotting attack

Plotting usually takes several hours (8 hours for a k32 in beta 14 with one core), but it is very parallelizable, so attackers might find ways to create plots after a challenge is released, and then delete the plot, in effect being able to farm without storing the space continuously. This will likely require expensive specialized hardware with fast memory, since the plot must be created in time for the infusion (less than 30 seconds).

2 Likes

yarg ā€¦ I get it ā€¦ here plotting K33s cuz I think Iā€™m safe. No way I can efficiently plot (or store ā€¦ my 8TB drives are hugely wasteful if plotting K34s) K34s or better with my hardware.

As Chia drops under $600 I hope for better Chia economics soon or my first thought, business venture, second thought, oops I did not factor in exponential growth, I guess itā€™s an expensive hobby now ā€¦ will become third thought, memory of ventures pastā€¦

I donā€™t think thereā€™s much value in plotting k34s right now, unless itā€™s just out of curiosity or novelty. To summarize my points:

  1. K32 is probably safe for at least a decade, and possibly much longer.
  2. K33 is useful for filling in extra space because itā€™s slightly bigger than 2 x k32.
  3. If/when the minimum size does increase, itā€™ll probably jump up by more than just one level, so plotting k33s will not do anything to future-proof your system.

I will continue to plot K33s. I donā€™t know if and when they will jump or if they will jump more than one level.

I do know that in 3-15 years, depending on who you listen to, K32s will become useless. K33s may become useless as well ā€¦ or they may not ā€¦ so my bet is better placed producing K33s on the basis that K33s might be adequate.

I also understand that K33s stand the test of time better integrity wise though I am no expert on this.

I am now an expert on tuning my machine for maximum plotting. One thing I found (contrary to many comments I had read) was that I produce three K33s in less time than six K32s. This 12% advantage was the final reason I went with K33s.

My i5, 4 core 8 thread plotting rig runs hard and hot at almost constant 100% CPU usage plotting 6 K32s. It runs hard with quick breaks and not alarmingly hot plotting 3 K33s. On my machine plotting the three larger K33 plots is a fair bit easier on my CPU than plotting 6 smaller K32 plots.

I believe this is also why it plots three K33s in 12% less time than six K32s.

2 Likes

i am building a setup for chia using Amd threadripper 3970 with wrx80 pro , 4x2tb nvme (temp drive) and 128 ddr4 4000 with 80tb segate pro. So am wondering how many plot in parralel i can run and what settings I should use to get maximum performance thnxs in advance

Yes. Was advised for 8 threads to try. I will start the test tonight and run it for 24hours to see how plots it can make.

So with madmax plotter can we start another instance after phase 1 has completed?

Maybe :slight_smile:

The MadMax plotter is designed to use all available resources for a single plot, there should in theory not be any resources left to do multiple plots in parallel.

but because there are different resources being used (RAM, CPU, Disk IO etc.) maxing out all of them at the same time is different for each system. and each phase leans more on one type of resource as well.

the result is that you maybe able to parallel plot still, but certainly not many (like 10, 20) as with the official plotterā€¦ but you can try 2 plots in parallel.

Thanks for this.
I tried 4 threads per plot, does indeed seem faster.

Just trying to make sure I understood you correctly.

16 threads Ć· 2 = 8
64GB ram Ć· 4 = 16
5400GB m2 Ć· 256 = 21

So I could run 8 plots in phase 1?

Iā€™ve tried 6 in phase 1 while 3 are finished phase 1 and my cpu spikes to 90 / 95 % used but drops to 40/ 50 % so def still room to play.

I had only been running 7 in phase 1 then letting them finish then starting more, so this should boost my numbers.