-
Notifications
You must be signed in to change notification settings - Fork 159
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
progress eta is very wrong #3178
Comments
cc @elmattic |
It's likely because the DB write speed is negatively correlated with the number of entries in the DB, from what I've noticed. I'm okay with disabling it altogether. Maybe we could contrive a smarter estimator, but I don't think it's worth it. That being said, I don't understand why this happens; I would assume the DB would use, e.g., a merge tree or something similar underneath to not slow down. That is another topic, though. |
@aatifsyed the way we compute the ETA is really simple, to compute the throughput a mean of the number of items processed over time is done. |
A moving average would bring it closer to reality but still inaccurate. If we would want to be precise, we would need to calculate the slope of the download speed function, which may not be linear and may change on any ParityDb update. It's overkill. |
Or train a NN to predict the completion time. We could finally become an AI project. DeepForest - 8B parameters to predict snapshot import times. |
Our ETA was 8m, but the actual elapsed was 35m.
We shouldn't provide an ETA in this case, it's the opposite of helpful.
Is this because our length isn't known? Or do we take much more time to process later entries than earlier entries?
The text was updated successfully, but these errors were encountered: