Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#2588 closed Enhancement (invalid)

EtaDLSpeed could be based on a longer time interval

Reported by: motumboe Owned by:
Priority: Low Milestone: None Set
Component: Transmission Version: 1.76
Severity: Minor Keywords: eta speed
Cc:

Description

I think that this part (trunk/libtransmission/torrent.c, lines 988-993) could be improved with some small modifications. These are the original lines:

if( ( tor->etaDLSpeedCalculatedAt + 800 ) < now ) {
	                tor->etaDLSpeed = ( ( tor>etaDLSpeedCalculatedAt + 4000 ) < now )
	                    ? s->pieceDownloadSpeed /* if no recent previous speed, no need to smooth */
	                    : 0.8*tor->etaDLSpeed + 0.2*s->pieceDownloadSpeed; /* smooth across 5 readings */
	                tor->etaDLSpeedCalculatedAt = now;
	            }

The 0.8/0.2 ratio covers a too short time interval.

If the speed is constant and equals S and then suddenly doubles (2*S), EtaDlSpeed reaches 1,9 times S in 11 cycles (e.g. 800*11 = 8,8s).

If we consider that download speed varies very much, 9 seconds are a small amount of time.

For example, let's have a 700MB file we need. Let's suppose that the average speed will be 200kb/s. It will take about a hour. I think that a moving average on the last 5 minutes is ok.

In order to achieve this, I think that 5s cycles are ok (instead of 800ms). So the moving average should get to 90% of the new value in 60 cycles -> this is achieved by setting the ratio at 0.96/0.04.

Also, I think that a 4s stop should not reset the average. I think that this should happen with 2 minutes stop, or the like.

So, I think that the ETA could be improved by using these lines:

if( ( tor->etaDLSpeedCalculatedAt + 5000 ) < now ) { /* recalculated every 5s */
	                tor->etaDLSpeed = ( ( tor>etaDLSpeedCalculatedAt + 120000 ) < now )
	                    ? s->pieceDownloadSpeed /* if no recent previous speed, no need to smooth */
	                    : 0.96*tor->etaDLSpeed + 0.04*s->pieceDownloadSpeed; /* smooth across about 60 readings */
	                tor->etaDLSpeedCalculatedAt = now;
	            }

Attachments (2)

eta comparison.jpg (123.7 KB) - added by motumboe 13 years ago.
ETA comparison graph
eta.ods (163.5 KB) - added by motumboe 13 years ago.
spreadsheet file for ETA comparison

Download all attachments as: .zip

Change History (5)

comment:1 Changed 13 years ago by charles

  • Milestone changed from 1.80 to None Set
  • Version changed from 1.76+ to 1.76

comment:2 Changed 13 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

I appreciate the patch, but when we discussed this in the devel channel, we all thought that the current averaging was pretty reasonable and that 60 5-second cycles was extremely high, so we're not going to use this patch. Please feel free to submit other code in the future.

Changed 13 years ago by motumboe

ETA comparison graph

Changed 13 years ago by motumboe

spreadsheet file for ETA comparison

comment:3 Changed 13 years ago by motumboe

Thank for your attention Charles.

Anyway, I attach this file which demonstrates the outcome of my work. Maybe you'll be wanting looking at this if you'll reconsider your opinion about this issue in the future.

It compares the new method versus the old method.

The torrent (351.5MB) started at 18.34 and was 36 minutes long (average speed 166kb/s).

In order to do the comparison I run both the estimators at the same time, calculated the estimated finish time at every cycle, and saved the data to an external file.

In the graph the new method is represented by the red line. It is more accurate (its square root error is about three times less than the old method), and the more important thing, it is much more stable. I even think that 0.97 could do better.

Anyway thanks again for your eccellent work with transmission.

Cheers

Marco

Note: See TracTickets for help on using tickets.