More realistic ETA determination (with specific examples)

[DamianDominoDavis]

Breif/TL;DR:

The incorporation of a new ETA utility, using arbitrary|user-defined timesteps|datasamples, to display a series of calculated time estimates.

Additionally, or instead, the incorporation of an average bar on the Speed tab graphs, and one additional time estimate derived therefrom displayed nearby.

I play with numbers a lot, and I've got an idea. We all know connection speeds aren't stable things, and that time estimates are to be taken with mountainous piles of salt (especially instantaneous estimates) and that instantaneous and average speeds will hover and change over time. The basic idea for the ETA is (Size - Completed) / Rate , wherein the ETA is updated with the file transfer rate -- that is, updated second-by-second. But suppose there were an allowance for the substitution of alternate definitions of rate; suppose rate was instead calculated as an arbitrarily size sample over the time to it's completion, or the downloaded size sample over an arbitrary number of timesteps. Calculation and simultaneous display of these alternitave estimates, as well as of the traditionally computed ETA, may give users more realistic and reliable information about their torrents.

As an aid to describe the mechanic, let me propose a complete scenario (by which I mean, the implementation described here is only one example of the concept I'm really suggesting). Suppose, within the Show menu of the Speed tab, there was an additional option; we'll name it 'Estimates'. Under this, the display subwindow will be similar to the Disk Statistics option, in that the Download option graph will display at right, and at left shall be two panes, divided by a reiteration of the traditional ETA. [One of these panes would do just as well; I mention them both to illustrate multiple avenues to accuracy.] In the first of these two panes, I suggest four arbitrary timesteps and one user-defined length of time, accompanied by new ETAs as determined by the download sample size over those times (and, perhaps, what those samples measured). These arbitrary timesteps could be 1, 5, 30, and 300 seconds (in deference to the graph display timesteps); or 10 seconds, 1 and 5 minutes, and 1 hour (in deference to the graph display gridwidth). I really have no inkling of the best implementation of the user-defined time estimate; I'll be undeservedly condescending and "leave it as an exercise for readers." The second pane is similar in most respects, except using arbitrary download sample size lengths, and recording the time necessary to completion for use in total time estimates. The first pane implies updates-by-second, balanced by keeping track of the data over time. The second pane could function by counting the number of timesteps -- starting from present data and moving backwards -- to achieve a set sample size. Stabilizing tweaks are probably necessary for this second method.

Perhaps as a more lightweight solution (or, hell, even a warmup for a writer tackling the above example's brainchild) would be just one additional ETA displayed on the Upload/Download options of the Speed tab. The rate used to determine this final estimate is the average over time of whatever graph is currently displayed; quick observers will note that this will be identical to one of the four estimates in the previous example's first pane. Not only will the estimate be informative, and inherently precision-adjustable with the timestep selection, but the averaged rate could easily be projected as a horizontal bar on the visual.

I don't know; I run out of things to do while waiting for torrents, and I crunch numbers for fun. I supposed that since what I most often came back to is actually useful, it might interest others if the effort involved were taken out.

[Ultima]

The thing is, though, the ETA isn't actually an instantaneous ETA, but instead, implemented as a sliding average that takes more than just current download/upload rates and remaining size into account. It actually takes the availaiblity and peer download rates into account as well. So the current way in which the ETA is calculated is already more reliable than the "usual" instantaneous (total - transferred)/speed ETA.

I'm not quite certain what other metrics you're referring to when you say that you'd like additional user-configurable ETAs. Examples please?

As for configurable timestamps... Do you mean for those timestamps as shown in the Added On column et al, or do you mean the ETA column (which isn't really a timestamp)?

Edit: Are you asking for the sliding average window to be configurable...?

[DamianDominoDavis]

Fascinating, that the current ETA calculation uses availability number. I had no idea; I'll check the source code for fun.

The original idea was cut-and-dry imitation integral calculation, from the present condition of the torrent in comparison to X time ago. But what I came to describe is more likened to what would happen if you had a text area, preforming the same calculation repeatedly, with three or four or five values for bt.auto_ul_sample_average.

I went as far as to propose a sandbox user interface for bt.auto_ul_sample_average, the point of which is real-time adjustability. To be honest, I only suggest user definition for sample width because it would be fun to play with it, and useful to intentionally stop short of an abnormal data sample.

And timesteps, not timestamps; sorry for the confusion. I chose "timesteps" over "predefined length of time" in the mechanics description to avoid the chaotic grammar and run-ons.

[Ultima]

Oh, hah, don't apologize for my inability to read xD

If the average were to be configurable in real-time, then µTorrent would have to keep a history of all of the metrics used, would it not? Otherwise, if the window were widened, µTorrent might have already thrown the statistics out, and it wouldn't actually end up using the window specified.

Unfortunately, µTorrent isn't open source, so you won't be able to check the source

[DamianDominoDavis]

In this case, then, I must be slightly confused. The Speed graphs' information's source is easily understood; but those graphs are maintained (within a timeframe). Where is that information, and in what form, then?

[Irrelevant tangent response: the answer is decompile.]

[Ultima]

Fair point that completely slipped my mind.

Not thinking straight right now. The statistics for the Speed tab are stored globally, and only for 2 metrics (global download rate, and global upload rate), not on a per-torrent basis. To allow the sliding average to be configurable for each torrents' ETAs, it would require storing of such numbers for each torrent, which doesn't sound quite "right" to me from an efficiency vs utility standpoint. Dunno.

[DamianDominoDavis]

Oohh.... very important difference. Even if the effect is indistinguishable with one and only one torrent active that session, that's the key that makes it hard to rationalize implementation, isn't it. You can argue either way that the Speed tab ought not to be global (and though I've never voiced it because I know why it should be, it does irritate me endlessly), but not convincingly enough, I know.

Well, anyway.

[Ultima]

FWIW, per-torrent Speed graphs have been requested before, and though I'm not sure what the plans are for that request (it wan't outright rejected, AFAIK)... if it were to be implemented, it would too require storing of statistics, in which case, this request would probably be a piece of cake to implement

[thelittlefire]

I theorize per-torrent graphs will not happen due to sheer resource constraints.. for an eye-candy feature. Statistics could be useful but would bloat (a probably overloaded resume.dat)... though I do think a SET allocation per torrent may be useful for a new .dat file (linear growth vs. growth without bound) similar to how rrdtool is able to store statistical data.