Open ChandlerFerry opened 3 years ago
Great feature especially because if the K32 plots are being made too fast chia might invalidate all K32 plots and only start accepting K33 plots. Your software does make it a hell of a lot easier because we no longer need parallel.
Once they announce k33 as minimum, I'll implement it, until then it's too much work.
Once they announce k33 as minimum, I'll implement it, until then it's too much work.
pretty sure they'll have to do so within the next 6 months
@madMAx43v3r Since we see people doing phase 1 under 10 minutes with your amazing chiapos, k32 will be obsolete faster then Chia devs could dream of. Please consider k33 as minimum, since most are sitting on 1+ TB NVMe drives and do not need so much parallel plots anymore.
@Forusim He will make K33 possible. But only IF Chia announces that they are going to invalidate K32.
@RamonRobben I have read that statement, but I do not want to plot 100 TB k32 and the replot again 100 TB k33/34, if k32 will be obsolete soon.
good point.. but if we go k33, I will hardcode it again, because having it dynamic is a huge pain...
@madMAx43v3r I am not an expert, but I though that k is a linear constant? Maybe with your implementations this is different. Let's see what Chia Inc. says about the future of k32, but at the moment they just poker face: https://github.com/Chia-Network/chia-blockchain/discussions/452#discussioncomment-842628
Lol gotta love Gene: "no".
@Forusim perhaps start a fundraiser for @madMAx43v3r xD The guy is doing gods work for free. I'd assume implementing K33 would take quite some time. But perhaps the better difficulty for a plotter like this. It will not break anything and it will improve efficiency per KwH ( Chia is all green and shit so plotting has to become green too :P )
@Forusim It's not just a numeric constant, the space requirements for all the table entries changes, and if it's not a multiple of 8-bit, oh well, lot's of work.
@madMAx43v3r What would be you assumption for RAM (Process and Temp2) usage on k33? Will it just double?
@Forusim It's not just a numeric constant, the space requirements for all the table entries changes, and if it's not a multiple of 8-bit, oh well, lot's of work.
I would love a k33 version. Just being a +1 here. I get what your saying about adding in a variable option though, then having 2 versions might also be a pain to implement any additional changes.
The problem with it being only k33 without the option for k32 is that it would double the RAM/storage requirements for the plotting. Especially if you're RAM driving it, minimum ram drive would go from 110gb to 220gb. This would slow things down for people, considerably and be counter productive. Additionally, if you had a drive that could hold 99 standard k32 plots, but you could only make k33 plots, you'd be unable to fill up that last single plot on the drive with a normal k32 plot (assuming it hadn't gone obsolete at that time).
Once they announce k33 as minimum, I'll implement it, until then it's too much work.
Since -k (<=k32) is becoming a 'thing', will K33+be part of that restructure?
Due to having some awkward sized drives, I would love it if you could provide K33 and maybe K34 support.
This will help optimize drive space for the people without a pallet of drives.