Suggestion: Calculate current and average upload speed [v2] about resumable.js HOT 9 CLOSED

Hi, [up]

I think it could be cool to store last uploaded byte in a variable, so that chunkSize can be modified while upload (so, if someone uploads from a mobile device, and gets 4G ... It can adjust speed and not do useful requests)

from resumable.js.

Hi,

i have prepared a sample implementation at AidasK/resumable.js@23:master...master

ResumableFile now is going to have two additional params:

• $.currentSpeed - current file upload speed based on "measureSpeedInterval" parameter
• $.averageSpeed - this is implemented based on formula: averageSpeed = SMOOTHING_FACTOR * lastSpeed + (1-SMOOTHING_FACTOR) * averageSpeed; http://stackoverflow.com/questions/2779600/how-to-estimate-download-time-remaining-accurately

I have also added two params: measureSpeedInterval and speedSmoothingFactor. I think they need a better naming.

from resumable.js.

If you are going to have a lot of mobile users I would probably just set the chunksize to 512k and have the number of simultaneous uploads shrink when upload speeds are low.

On 23 sep. 2014, at 16:53, Steffen Tiedemann Christensen [email protected] wrote:

Yup -- absolutely doable, although it would require a bit of extra complexity on the server side to stitch together chunks. The real way of doing it would be do simply send the start and end bytes I gather and then have the server stream bytes to a fully assigned file.

The question remain though if it's worth the bother -- is the real life use cases justify the change?

—
Reply to this email directly or view it on GitHub.

from resumable.js.

I like the idea, and have actually had this feature in the custom Flash uploaders I've been using before. The reason I didn't include it in Resumable originally was that the actual calculation tended to be inaccurate at best -- mostly because HTTP uploads tend not to perform linearly for bigger files. And in this case there's the additional complexity of connect times, seek times, test times, resume times to consider.

My approach would probably be to:

• Create a timer firing every few seconds which indexes the currently uploaded file size. This index should probably be trimmed over time.
• Create functions $.remainingFileSize() and $.currentUploadSpeed(). This latter would look at the above index to see the average upload speed in bytes/sec over the past minute or two. It would also consider if the upload was started or resumed more recently that this (starting/pausing/resuming could just clear the index, I guess).
• Create one or two helper functions using the above to calculate and format the time remaining.

from resumable.js.

Hey, have you seen my implementation? I would like to finish this feature and move on to new ideas.

from resumable.js.

I like the idea of the changing chunk size -- but wondering if it's really applicable in any real use case? On mobile, would you even know what the available bandwidth is ahead of sending the chunk?

The last uploaded byte can be a bit of a moving target with Resumable: Since multiple chunks are uploaded at once, a file is not uploaded linearly -- in fact the first chunk set to upload might be the last to finish.

from resumable.js.

I thought of some way to have the chunk size increased if it took <1 second to upload, else decrease it. But you're right, there's no way to know for the first chunk (worse) when upload speed is lowered, resumable's main feature "fails", as it can't be really paused.

As for uploading multiple chunks at one, I were not aware and don't know if it's a good point (and I supposed it to be ran linearly, appending chunk to a file ..)

from resumable.js.

You could force the first chunks to be small and have Resumable upload them non-simultaneously. when speed is high increase the chunks to what is configuredm switch to the simoultaneous number of uploads that is configured. When the chunks need to shrink, just first have the uploader fall back to 1 upload, wait for all other chunks to complete and then decreas the chunksize. the only tricky part is to identify the order of the chunks in the backend because you might end up slicing chunks that persist somewhere in the middle of a file.

from resumable.js.

Yup -- absolutely doable, although it would require a bit of extra complexity on the server side to stitch together chunks. The real way of doing it would be do simply send the start and end bytes I gather and then have the server stream bytes to a fully assigned file.

The question remain though if it's worth the bother -- is the real life use cases justify the change?

from resumable.js.