Come stimare il tempo di download rimanente (con precisione)?

Question

Sicuro di poter dividere la dimensione del file rimanente dalla velocità di download corrente, ma se la velocità di download oscilla (e lo sarà), questo non produce un risultato molto bello. Qual è un algoritmo migliore per generare countdown più regolari?

Answer 1

Un exponential moving average è perfetto per questo. Fornisce un modo per uniformare la media in modo che ogni volta che si aggiunge un nuovo campione i campioni più vecchi diventino sempre meno importanti per la media generale. Sono ancora considerati, ma la loro importanza diminuisce in modo esponenziale - da qui il nome. E dal momento che si tratta di una media "in movimento", è sufficiente mantenere un solo numero in giro.

Nel contesto di misurare la velocità di download la formula sarà simile a questa:

averageSpeed = SMOOTHING_FACTOR * lastSpeed + (1-SMOOTHING_FACTOR) * averageSpeed; 

SMOOTHING_FACTOR è un numero compreso tra 0 e 1. Più alto è questo numero, i campioni più velocemente anziani vengono scartati. Come puoi vedere nella formula, quando SMOOTHING_FACTOR è 1 stai semplicemente usando il valore dell'ultima osservazione. Quando SMOOTHING_FACTOR è 0 averageSpeed non cambia mai. Quindi, vuoi qualcosa in mezzo, e di solito un valore basso per ottenere una levigatezza decente. Ho trovato che 0.005 fornisce un valore di smoothing piuttosto buono per una velocità di download media.

lastSpeed è l'ultima velocità di download misurata. È possibile ottenere questo valore eseguendo un timer ogni secondo circa per calcolare quanti byte sono stati scaricati dall'ultima volta che è stato eseguito.

averageSpeed è, ovviamente, il numero che si desidera utilizzare per calcolare il tempo rimanente stimato. Inizializza alla prima misurazione lastSpeed che ottieni.

Answer 2

Penso che il meglio che puoi fare è dividere la dimensione del file rimanente per la velocità media di download (scaricata fino ad ora divisa per quanto tempo hai scaricato). Questo fluttuerà un po 'per iniziare, ma sarà sempre più stabile più a lungo si scarica.

Answer 3

speed=speedNow*0.5+speedLastHalfMinute*0.3+speedLastMinute*0.2 

Answer 4

In estensione alla risposta di Ben Dolman, è anche possibile calcolare la fluttuazione all'interno dell'algoritmo. Sarà più liscio, ma prevarrà anche la velocità media.

Qualcosa di simile:

prediction = 50; 
depencySpeed = 200; 
stableFactor = .5; 
smoothFactor = median(0, abs(lastSpeed - averageSpeed), depencySpeed); 
smoothFactor /= (depencySpeed - prediction * (smoothFactor/depencySpeed)); 
smoothFactor = smoothFactor * (1 - stableFactor) + stableFactor; 
averageSpeed = smoothFactor * lastSpeed + (1 - smoothFactor) * averageSpeed; 

fluttuazione o no, sarà sia stabile come l'altro, con i giusti valori per la previsione e depencySpeed; devi giocarci un po 'a seconda della velocità di internet. Queste impostazioni sono perfette per una velocità media di 600 kB/s mentre fluttua da 0 a 1 MB.

Answer 5

Ho scritto un algoritmo anni fa per prevedere il tempo rimanente in un programma di imaging e multicasting del disco che utilizzava una media mobile con un ripristino quando il throughput corrente non rientrava in un intervallo predefinito. Manterrebbe le cose lisce a meno che non succedesse qualcosa di drastico, poi si adatterebbe rapidamente e poi tornerebbe di nuovo alla media mobile. Vedi esempio grafico qui:

La linea blu spessa in quel grafico esempio è la velocità effettiva nel tempo. Si noti il ​​basso throughput durante la prima metà del trasferimento e poi salta drammaticamente nella seconda metà. La linea arancione è una media complessiva. Si noti che non si regola mai abbastanza lontano da dare sempre una previsione accurata di quanto tempo ci vorrà per finire. La linea grigia è una media mobile (ad es.la media degli ultimi N punti di dati - in questo grafico N è 5, ma in realtà N potrebbe necessitare di essere più grande per essere abbastanza regolare). Si recupera più rapidamente, ma richiede ancora un po 'di tempo per adattarsi. Ci vorrà più tempo per l'N maggiore. Quindi se i tuoi dati sono piuttosto rumorosi, allora N dovrà essere più grande e il tempo di recupero sarà più lungo.

La linea verde è l'algoritmo che ho usato. Va avanti come una media mobile, ma quando i dati si muovono al di fuori di un intervallo predefinito (indicato dalle sottili linee blu e gialle), ripristina la media mobile e salta immediatamente. L'intervallo predefinito può anche essere basato sulla deviazione standard in modo che possa adattarsi a quanto i dati sono disturbati automaticamente. Ho appena gettato questi valori in Excel per disegnarli per questa risposta, quindi non è perfetto, ma hai un'idea.

I dati potrebbero essere inventati per fare in modo che questo algoritmo non sia un buon predittore del tempo rimanente. La linea di fondo è che è necessario avere un'idea generale di come ci si aspetta che i dati si comportino e scegliere un algoritmo di conseguenza. Il mio algoritmo ha funzionato bene per i set di dati che stavo vedendo, quindi abbiamo continuato a utilizzarlo.

Un altro suggerimento importante è che in genere gli sviluppatori ignorano i tempi di configurazione e di smontaggio nelle barre di avanzamento e nei calcoli delle stime temporali. Ciò si traduce nell'elegante barra di avanzamento del 99% o 100% che rimane inutilizzata per un lungo periodo (mentre le cache vengono svuotate o altri lavori di pulizia stanno accadendo) o stime iniziali quando si verifica la scansione di directory o altri lavori di installazione, accumulando tempo ma non accumulato alcun progresso percentuale, che getta via tutto. È possibile eseguire diversi test che includono i tempi di impostazione e di smantellamento e fornire una stima di quanto tempo sono in media o in base alle dimensioni del lavoro e aggiungere il tempo alla barra di avanzamento. Ad esempio, il primo 5% del lavoro è il lavoro di installazione e l'ultimo 10% è un lavoro di smontaggio e quindi l'85% nel mezzo è il download o qualsiasi altro processo ripetitivo di tracciamento. Questo può essere di grande aiuto.