Display realistic time remaining values in snark

[jogger]

Currently time remaining is calculated based on current transfer speed. This varies widely and is too optimistic, since stalled torrents, unsuccessful transfers, torrents currently without peers und most importantly downtimes are not taken into account.

Proposal: calculate time remaining as: (now - time_torrent_was_started) * (total_data - data_transferred) / data_transferred. Taking local creation date of torrent file for time_torrent_was_started should be crash proof.

Benefits: As soon as some pieces of data are received, users get a realistic, meaningful and slowly changing value. A meaningful value can and should be displayed even when transfers are stalled or seeders are temporarily offline. Users get realistic values based on their past usage pattern and get an incentive to let the machine run, because as long as they can look at it, the value tends to decrease fast. Slow leechers are discouraged from tying up resources over many months (or get their gear in order), when they constantly see time remaining > 1 year instead of the illusion they could finish within months.

[zzz]

The current implementation is not biased to be optimistic or pessimistic (except during end game, see #1775). It's based on a snapshot in time. Your proposal is to make that time much much much longer. Apparently you don't have an issue with the displayed bandwidth being optimistic or widely-varying? But wouldn't it be strange to have one time scale for bandwidth calculation and one for ETA? Maybe not.

At torrent startup or after changing network conditions, a very long time scale would make the display less "realistic". It's a tradeoff, there is no perfect answer.

Torrent creation date only works until you stop i2p and restart later. It may be crash proof but it's not guy-who-runs-i2p-4-hours-a-day-proof.

Not buying your theory that the displayed ETA is somehow responsible for "incentive" or "discouraging" behavior.

This is a nice thing to bikeshed but I don't yet see a convincing argument to change things.

[zzz]

Another example which is quite common, and may be the best counterargument: A user starts up a torrent that has a sole low-bandwidth seeder and a bunch of leeches all at the same completion %. For the new user, he downloads it really fast until he "catches up" to all the other leeches, when it slows down by a factor of 5 or 10 or more, and that's going to be the speed until it's done. With a very long time scale for ETA calculation, the display will never be "realistic".

[zzz]

hearing no objection, closing wontfix.