Seeking Assistance with High Rate of Stale Partials

I’m experiencing an issue with an unusually high rate of stale partials (around 80%) in my farming. I have only noticed it since reduced payouts from Spacepool. Below, I’ve outlined my setup, the problem, and the steps I’ve taken so far.


  • Harvester/Full Node: Running in a container technology (CT) environment (DELL R620), provisioned with ample RAM and CPU resources.
  • Storage: Plot directories are bindmounts of drives mounted to the Proxmox VE via HBA with a SAS expander, ensuring what should be efficient disk I/O. Currently I have 50TiB.
  • Network: The connection between my router and the harvester is sub 1ms, operating over a high-speed fiber internet connection (not port forwarded).

I recently re-plotted to C7 with BB on a separate machine. I’m thinking this is what exacerbated an issue perhaps already present. Previously I was getting some rewards at least.

Problem: Despite what seems to be a well-optimized setup, I’m seeing an 80% rate of stale partials, significantly impacting my farming rewards. This issue persists even after ensuring there are no apparent bottlenecks in CPU, RAM, or disk I/O, and after addressing potential network latency issues both internally and to the internet.

Chia log shows lots of warnings about lookups taking 20-40 seconds (instead of optimal sub 8 seconds)

Steps Taken:

  1. Separate plotting and harvesting operations on different machines to prevent resource contention (plotting has finished a few days ago in any case)
  2. Ensured the harvester and all related systems (Proxmox VE, container environment, HBA/SAS setup) are configured for optimal performance, with sufficient resources allocated and no virtualization overhead impacting performance. Currently 8CPUs which sits static at ~27% utilisation. 8GiB RAM at ~20% utilisation.
  3. Some older HDD drives in use, but checked all SMART passing
  4. Monitored system load, disk I/O, and network performance closely, without identifying a clear bottleneck.
  5. Was running chia-blockchain 2.1.4, now updated to 2.2.1.

Just seen this in the log “WARNING No decompressor available.”

I’m using CPU, not GPU. I notice now that this page suggests GPU is required for C7. Is this a hard requirement? If so, this is a nightmare. I plotted C7 in RAM after buying a huge amount of RAM for the server, and assumed farming would be trivial by comparison, in terms of resource requirements. I actually have a handful of C5 on there. Which might explain why I do get a rare valid partial.

Is there anything I can do to farm C7 without adding a GPU to my 1U server, which will obviously be difficult, and add unnecessary cost. Especially after going the route of RAM plotting.

My Harvester settings:

    crt: config/ssl/ca/chia_ca.crt
    key: config/ssl/ca/chia_ca.key
  decompressor_thread_count: 2
  decompressor_timeout: 20
  disable_cpu_affinity: false
  enforce_gpu_index: false
    host: localhost
    port: 8447
  gpu_index: 0
  logging: *id001
  max_compression_level_allowed: 7
  network_overrides: *id002
  num_threads: 30
  parallel_decompressor_count: 1
  parallel_read: true
  - /mnt/chia/01
  - /mnt/chia/02
  - /mnt/chia/03
    batch_size: 300
    batch_sleep_milliseconds: 1
    interval_seconds: 120
    retry_invalid_seconds: 1200
  port: 8448
    crt: config/ssl/ca/private_ca.crt
    key: config/ssl/ca/private_ca.key
  recursive_plot_scan: false
  rpc_port: 8560
  selected_network: mainnet
    private_crt: config/ssl/harvester/private_harvester.crt
    private_key: config/ssl/harvester/private_harvester.key
  start_rpc_server: true
  use_gpu_harvesting: false

Actually here is a log with the same error for C5

2024-03-31T21:49:38.323 harvester chia.harvester.harvester: WARNING No decompressor available. Cancelling qualities retrieving for /mnt/chia/04/plot-k32-c05-2024-03-18-18-26-df6be49f01234abcd.plot

OK it seems to be CPU resources. I have cranked up the CPU allocation to 20 and decompressor_thread_count: 20.

I’m seeing quicker lookups now. It just wasn’t obvious before because I had limited threads available and that made it look like CPU I had allocated wasn’t being maxed to 100% giving me a false sense of security. I’m guessing the bottleneck was making a backlog of decompression requests and hence the “unavailable” warning. I’m no longer getting that warning.

Lookups are taking ~10-20 seconds which is still a bit slow (though, much faster than before). Spacepool is starting to recognise my total plot size. Prev reporting 3TiB of 50TiB, but now climbing.

You’re going to have fresh issues once the filter halves on 13 June, it means the workload will double.

If you only have 50 TiB is it even worth running? I can’t see a Dell r620 being very power efficient, it’s probably costing more in electric than your earning.

Really c7 BB requires a GPU.

C7 def needs GPU!
maybe take a look at Gigahorse? much more efficient than Bladebit.

1 Like

I have solar so that helps a lot. I can strap in a GPU for farming with a riser cable, I suppose. It’s just making the cost of farming (along with the power, and plotting machine costs), untenable. Not to mention it’s $200 bucks per drive if I want to increase my netspace.

Really trying to make this work but it’s starting to feel like a sunk cost fallacy.

How does adding more net space help with economies of scale here?

Is GPU harvesting for C7 that much more more efficient? Maybe I just need to grab an old budget gaming PC off Marketplace and slap my SAS HBA card in there. My JBOD is external.

Getting waaaay over capitalised and disenfranchised TBH.

C7 was never meant for CPU farming (C5 is CPU sweet spot). Seeing you only have 50TiB I get it that adding a GPU does not make sense, in the end it is all about OPEX & CAPEX.

One GPU could triple your netspace, whether it’s cost effective is a different matter. Based on raw size.

As in - service a bigger farm? Or allow and service even higher compression levels for my current 50GiB?

Both, C7 BB gives 1.3 times your raw capacity, c30 Gigahorse gives 2.34 times raw capacity. C32 is three times, c33 3.5 times.

But with only 50TB raw capacity is it worth the expense.

Thanks for the links. I guess we have gone full circle and are now PoW. Definitely lots to consider.

Seems a long way from the original sentiment of the project. This arms race too is forcing people to continually re-plot, which in and of itself is mental.

Not entirely PoW though, it’s sort of halfway, and actually more efficient than adding more discs, but obviously the replotting is power intensive, although GPUs have made it substantially quicker.

I’ve now plotted five times, OG, NFT, BB C7, GH c19, GH c30. Can’t remember how long the first two took but it was a long time, especially the OG plots. but the other times it was about a week each.

We will have another replot coming up in a year or so as another compression resistant format is being planned.

1 Like

What do you mean “compression resistant” - Are you saying compression is undesirable and Chia are trying to discourage it by creating a compression resistant format that will be mandated? I would kind of support that TBH.

Found this. I’ll leave it here for anyone else: