Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic copying of completed plots to destination is slower than manual copying #5169

Closed
thestevekoch opened this issue May 16, 2021 · 15 comments
Labels
stale-issue flagged as stale and will be closed in 7 days if not updated

Comments

@thestevekoch
Copy link

On Ubuntu 20.04 the final process where the plots are copied to the destination is slower than if the user copies the same plots to the same destination manually using the GUI.

For instance, two plots completed phase 4 (plot 1 and plot 2) and they started transferring to dest1 at ~8:50 PM. At 9:10 PM I manually copied plot 1 into a temporary folder in dest1 which completed in 30 minutes at 9:40 PM. The copy process chia started is still ongoing at 9:50 PM with plot 1 and plot 2 at 33 GB and 27 GB completed, respectively.

@josinaldobarbosa
Copy link

are you copying more than one plot at the same time?

@thestevekoch
Copy link
Author

Yes

@todordev
Copy link

I have just completed a plot. It is in phase of coping the compressed file from second temporary folder to the permanent one.
This is really slow because the second temporary folder and the constant folder are on the same disk.

Is there an option to move the file instead of copying when the temporary compressed file and the permanent folder are on the same disc?

I guess, the OS will only edit the boot record and would not copy the whole file bytes by bytes.
This approach could save time and will keep the disk healthy longer.

@todordev
Copy link

I guess, this Pull Request could be a solution.
Chia-Network/chiapos#211

@thestevekoch
Copy link
Author

On Ubuntu 20.04 the final process where the plots are copied to the destination is slower than if the user copies the same plots to the same destination manually using the GUI.

For instance, two plots completed phase 4 (plot 1 and plot 2) and they started transferring to dest1 at ~8:50 PM. At 9:10 PM I manually copied plot 1 into a temporary folder in dest1 which completed in 30 minutes at 9:40 PM. The copy process chia started is still ongoing at 9:50 PM with plot 1 and plot 2 at 33 GB and 27 GB completed, respectively.

Performed additional testing. A single plot copy performed by the chia process from the temp disk to the destination disk takes 60 minutes. The same copy (same file, same source, same destination) performed using the file manager takes 15 minutes.

Environment info:

Chia 1.1.5
Ubuntu 20.04 Desktop
AMD Threadripper 1950x
64 GB memory
Temp disk: 4TB nvme (2x2TB Inland Premium in RAID0)
Dest disk: Western Digital My Book 14 TB connected via USB 3.1

@todordev
Copy link

todordev commented May 17, 2021

Your case could be a problem with the PCI bus limits.
Your system may be disable a drive if there are too many drives connected to your PC. If several drives share a bus.
I had similar problem. When I connect a HDD via USB, the system disabled my inner network card.
There was an internet but it was too slow.
Check the documentation of your motherboard to find which drives shares PCI buses.

In my case, the problem is the process of files copy. Chia should move the file instead to copy it when the file has to be moved to a folder in the same partition.

@redbaron
Copy link

Why copy file at all? IMHO it's best to create file plot in the final destination, avoiding unnecessary IO all together even if tmp and output directories are on different disks.

@todordev
Copy link

You are right. Everyone must create plots in the permanent folder if he does not use second temporary folder (temporary folder on another drive). I have made a mistake starting a plot with second temp folder on the drive where the permanent folder is located. I entered wrong drive name.

So, the Plotter must take this into account and warn if someone does the same thing. It must prevent creation of plots if the second temporary folder and the permanent folder are located on same drive and partition.

If this approach is not accepted by you, the Plotter must move the file instead copy when the second temporary folder is located on same drive and portion with the permanent one.

That will avoid unnecessary IO if someone make similar mistake. :)

@redbaron
Copy link

No I mean regarding of the location of tmp and destination directories, always create final file in the destination directory.

So instead of this at the end of plotting:

  • write file $TMP/plot
  • copy file $TMP/plot to $DESTDIR/plot.tmp
  • rename $DESTDIR/plot.tmp to $DESTDIR/plot

Do this:

  • write file $DEST/plot.tmp
  • rename $DESTDIR/plot.tmp to $DESTDIR/plot

@thestevekoch
Copy link
Author

thestevekoch commented May 18, 2021

Your case could be a problem with the PCI bus limits.
Your system may be disable a drive if there are too many drives connected to your PC. If several drives share a bus.
I had similar problem. When I connect a HDD via USB, the system disabled my inner network card.
There was an internet but it was too slow.
Check the documentation of your motherboard to find which drives shares PCI buses.

In my case, the problem is the process of files copy. Chia should move the file instead to copy it when the file has to be moved to a folder in the same partition.

I may not be explaining this clearly, so hopefully this clarifies what is occurring.

The only difference between the slow file copy and the fast file copy is whether Chia is performing it via a python call (fs::copy) or whether the Ubuntu file manager is performing the copy.

ALL other variables are the same and both fast and slow copies are occurring at the same time, using the same files.

I have resolved the issue for myself by disabling the chia copy and instead using a bash script to monitor the temp directory and mv the file to the destination.

@ghost
Copy link

ghost commented May 26, 2021

I have resolved the issue for myself by disabling the chia copy and instead using a bash script to monitor the temp directory and mv the file to the destination.

Hi @thestevekoch can you explain how you disabled the chia copy? I also want to disable it and move the file manually. Thanks!

@thestevekoch
Copy link
Author

I have resolved the issue for myself by disabling the chia copy and instead using a bash script to monitor the temp directory and mv the file to the destination.

Hi @thestevekoch can you explain how you disabled the chia copy? I also want to disable it and move the file manually. Thanks!

Sure, I'm using plotman, so I've uncommented out the tmp2 directory path and set it to a folder on my plotting NVMe. I've then set the destination path to the same folder. It's important that tmp2 and destination are on the same drive as this will perform a move instead of a copy. If you're not using plotman, you can do this by adding the -2 switch .

I've then created a short script that monitors the destination directory for plots and moves them into the final directory one at a time. Here's some example syntax of the plot command and a bash script.

Plot command example:
chia plots create -k 32 -r 4 -u 128 -b 4000 -t /mnt/4tb -d /mnt/4tb/plottemp -2 /mnt/4tb/plottemp

Monitoring script example:

#!/bin/bash
while :
do
        echo "Checking for plots"
        for f in /mnt/4tb/plottemp/*.plot;
        do
                echo "Plot found. Moving plot to External Drive"
                mv -n "$f" "/mnt/extDrive"
        done

        echo "Sleeping 10 minutes"
        sleep 10m
done

@ghost
Copy link

ghost commented May 27, 2021

I've then set the destination path to the same folder.

That was the missing key here! Thanks, I'll use the bash script too, It seems fine but i'll remove the while loop and use cron with a */10 entry.

@github-actions
Copy link
Contributor

github-actions bot commented Jul 9, 2021

This issue has been flagged as stale as there has been no activity on it in 14 days. If this issue is still affecting you and in need of review, please update it to keep it open.

@github-actions github-actions bot added the stale-issue flagged as stale and will be closed in 7 days if not updated label Jul 9, 2021
@github-actions
Copy link
Contributor

This issue was automatically closed because it has been flagged as stale and subsequently passed 7 days with no further activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale-issue flagged as stale and will be closed in 7 days if not updated
Projects
None yet
Development

No branches or pull requests

4 participants