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

In sync percentage should be weighted to folder size, not just average of folder completion #1300

Closed
Dot-Dash opened this issue Jan 26, 2015 · 15 comments
Labels
enhancement New features or improvements of some kind, as opposed to a problem (bug) frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion

Comments

@Dot-Dash
Copy link

While syncing a folder of 26 GiB, 12.8GiB of which has been completed, Syncthing shows that as "Syncing (73%)" at one end, while showing "Syncing (45%)" at the other end. In my case, the Documents folder is being synced. The "Default" folder exists, but has nothing of significant size to contribute. The 45% number looks more accurate to me.

MacOS 10.10.1.

syncing 73 percent
syncing 45 percent

@AudriusButkevicius
Copy link
Member

I think it takes the average for all folders involved, which makes sense as the global state.

@Dot-Dash
Copy link
Author

Averaging percentages of folders is meaningless. If you are 100% done with a tiny folder and 1% done with a huge folder, you are nowhere near 50% done overall.

@AudriusButkevicius
Copy link
Member

To be honest that's how I think it's already supposed to work, and not having checked the code I cannot say for sure

Regarding you scenario, I am 50% done on a folder per folder basis. But yes it could be better. It's just that working out exact percentages means we have to scan the whole database which is damn expensive as it is already.

@AudriusButkevicius AudriusButkevicius added the enhancement New features or improvements of some kind, as opposed to a problem (bug) label Jan 28, 2015
@AudriusButkevicius AudriusButkevicius added this to the v1.0-maybe milestone Jan 28, 2015
@addisonamiri
Copy link

This has been bugging me recently. Has anyone been able to figure out where the discrepancy is? I tried looking through the code but I couldn't figure it out.

@AudriusButkevicius
Copy link
Member

It was explained in the second post.

@calmh calmh removed this from the v1.0-maybe milestone Nov 17, 2015
@calmh
Copy link
Member

calmh commented Nov 22, 2015

What's the actual request here - what would be the desired end state to resolve this ticket?

@Dot-Dash
Copy link
Author

The desired end state is for the percentages at both ends to accurately reflect the amount of work left to complete the sync, compared to the amount of work already done. If you've been syncing for 90 minutes, and the percentage reads 90%, you should be able to expect that the sync will be complete in about 10 minutes more.

@calmh
Copy link
Member

calmh commented Nov 23, 2015

The percentage really has nothing to do with how long we've been syncing though - it's a measure of how much of the data is in sync. I can shut down Synchting, start it up again, and it's instantly at 90%. This says nothing about the time or effort to complete those remaining ten percentage points.

Currently the percentage is the average of all folders, so if three folders are shared, two of them are in sync and the second is halfway done, the total percentage is (100% + 100% + 50%) / 3 = 83% complete. I could see us using the actual space instead, where if the folders are one, two and four gigs large we might have for example (1GB + 2GB + 2GB) / (1GB + 2GB + 4GB) = 71% complete instead.

But in the original post it looks like the sharing configuration is asymmetric, and then the percentages will not match and should not match - the devices are dealing with different amounts of data, and have different amounts of it in sync.

@addisonamiri
Copy link

I think that second example, where the size of the folders is taken into
account, is more intuitive. It's more a reflection of how much data is in
sync instead of the number of folders that are in sync (if that makes
sense).

On Mon, Nov 23, 2015 at 7:15 AM Jakob Borg notifications@github.com wrote:

The percentage really has nothing to do with how long we've been syncing
though - it's a measure of how much of the data is in sync. I can shut down
Synchting, start it up again, and it's instantly at 90%. This says nothing
about the time or effort to complete those remaining ten percentage points.

Currently the percentage is the average of all folders, so if three
folders are shared, two of them are in sync and the second is halfway done,
the total percentage is (100 + 100 + 50) / 3 = 83% complete. I could see us
using the actual space instead, where if the folders are one, two and four
gigs large we might have for example (1GB + 2GB + 2GB) / (1GB + 2GB + 4GB)
= 71% complete instead.


Reply to this email directly or view it on GitHub
#1300 (comment)
.

@capi
Copy link

capi commented Nov 24, 2015

I tend to agree with @addisonamiri, that using the folder sizes would be a more meaningful metric for progress.

@AudriusButkevicius
Copy link
Member

Percentages are relative to size, why is that no good?

@capi
Copy link

capi commented Nov 24, 2015

No it isn't as, the all folders are weighted identically, regardless of their size. I could have 9 repositories with 1MB, and 1 with 1TB, and once the 9MB have been synced, the synchronization progress would be 90%, which I tend to agree is counter-intuitive.

@calmh calmh changed the title Local and Remote Percentages Differ Wildly In sync percentage should be weighted to folder size, not just average of folder completion Nov 24, 2015
@calmh
Copy link
Member

calmh commented Nov 24, 2015

I've changed the issue description to reflect that.

@Ferroin
Copy link

Ferroin commented Jun 17, 2016

I'm kind of curious why this has been left untouched. The current implementations reported metric is at best essentially useless without some extra information (which the UI admittedly does provide) and a not insignificant amount of math, and at worst severely misleading. The only advantage that it appears to have over a proper weighted average is that it's computationally simpler, which is itself not a good argument for knowingly misleading the user.

@AudriusButkevicius
Copy link
Member

It's untouched because nobody cares enough about this. Please feel free to solve this is you feel about it strongly. It's an open code base afterall.

Also, close your other ticket if this one covers tye issue.

@st-review st-review added the frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion label Aug 10, 2017
@syncthing syncthing locked and limited conversation to collaborators Aug 10, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New features or improvements of some kind, as opposed to a problem (bug) frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion
Projects
None yet
Development

No branches or pull requests

7 participants