Comment estimer le temps de téléchargement restant (avec précision)?

Il y a des années, j’ai écrit un algorithme pour prédire le temps restant dans un programme d’imagerie et de multidiffusion sur disque utilisant une moyenne mobile avec une réinitialisation lorsque le débit actuel dépassait une plage prédéfinie. Cela permettrait de garder les choses en place à moins que quelque chose de radical ne se produise, puis il s’ajusterait rapidement et reviendrait ensuite à une moyenne mobile. Voir exemple graphique ici:

La ligne bleue épaisse dans cet exemple de graphique correspond au débit réel au fil du temps. Notez le faible débit au cours de la première moitié du transfert, puis il monte en flèche dans la seconde moitié. La ligne orange est une moyenne globale. Notez qu’il ne s’ajuste jamais assez loin pour pouvoir prédire avec précision le temps qu’il faudra pour finir. La ligne grise est une moyenne mobile (c.-à-d. La moyenne des N derniers points de données – dans ce graphique, N est 5, mais en réalité, il se peut que N doive être plus grand pour être suffisamment lisse). Il récupère plus rapidement, mais il faut encore du temps pour s’ajuster. Il faudra plus de temps au plus grand N. Donc, si vos données sont assez bruyantes, alors N devra être plus grand et le temps de récupération sera plus long.

La ligne verte est l’algorithme que j’ai utilisé. Il se déroule comme une moyenne mobile, mais lorsque les données se déplacent en dehors d’une plage prédéfinie (désignée par les lignes bleues et jaunes claires), il réinitialise la moyenne mobile et saute immédiatement. La plage prédéfinie peut également être basée sur l’écart type afin de pouvoir ajuster le niveau de bruit des données automatiquement. Je viens de jeter ces valeurs dans Excel pour les représenter graphiquement pour que cette réponse ne soit pas parfaite, mais vous avez l’idée.

Les données pourraient être conçues pour que cet algorithme ne soit pas un bon indicateur du temps restant. L’essentiel est que vous devez avoir une idée générale de la façon dont les données se comportent et choisir un algorithme en conséquence. Mon algorithme fonctionnait bien pour les jeux de données que je voyais, alors nous avons continué à l’utiliser.

Un autre conseil important est que les développeurs ignorent généralement les temps de configuration et de déassembly dans leurs barres de progression et leurs calculs d’estimation de temps. Cela se traduit par une barre de progression éternelle de 99% ou 100% qui rest juste là (pendant le vidage des caches ou tout autre travail de nettoyage) ou des estimations précoces lors de l’parsing des répertoires ou du travail d’installation mais n’accumulant aucun pourcentage d’avancement, qui lance tout. Vous pouvez exécuter plusieurs tests incluant les temps de configuration et de déassembly et fournir une estimation de la durée moyenne de ces temps ou en fonction de la taille du travail et append cette durée à la barre de progression. Par exemple, les premiers 5% du travail sont configurés et les 10% restants sont des tâches de déassembly. Les 85% restants représentent le téléchargement ou le processus de répétition. Cela peut aider beaucoup aussi.

Une moyenne mobile exponentielle est idéale pour cela. Il permet de lisser votre moyenne afin que chaque fois que vous ajoutez un nouvel échantillon, les anciens échantillons deviennent de plus en plus importants par rapport à la moyenne générale. Ils sont toujours considérés, mais leur importance diminue de manière exponentielle – d’où le nom. Et comme il s’agit d’une moyenne “mobile”, il vous suffit de garder un seul numéro.

Dans le contexte de la mesure de la vitesse de téléchargement, la formule ressemblerait à ceci:

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

SMOOTHING_FACTOR est un nombre compris entre 0 et 1. Plus ce nombre est élevé, plus les anciens échantillons plus anciens sont supprimés. Comme vous pouvez le voir dans la formule, lorsque SMOOTHING_FACTOR vaut 1, vous utilisez simplement la valeur de votre dernière observation. Lorsque averageSpeed 0, averageSpeed ne change jamais. Donc, vous voulez quelque chose entre les deux, et généralement une valeur faible pour obtenir un lissage décent. J’ai trouvé que 0,005 fournit une très bonne valeur de lissage pour une vitesse de téléchargement moyenne.

lastSpeed est la dernière vitesse de téléchargement mesurée. Vous pouvez obtenir cette valeur en exécutant une timer toutes les secondes pour calculer le nombre d’octets téléchargés depuis la dernière fois que vous l’avez exécuté.

averageSpeed est évidemment le nombre que vous souhaitez utiliser pour calculer votre temps restant estimé. Initialisez ceci à la première mesure de dernière lastSpeed .

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

Je pense que le mieux que vous puissiez faire est de diviser la taille de fichier restante par la vitesse de téléchargement moyenne (téléchargée si divisée par la durée du téléchargement). Cela va fluctuer un peu pour commencer mais sera de plus en plus stable au fur et à mesure que vous téléchargez.

En plus de la réponse de Ben Dolman, vous pouvez également calculer la fluctuation dans l’algorithme. Il sera plus lisse, mais il prédira également la vitesse moyenne.

Quelque chose comme ça:

 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; 

Fluctuation ou non, elle sera à la fois aussi stable que l’autre, avec les bonnes valeurs de prédiction et de depencySpeed; vous devez jouer avec un peu en fonction de votre vitesse internet. Ces parameters sont parfaits pour une vitesse moyenne de 600 Ko / s alors qu’elle varie de 0 à 1 Mo.