>128 buckets and ram usage

[syadnom]

-You almost never want to use any bucket values other than 128.
-Less buckets requires more RAM for each plotting process. 64 buckets requires twice the RAM.

Does using more buckets use less RAM? does 256 buckets use half the RAM?

Let's say I'm on a RAM starved system but have TONS of IO. Like a 2TB NVME card but only 8GB of RAM.

Knowing that more buckets is most likely going to cause more IO and have some negative affect on plotting speed. Being limited to 2 concurrent plots (without big efforts to stagger) the RAM is the bottleneck. Will moving up to 256 buckets half the RAM usage and let me plot 4 concurrent?

I'd really extend this out, I have some 12 bay machines and I'd love to run 12 plots on them but that could be ~40GB of RAM while I have 24GB in the system.

I'm using straight numbers here, I know I can get more out of less with careful staggering but I don't want to make the conversation unnecessarily complex.

[padik11]

Do the tests. In my experience, the maximum amount of RAM is only used at certain times, not all the time.

[chiabug]

I plot with machines that have 4 or 8 GB of ram. My analysis shows that the max allocated ram is not used by much of the process. RAM is not generally the bottleneck.

[defstm]

Buckets are SAS drive based elements implemented into chia. SAS drives if not used as servers utilized bucket configuration to speed up the amount of file size and write speed. If you have the RAM, THREADS, CPU, GOOD CONNECTION ETC, you can change the bucket size. SAS always ran good on 68 to 78 buckets. 68 and bellow can cause write errors, so test should be done to see how well your system writes. If you use Linux, Linux has a system I believe in it that can help stabilize these writes as you get smaller on buckets size. The system though rewrites failed sectors and could possibly cause a confliction with the farming system. Although I think you would have to turn this on in Linux for it to utilize the rewrite. You can also open the rewritten sector and correct it with it's original intention, but you have to know calculations etc etc etc. Just change your buckets if you want to. Keep your buckets in a safe area from 78 up, or try lower if you want to. All you are doing is transferring writes in larger sizes and trying to speed it up, or keep up with more ram use.

[room101-dev]

-You almost never want to use any bucket values other than 128.
-Less buckets requires more RAM for each plotting process. 64 buckets requires twice the RAM.

Does using more buckets use less RAM? does 256 buckets use half the RAM?

Let's say I'm on a RAM starved system but have TONS of IO. Like a 2TB NVME card but only 8GB of RAM.

Knowing that more buckets is most likely going to cause more IO and have some negative affect on plotting speed. Being limited to 2 concurrent plots (without big efforts to stagger) the RAM is the bottleneck. Will moving up to 256 buckets half the RAM usage and let me plot 4 concurrent?

I'd really extend this out, I have some 12 bay machines and I'd love to run 12 plots on them but that could be ~40GB of RAM while I have 24GB in the system.

I'm using straight numbers here, I know I can get more out of less with careful staggering but I don't want to make the conversation unnecessarily complex.

Long been known that 128 is optimal default value, just don't mess with it.

I played months ago with memory, optimum for me is 4,000, when I use 8,000 its actually slower, the requested is 3900; Counter intuitive that more is less, but this is life under chia shit-ware, note they have no parallel-processing, its just dumb code;

I have 512GB of ram, so when I started I went what the hell why not 32gb per plot, hell why not just ram-disk the entire plot? Again, its all actually slower, better to diversify the controller(s) workload.

optimal plotting is 4x plots per NVME, staggered +30 minutes; I run three NVME drives on my plotting machine. Two on MOBO, and one on pcie-4x16, plot generation is 6hr average, per plot

Most important is the best NVME -t, and at good -2 Sata-SSD, and a physically connected 7200rpm hdd -d for plot storage

[room101-dev]

-You almost never want to use any bucket values other than 128.
-Less buckets requires more RAM for each plotting process. 64 buckets requires twice the RAM.

Does using more buckets use less RAM? does 256 buckets use half the RAM?

Let's say I'm on a RAM starved system but have TONS of IO. Like a 2TB NVME card but only 8GB of RAM.

Knowing that more buckets is most likely going to cause more IO and have some negative affect on plotting speed. Being limited to 2 concurrent plots (without big efforts to stagger) the RAM is the bottleneck. Will moving up to 256 buckets half the RAM usage and let me plot 4 concurrent?

I'd really extend this out, I have some 12 bay machines and I'd love to run 12 plots on them but that could be ~40GB of RAM while I have 24GB in the system.

I'm using straight numbers here, I know I can get more out of less with careful staggering but I don't want to make the conversation unnecessarily complex.

Sounds like your making a problem, where none exists. You can plot 4x on a NVME EVO980 class 1-2TB staggered +30min

U MUST daily 'sudo fstrim -av', otherwise your plotting will slow down to zero

Best you will ever see is plots ever six hours

"chia plots create -t /dev/nvme -2 /dev/ssd-sata -d /dev/hdd'

That is it, I have explained the nvme above, the ssd can be anything > 1TB, and the HDD must be a physcially fast HDD of new quality, or it will fail the new 5second rule for 'chia plots check'

The system should be 32GB ram, 16 core, I run three NVME's, two on mobo, one on pcie4x16 board

This is not a cheap hobby to earn, $1/day; right now around $10/day (1,000 plots) been on HPOOL since day one, as I always knew solo-mining was a scam using shitty-sw as provided, never seen any problems with the HPOOL mining code, never seen anything from chia-net dev working. No, HPOOL doesn't require you to send them your priv-key, that is the BIG lie from chia-net team FUD, they hate competence, so they spread lies.

...

The only reason I started CHIA months ago, was that I can't buy GPU's anymore, so I wanted to try something new; I suspect that once SPACE here hits 1,000EB that everything will implode, enjoy the ride. Certainly the constant here is that CHIA-NET-DEV will never get their feces together, just shows you that an IPO could issue a 'dead dog' and still make money.

[Chilli71]

I'm currently plotting with SAS drives on Debian, using 64 buckets and 6800 RAM per K32 plot. I'm doing 16 plots in parallel.
Until now nothing did complain.
But I will run a check over the plots to make sure there were no hick ups.
There is a good reason reducing the buckets: Minimizing seeks. As far as I saw for each bucket a file is created on the HDD and the plotting jumps permanently between the files. Less files less seeks more streamlined.