can optimize nossd client,when one plot have many qualities, can parellel read plot file.
Can you share me full details how to do that, merci 
nossd client scan all the plot every minute, its too frequency, can add an option to choose disable it. it let proof timeout.
Have you seen proof timeout error?
All data needed for enumeration usually resides in OS cache, so it should not read it from HDD every time.
Too many stale proofs! 53 proofs out of 1649…, this msg
the client scan all plot every minute, its true
Have you run the benchmark? How many plots it shows and how many plots do you have?
Stale proofs usually occur when CPU load is too high. Maybe you run another plotting client on the same system and it loads the CPU?
It’s very unlikely that plot enumeration is the reason of stale proofs.
4000 plot now, i use nfs disk. so plot scan will have some affect
Is this for real ? chia road map point to plot comprasion . Whats the draw back ?
Like Hpool OG. Centralized. Not your keys, not your coin. The only problem I’m having is the frequent crashing of the client still.
2 Likes
Does it crash without plotting? What command line you use, what machine, OS etc?
for me only plot speed is useful
I haven’t tried without plotting yet. Still finalizing a dozen drives.
Running the client with -c 5 flag and nothing else other than the address and the drives.
I’m running it inside a Proxmox VM on Ubuntu 22.04.1 LTS
Supermicro 1U server Dual E5-2699V4’s 256G RAM
60 cores allocated 175GiB RAM allocated to the VM for plotting
Was thinking about trying a different distro if this keeps happening.
1 Like
can you disable the minute plot scan
@douyacai
Can you please tell me your Chia address you are mining on
I want to check your share delays
1 Like
not just enumerate plot, read every plot. when have plenty plot, will consume a lot time and io.
I’ve checked your share statistics.
Before October 17 you had very good share time (0-1 second). But after that it’s 5-10 seconds and more.
There is no distinct 60 seconds interval between your stale shares. That means that plot enumeration and stale shares are probably not connected.
Besides, as I’ve already said, file enumeration normally done in cache and does not cause actual disk reading. I/O operations in process explorer do not mean that HDD really reads something.
The most probable reason of such bad performance is that you are plotting on the same disks.
Parallel plotting and mining works well only if done by single client program. It suspends plotter when miner needs to read proofs. Otherwise, high disk load caused by plotter will prevent miner to read proofs quickly from that disk.
Are you plotting and mining on the same disk using separate client instances or not?
1 Like
only miner,no plotting. miner base on nfs, now 4000 plots, final one miner will have 8000 plots, so must fully optimized.
What changed on October 17?
Did you use local HDDs before and NFS after?
What latency (i.e. ping) do you have to your NFS storage?
yes, have to use nfs,
Too many stale proofs! 94 proofs out of 3488, no minute scan can reduce stale proofs
Why are you ignoring questions? What ping do you have to your NFS storage?