Show file upload speed

[Pro100x3mal]

Add the ability to display the upload speed in the files extension. Perhaps as a separate parameter in the settings. I want to switch from nextcloud to ocis. It is important for me to see in the web interface the speed with which I upload files to my cloud. How can I see her?

[micbar]

@kulmann @JammingBen @fschade Could our upload client provide that metric?

[fschade]

@Pro100x3mal thanks for your input. Can you explain what you want to see?

I could think of:

• upload time for the file (after the upload)
• upload time for all files (after the upload)
• upload speed for the file (after the upload)
• upload speed for all files (after the upload)

or do you want to see realtime the current upload speed while uploading?

[Pro100x3mal]

@fschade i want to see realtime the current upload speed while uploading

[Pro100x3mal]

Tell me, are you planning to add this option in the next release?

[pascalwengerter]

Tell me, are you planning to add this option in the next release?

@Pro100x3mal, from reading your initial request it is not clear for me what you want to see, is it "estimated time until upload is completed", literally "bytes that are being transferred this very second", or something else? Could you provide a link or screenshots to an implementation you already know, or a simple mockup on how the information should be displayed? 😉
Also adding @tbsbdr here to provide some UI/UX feedback from ownCloud product management.

To answer your question: Please note that there is already a web release being prepared which first needs to be brought to the oCIS repository and will be released with the next oCIS release (assuming you'd want to use an official release rather than building the application from scratch on the current master). There's also a product backlog and features scheduled to be worked on, so I'd ask you to be a bit patient - your request, while valid, is not necessarily a top priority (feel free to provide input if we're missing something on why it should be), and such a feature, including more ironing out of requirements, as pointed out above, as well as actual implementation and automated tests and maybe some user testing, take time. You're of course welcome to contribute e.g. a working prototype 🙂

The library we're using, uppy.oi, seems to have some util function that could potentially be used to achieve the goal.

[Pro100x3mal]

@pascalwengerter @tbsbdr
That's what I meant. Example from Nextcloud. When uploading files, the upload speed is displayed in real time

[mamay]

There is an issue with current time calculation (and Nextcloud one too) as when upload speed is not stable - the time is moving awkward instead of recalculating on mean speed. So the tooltip data should be carefully thought of.

[pascalwengerter]

@Pro100x3mal @mamay I've drafted something here: #8187 (comment)

@mamay do you have any idea of what "carefully thinking of current time calculation" could look like? 🙂 Also, please note that the issue (and corresponding PR) target the display of current upload speed, if you find awkward moving of the progress bar to be an issue in this repo please open a separate ticket!

[mamay]

There are a few questions here:
0. Do we need to show current speed and/or average one

1. How do we calculate the average speed to get the estimated time?
   1a. We're uploading with speeds varying from 400 to 900 Mbps (I've uploads with such delta during 1 minute averaging window, investigating), then upload drops suddenly to 200 Mbps due to network issues (say hello to WiFi, as an example). How should we react to this? Most file managers will calculate average speed based on some window and adjust time slowly, some will also just hold estimate calculation, then adjust "suddenly" (see Windows 11). How long should this window be?
   I currently hate estimates from Nextcloud, which on ~1G speeds are very awkward in web.
   1b. Speed is about 1G, drops to 100Mbps for, hm, 5 seconds, then back to 1G. Same averaging question.
   1c. Should we try to calculate trend? Like linear one between speed on start of the averaging window and on end.
   1d. Should the length of the averaging window depend on the file length (and "current" upload speed?)

Personally I see all the estimates lying in any conditions except stable ones (except Nextcloud, its the worst I've experienced), some are better (the standard file manager ones.

[kulmann]

@mamay

I just gave #8187 a try. Feels quite good to me. Regarding your questions some context: For "everything upload related" we rely on uppy.io including the upload speed calculation which the linked PR introduces. They calculate an average upload speed. That being said:

0. Do we need to show current speed and/or average one

We can only show the average speed. The lib doesn't provide the current bandwidth utilization.

1. How do we calculate the average speed to get the estimated time?

At the moment the estimated remaining upload time is simply calculated like this: ((timeElapsed / progressPercent) * 100) - timeElapsed . That obviously has its flaws, because it doesn't take the upload speed into account. As of now this was fine, especially because we didn't have the upload speed available (there was an upstream bug).

Could you share your ideas for upload ETA calculation in a new issue? I think the ETA calculation is out of scope for this particular issue here. An easy first improvement could be that we use the remaining bytes and the average speed to calculate the remaining time. What do you think, would that be sufficient for your use case (in theory, obviously needs to be tried out when we have it)?

[mamay]

Maybe we should post this to uppy.io, to get everything done in upstream?

[pascalwengerter]

Maybe we should post this to uppy.io, to get everything done in upstream?

Can't hurt I suppose 🙂 from what I've witnessed they're always open for suggestions (and have given the topic some thought already I would assume), but let's see!