search

madMAx43v3r / chia-plotter

Apache License 2.0
2.28k stars 664 forks source link

[Feature Request]: K33 Support #25

Open ChandlerFerry opened 3 years ago

ChandlerFerry commented 3 years ago

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.

BitSec01 commented 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.

madMAx43v3r commented 3 years ago

Once they announce k33 as minimum, I'll implement it, until then it's too much work.

gilnobrega commented 3 years ago

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

Forusim commented 3 years ago

@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.

BitSec01 commented 3 years ago

@Forusim He will make K33 possible. But only IF Chia announces that they are going to invalidate K32.

Forusim commented 3 years ago

@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.

madMAx43v3r commented 3 years ago

good point.. but if we go k33, I will hardcode it again, because having it dynamic is a huge pain...

Forusim commented 3 years ago

@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

SebMoore commented 3 years ago

Lol gotta love Gene: "no".

BitSec01 commented 3 years ago

@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 )

madMAx43v3r commented 3 years ago

@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.

Forusim commented 3 years ago

@madMAx43v3r What would be you assumption for RAM (Process and Temp2) usage on k33? Will it just double?

rtm125 commented 3 years ago

@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.

number435398 commented 3 years ago

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).

cjedwards commented 3 years ago

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?