You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: