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

Scoreboard updates should happen at regular time intervals #1484

Open
cus opened this issue Jul 16, 2022 · 0 comments
Open

Scoreboard updates should happen at regular time intervals #1484

cus opened this issue Jul 16, 2022 · 0 comments

Comments

@cus
Copy link

cus commented Jul 16, 2022

Right now, proftd is updating the scoreboard based on the number of transferred blocks or the percentage of the file transfer progress.

Percent based scoreboard updates can be too infrequent for big files and slow link speeds, because it can take a lot of time to transfer a percent of a file. Blocksize based scoreboard updates can be too frequent for fast links, because 10 blocks of data (which is the default value of PR_TUNABLE_XFER_SCOREBOARD_UPDATES) can be transferred in a fraction of a second on a gigatbit link...

Overall, any scoreboard update method dependant on link speed or file size is sub-optimal, because the user expects the scoreboard to update regularly, not too often (in order to reduce the extra load caused by the scoreboard updates), and not too rarely (to get accurate up-to-date information).

Therefore I suggest to make scoreboard updates based on the elapsed time since the last scoreboard update, e.g. update the scoreboard every second. Elapsed time is already queried in pr_throttle_pause() where the updates take place, so it should be fairly easy to change the implementation.

cus added a commit to cus/proftpd that referenced this issue Jul 16, 2022
This commit removes the previously used blocksize or filesize percentage based
scoreboard updates and starts using elapsed time based scoreboard updates.

Percent based scoreboard updates could have been too infrequent for big files
and slow link speeds, blocksize based scoreboard updates could have been too
frequent for fast links.

Also this changes the meaning of PR_TUNABLE_XFER_SCOREBOARD_UPDATES, previously
it meant the number of transferred blocks to wait until a scoreboard update
happened, now it means the number of deciseconds to wait between subsequent
scoreboard updates.

Deciseconds as the unit were chosen so the default of
PR_TUNABLE_XFER_SCOREBOARD_UPDATES of 10 is unchanged and will mean a
scoreboard update every second.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant