i have plenty of k32 plots, we all do. is it absolutelly stupid idea to replace them with k33/k34 plots?
2 Likes
I have few k32 plots. I mostly have k34 plots, followed by k33 plots (and two k35 plots).
The chances of finding a block will not differ, based on which size plots you have (well, not by anything that matters – it will likely never change your chances of a win).
Whenever the day might come where Chia will no longer support 32 plots, I need not worry.
Also, larger plots means fewer plots. Fewer plots means less work for your harvester(s).
I learned this, because I used to get warnings in my logs that proofs were taking over 5 seconds (or something like that). Now that I have fewer plots, I never get those messages (and I have the same hardware). Nothing changed, except my plots.
But is it worth your time and effort, and your increased electrical bill to re-plot? Each person considering the above will have to decide for themselves.
2 Likes
Rember you can make k32 in memory without wearing out your SSD drives…
2 Likes
well, one good ssd drive covers pretty much of middle kind of demands.
i just feel k32 are useless i don’t know this is kind of slice of superstitious
1 Like
You can make k33 files in memory, too.
I do not know which motherboards support the most memory. But if you can fit enough RAM into a motherboard, and you have the $$ to do so, you can create k34 plots in memory, too.
1 Like
How much memory do you think it takes to make a k34 in a ram disk?
2 Likes
Just north of 4 TB.
EDIT:
Just north of 1 TB (not 4 TB).
Thinking about this some more…
Your CPU would need to be able to address that much memory. I do not know the limits and if any CPUs are capable of addressing that much memory.
The same goes for the OS. I guess a web search might shed some light. But I am not interested enough to find out. I was really only pointing out that if you can make use of enough RAM, you are not limited to k32 RAM plotting.
2 Likes
Space plotted is important, whst k size you plot with not so much.
Works out more or less equal per plotted space reward wise.
3 Likes
and yet i don’t like them
1 Like
AFAIK current Threadripper Pro goes to 2TB, Eypc to 4TB. Go for it @drhicom … Eypc for the win 
2 Likes
Please note that I edited my previous comment, because I wrote the wrong value of TB.
1 Like
Sure then, why the heck not - get plotting! It’s a great opportunity to take plotting to the next level. Take a moment to stagger K sizes to maximize space: https://plot-plan.chia.foxypool.io/
1 Like
Unfortunately, that seems to be just an urban myth. The higher the k-value plots are the less proof-dense per TB they are.
2 Likes
Interesting - that’s good to know. Appreciate the correction 8).
Looks like K34’s are left for bragging rights and futureproofing instead (which is fine of course!).
1 Like
Yes it is
Though not absolutely so.
2 Likes
Before this will kick in, Chia needs to become a viable coin. So, I would not worry about it for now. Also, in case this will be the case, Chia will give enough notice to let everyone replot. Chia can address this problem in two steps: 1. lower the filter, 2. drop k32 plots. We are nowhere close to #1, so no point really to worry about #2.
Although, the work NoSSD team started will prompt people to look for some more advanced hybrid solutions that may eventually influence how long k32 plots will be a viable thing.
Also not exactly, or rather hard to tell. Chia doesn’t have a properly done proof lookups, so the more plots are put on a single harvester, the slower those lookups are (it looks like not properly parallelized, also reporting once all relevant plots are checked - thus waiting for the slowest proof potentially on a bad drive). Increasing the k-value helps reduce lookup times. Although, I am not sure where the demarcation line is to trigger the move to higher k-values. If you check top miners on various pools, you can see that some have less than 500TB per harvester, where some have more than 1PB, and the lookups are basically the same (same percentage of stale results - mostly none). We can also assume that those big farms are running k32 plots, as those farms control a big chunk of the netspace, where percentage of other than k32 plots is basically non-existent.
Actually, another thing telling is that it looks like big farmers were opposing NoSSD the most. I would imagine that if k32 plots would be iffy, those big farms will all already switched to higher k-value plots. Although, this argument may be more appropriate as far as futureproofing farms.
2 Likes
@ivan_dulin Although k32 plots will offer an advantage, due to having an overall higher proof-dense percentage for the space that they occupy, vs higher “k” values, the differences are only on paper (so to speak).
Fill one drive with k32 plots, and fill another (same size) drive with higher “k” size plots, and each drive will offer the same estimated time to win.
Perhaps if you had 10 PB of plots, your estimated time to win might differ by an hour or two.
I am guessing at the above figures, but my guesses are to illustrate a point. Two people with the identical hardware, one using only k32 plots, and one using higher “k” size plots, will have the same estimated time to win (or very, very close).
So although the higher “k” size plots are at a slight disadvantage, they will future-proof your farm, and they will put less overhead on your harvester(s).
The strain on the harvesters is primarily the number of plots – not the size of the plots.
For example, 1 PB of k32 plots (on a single harvester) would probably cause long proof lookup times. Whereas, that same 1 PB farm, if made up of k34 plots, would not have that issue.
Also ask yourself…
If and when Chia announces that they will be retiring k32 plots, how much advance notice will they give? Are you prepared to re-plot in whatever given time is allotted? Will you have the time (no way to know about future demands on your time).
For new farmers, I recommend that they create only larger “k” size plots, and fill in gaps with k32 plots.
All of this is basically academic, because you should be in good shape, regardless of whichever “k” size you choose (as long as you do not overload a harvester with too many plots). So since it is “six on one hand, and half a dozen on the other hand”, I lean towards higher “k” sizes, for better harvester performance, and future proofing (and no harm if the future proofing never becomes necessary).
2 Likes
Also ask yourself how fast we can plot in 1-2 years compared to today.
2 Likes
Looks like it ends right there.
Just to put this into perspective, k33 plot is ~3% bigger than 2x k32. Also, k34 is ~6% bigger than 4x k32. It implies that if you are to fill 18 TB drive with k32 / k33 / k34 plots, you will end up with equivalent of about 184 / 179 / 173 k32 plots (based on Chia provided equation). So, you really need to optimize for proofs, not for size / k-values.
That is just FUD.
You missed the point of lowering the filter before the need to abandon k32 plots. Therefore, such event will not be an abrupt one, and everyone will have plenty of time to replot. Otherwise, the netspace will collapse, and this is the last thing that Chia would like to see.
1 Like