Extreme performance issues with bladebit 2 (very bad)

I saw the announcement and decided to try bladebit diskplot again. The results are horrible and do not are not even in the same universe with respect to performance on the reference machines in the announcement.

My specs: 5950x, 128gb ram 3600MHz (infinity fabric 1:1), samsung 980 pro 2TB nvme pcie 4.0

madmax 110G ram drive for temp2 takes 17-18 mins to create a k32 on my system.

bladebit, for phase 1, took almost an hour.

How I compiled bladebit

git clone https://github.com/Chia-Network/bladebit.git
cd bladebit
git checkout 2.0.0-alpha-2
mkdir build
cd build
cmake ..
cmake --build . --target bladebit --config Release
./bladebit --version

This returns “2.0.0-alpha-2” as the version.

My plotting command is ./bladebit -f <farmer_public_key> -c <pool_contract_address> diskplot -a --cache 99G -t1 /mnt/nvme01 /mnt/nvme01/chiadone

Something is wrong here and I cannot figure it out. Normally I would not create a topic about this, but I feel as though the announcement became an invitation to try bladebit as madmax has had nearly no development for several months while Mr. Brenes has been actively optimizing his plotter. Unfortunate the experience as a returning user with moderate computer experience has been bad. Even the example code on the release page is wrong diskplot -f <farmer_public_key> -c <pool_contract_address> diskplot -a --cache 99G -t1 <temp1_path> <output_path>, but the releases have binaries for bladebit, not “diskplot”. I understand you need to change the binary to bladebit, but at least make the example command relative to what users will have. Explain to the users if the 99G is GiB or GB → I only need 4GB ram for my OS safely as it is headless and uses less than 1GB ram. Does that mean I can run 128GB - 4GB = --cache 124G or do I need to convert this to GiB. 119.209 GiB - 3.72529 GiB (os + overhead) = --cache 115G. Does the --cache XX include the ram required for the application? Should I set it up like madmax where I give it 110GB, or do I need to convert this to GiB? The readme does not answer any of this. Why?

Sorry if this sounds harsh but the announcement felt like a “try this, we did a really good job on this” but the performance and documentation on this has been very poor.

1 Like

I’m still looking for somebody to tell me that they created BladeBit plots with the Windows GUI (chia 1.5.0). is this really that hard of a question? IF it’s in the GUI it should work correct if not then why is it in there???

I don’t want to hear about command lines…

the blog post was extremely clear that its part of an opt in beta program. This topic is unrelated to GUI. Enroll in the beta program and get accepted or wait until it hits mainline, or Ill help you with CLI.

Very easy steps

  1. Releases · Chia-Network/bladebit · GitHub download v2.0.0-alpha2 for your platform. Get bladebit.exe and place it in a folder on your desktop. Copy the path to this folder to your clipboard. C:\Users\drhicom\Desktop\bladebit\ for example.
  2. go to your start menu and type “environment variables”


4) open a cmd window by winkey + r, type cmd
5) bladebit.exe -f <farmer_public_key> -c <pool_contract_address> diskplot -a --cache 99G -t1 D:\nvme\ E:\hdd01\

1 Like

Man, I need to figure out why my 5950X is taking 29 minutes for a k32 plot with madMAx and a 110GB RAMdisk. Bladebit disk is 25 minutes. My RAM kit is 3200, not 3600, but surely that can’t be the whole problem…?

Anyway, try downloading the alpha from here instead of building it. You can also try adding -b 64 to the command line. Part of the release notes seems to imply that it’s required but it’s not given in the example command.

Are you windows? That was about my time for a windows box.
If linux, double check your plotting nvme filesystem.
xfs is really good, use it if you can.

Nope, Linux all day.

This could be it. I was getting better times when I was using f2fs for my tmpdir. Now I’m using ext4. I’ll re-test with xfs and f2fs. Thank you!

f2fs is VERY slow for me. I do not know why. It was about 7 - 10 mins slower than xfs

Can you share your mkfs.xfs command?

yeah, like… sudo mkfs.xfs /dev/nvme0n1
I mount with noatime but it didnt have any performance implications.

xfs is very optimized ootb

Ah, the last time I tested xfs I was getting pretty deep in the weeds with mkfs.xfs options… I’ll try it with the defaults instead. Sorry to hijack your thread but appreciate the help.

Thank you sir will add to my notes.

Harold is aware that the AMD 5-series processors are having issues with Alpha 2. Hopefully I can get a system for him to test very soon.

1 Like

OK, I did a RAM OC to DDR4-3600 CL18. With some more tweaking and experimentation (and, quite frankly, simply remembering things that I failed to document when I did all my plotting last year) I was able to get madMAx down to an ~18 minute plot and Bladebit disk down to a ~22 minute plot, both using an SK hynix P41 2TB NVMe SSD with an xfs partition for tmpdir1, with a 110GiB RAMdisk for madMAx tmpdir2 and diskplot -b 64 -a --cache 99G for Bladebit 2 Alpha 2. So yes, Bladebit disk is not quite there yet on Ryzen 5000-series, but it’s not too far off.