Opened 5 years ago

Closed 4 years ago

#1909 closed enhancement (wontfix)

Display realistic time remaining values in snark

Reported by: jogger Owned by: zzz
Priority: minor Milestone: undecided
Component: apps/i2psnark Version: 0.9.28
Keywords: snark time remaining Cc:
Parent Tickets: Sensitive: no


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.


Change History (4)

comment:1 Changed 5 years ago by 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.

comment:2 Changed 5 years ago by 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".

comment:3 Changed 4 years ago by zzz

hearing no objection, closing wontfix.

comment:4 Changed 4 years ago by zzz

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.