Not plotting anymore. How to stop Chia to check for new plots?

Chia Farming & Harvesting
1

I found this section in Chia config file.

plots_refresh_parameter:
batch_size: 300
batch_sleep_milliseconds: 1
interval_seconds: 3600
retry_invalid_seconds: 1200

I changed interval_seconds: to 3600 seconds from it default 120.

What is the biggest value of this parameter? Can I set it to 86400 seconds (24h)?
I’m not sure about that high value as my guess is if this value will be to big could be ignored by app and then default option of 120 second could be used.

The point is to limit discs operations. I’m not creating new plots so it make no sense for the app to check for new plots every 2 minutes.

2

Only a guess:
But I believe that when Chia checks for new plots, it uses very little resources, and maybe it would be best to leave the default setting.

I know that you would prefer to change the value for it to check every 24 hours. I do not have an answer for that.

If no one answers, then I suggest that you change the value to 86400, add one more plot, and check back in 23½ hours to verify that your plot count did not increase, and then 31 minutes later, check again to see if it did increase.

If you have no space for one more plot, then you could change the value to 86400, and then rename one of your plots to have, for example, .test extension. Then wait to see if the plot count goes down, as per your new configured schedule. When all is well, rename your plot back to its original name.

1 Like
3

Not really. “little resources” really depends on how many drives/plots you have. For a big farms (multiple PBs), they recommend to make that value rather big.

So, setting that value to 1 hour may be worth doing. If a farm is not too big, whether that would be 1 hour or 1 day, it really doesn’t matter that much (from drive perspective).

Once you do that, you need to remember, that when you will disconnect and reconnect a drive, you will need to use UI to speed up finding it, as otherwise it will default to the value you set up.

I think you can safely do that (remember reading about it some time ago). Although, depending on the size of your farm, it may really not matter (from your drives perspective). Just add one fake directory through config.yaml (e.g., x:\bad), and check your logs whether you will see a line stating that such folder is missing (you will know that your 1 day value sticks).

2 Likes
4

Thank you for answers.

I will try to set it to 86400 and try to rename 1 plot and then check the logs.

It is brilliant and simple solution but I missed that :wink:

5

Don’t rename your plot. If you do that, you will get “bad plot” or something like that sticking around your UI for some time.

Just open your config.yaml, look for “plot_directories:”, and add one more line, so you will have something like:

  plot_directories:
  - d:\plots
  - e:\plots
  - x:\bad

That config file is in - “%userprofile%.chia\mainnet\config” folder (in Windows). Just use notepad to edit it. Once you do that, go to your UI / Plots / three vertical dots in the upper right corner / Refresh plots. You should see that line in your debug.log:

021-10-30T10:58:29.620 harvester chia.plotting.util : WARNING Directory: x:\bad does not exist.

Then you can check your debug.log again, after your 1 day or 1 hour (depending on how you change it), and see that line again. This is a harmless warning, so you don’t need to worry about it being there.

You can find your config.yaml or debug.log in command prompt window by issuing “dir /s \config.yaml”

2 Likes
6

You are right. This solution is more “elegant”.

I set interval_seconds to 86400. Then I add non existing directory to my config file. Then I did restart of Chia app.

I got Warning info in my log file exact like you got.

I will check the log tomorrow after 24 hours.

1 Like
7

No need to restart the app. When that time out elapses, Chia goes back to config.yaml, and checks for potentially new settings, and will go from there. So, that is the beauty of adding/removing folders via config directly. Although, when you extend it to one day, that section will be checked only on that interval (that makes that 1 day value not good IMO, as I would rather use 1 hour). Again, no difference from drive perspective. (However, that is not the case with all settings in that config file.)

1 Like
8

WOW!

You are amazing. Thank you.

I wasn’t sure about changes in config files. How it works when I change someting there. Do I have to restart Chia or just wait.

Is this rule apply to all changes in Chia config files? Can I change something and leave it and when the time will come Chia process will check config file and apply new changes?

9

No, potentially only those entries that have some sort of timeouts behave like that (if at all). Maybe one reason that it works like that is that in early days UI was just not working, so instead of fixing UI, some time was spent to real-time check for config changes (basically trying to make sure that service works, while not giving a shit about UI).

10

Thank you for informations.

11

I thought that Chia looks for plots with its custom naming convention, and that that if you name it to something else, like *.plot.test, then Chia will see it as something to ignore (and likely not see it at all)?

And if renaming the file will produce an error in the log, then moving the plot up or down one directory, into a directory not scanned by Chia, then that will definitely produce no errors from Chia.

Such a move will be instant, as will be moving the file back after testing for 24 hours.

The benefit of doing this is that the ultimate test is to actually see your number of plots change by 1, based on your new timing schedule.

True, that adding a phony plot directory will result in an error in the logs, based on the time interval set. And that is 99% conclusive. But to be 100% conclusive, I feel that actually seeing your plot count decrease by 1, and increase by 1, on your new schedule, it ultimately concrete proof that your settings are working.

Cheers!

1 Like
12

Good catch! You are absolutely right. My mistake.

So, when you rename your plot, you may want to watch the count of plots that are being reported. Looks like this is a better way to test for those changes. (I just don’t use UI that much, as it had too many issues before.)

Update:
I take it partially back :slight_smile: When you rename your file, you will see that counter dropping, but that doesn’t indicate whether that timeout change took place. All plots (names/locations) are put into the memory during that folder scan. That memory map is being used for all lookups. Therefore, if you remove a file, the memory map will not jive with the physical file, so the counter will be dropped. If you restore such file, the counter will get back to what it was before. However, I am not sure whether if you add a new file, it will be recognized right away, or rather that will happen during the next folder scan.

So, actually those two are different experiments, as such giving us slightly different feedback.

By the way, I would love to have a feature, where we could specify to also check all sub-folders. For those that map plot folders to some “root” plots folder that would be a blessing, as that would basically end all the mess with adding / removing such folders.

1 Like
13

I thought that, for large plot counts, the large “interval_seconds” value was to have a more stable start-up for when starting up Chia?

Please point me to who said that the default “interval_seconds” uses even modest resources, for non-huge farms.

I would like to know what resources are actually used for farming, perhaps, a few thousand plots, when the “interval_seconds” are left at its default 120 value.

And frankly, I doubt that the default value would impact even multi-PB farms, other than at start-up.

I am not saying that you are wrong. I am saying that I would like to know how you know, before I come to that same conclusion.

Thank you.

14

As far as I remember, the latency problem happens with really big farms. Few thousand plots farms are fine with 2 minutes. Still, my take is that whether that is 2 or 10 minutes, it really doesn’t matter that much, so why not to go for that 20 minutes (or pick your number of minutes). Once your farm stabilizes, that scan for new folders is not that important.

Also, for those big farms, I think that you also need to modify that batch_size and batch_sleep values. The reason for that was that the initial implementation was serializing that scan, so one value (timeout) was good enough. As those scans started to take long time for bigger farms, they parallelized that taks. Once that process was parallelized, basically all folders were added at once, and plot findings started to encroach one on another. To avoid that, they introduced “force_synchronized” value, as otherwise it was really barfing. Soon after adding that force_synchronized value, they expanded that entry to include all those new values.

One problem with those new entries (at least before) was that when you were upgrading your setup, the installer was not adding that entry to your config.yaml, and also was ignoring value that was there. So, you may check your config.yaml whether you have it there, and if not add that section.

1 Like
15

The process that scans those folders/drives take place every time that timeout happens. So, it is not just startup.

From what I remember, there were people with about 50TB farms which were taking an hour or more to start.

16

I really have no problem with being wrong, also on this issue :slight_smile: That is how we learn, isn’t it?

I need to go, but you can scan Issues page on github, as it was reported there about two months ago.

1 Like
17

I move plots around, often. The GUI (and the “chia farm summary”) output reflects my changes in roughly 2 minutes (I never actually timed it, and I do not know if my moves are happening at the start of a new 2-minute interval, or when the 2-minute interval is about to check your farms, again).

In any event, when I copy plots from “A” to “B”, I always use a non-scanned location for “B”.
This avoids errors in the logs, because an in-progress file copy will result in 1) a supposed duplicate plot, and 2) a reported corrupted plot (because the file copy is not finished).

After my file copying is completed, I move the files into their proper (scanned) directories.

The above does result in seeing my plot count drop, until I eventually move the plots to their final (scanned) directories. Then my plot count returns to what it was.

The reasons that I do this manual copying is a long story, and there might not be enough storage space on the internet for me to explain it all. Well, it is not that long, but I have good reasons for why I copy plots around.

It is mainly due to not trusting 3rd party software, and adding new drives. I am striving to keep nothing other than essential software running on my new hardware. The last thing I need is to have to figure out if some problem is Chia related, or some 3rd party this or that related.

I had enough trouble sourcing parts and building my Chia hardware, as well as educating myself on how to get Chia working (I knew zero about it). So I kept away from anything and everything other than installing the OS and Chia. This results in my having to manually move plots around, when I add new storage space. Hence, I see my number of plots decrease and increase, based on my plot transfers.

Cheers!

18

I imagine that there are many people that have USB drives that sleep. And they might not realize that their drives are sleeping (they would have to check the response times in the logs to know that they have an issue, or they would have to manually access the sleeping drive and realize that the drive is sleeping + they would have to connect the dots that that is an issue for Chia).

So when they would start up Chia, and their drives happened to be sleeping, then that will take an eternity for Chia to get snapshots of all of their drives – waiting for them to wake up.

The above might account for slow start-up issues.

When I reboot my PC, I always wake up my drives before starting Chia. And I run a script that keeps my drives from going back to sleep. This is mainly a problem for USB G-Drives (a WD brand) and WD MyBook drives. I do not recall if my other WD drives have this issue, since I keep the drives awake now.

My Seagate drives do not have a sleeping issue. They give me no headaches. But they cost more per TB.