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

Bien sûr, vous pourriez diviser le reste de la taille du fichier par le courant de la vitesse de téléchargement, mais si votre vitesse de téléchargement varie (et il le fera), ce n'est pas de produire un très joli résultat. Qu'est ce qu'un meilleur algorithme pour produire plus lisse comptes à rebours?

OriginalL'auteur mpen | 2010-05-06

  1. 7

    J'ai écrit un algorithme ans pour prédire le temps restant dans une image disque et de la multidiffusion programme qui a utilisé une moyenne mobile avec un reset quand le débit est passé à l'extérieur d'une plage prédéfinie. Il serait de garder les choses en douceur, à moins que quelque chose de radical qui s'est passé, alors il faudrait s'adapter rapidement et ensuite revenir à une moyenne mobile de nouveau. Voir l'exemple de graphique ici:

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

    La ligne bleue épaisse dans cet exemple, le graphique est le débit réel au fil du temps. Avis de la faible débit pendant la première moitié du transfert et puis, il saute de façon spectaculaire dans la seconde moitié. La ligne orange est une moyenne globale. Remarquez qu'il ne s'ajuste jusqu'assez loin pour donner une prévision précise de combien de temps il faudra pour terminer. La ligne grise est une moyenne mobile (c'est à dire la moyenne de la dernière N points de données - dans ce graphe N est de 5, mais en réalité, N peut-être besoin d'être plus grand pour assez lisse). Il récupère plus vite, mais prend toujours un certain temps pour s'adapter. Il faudra plus de temps le plus grand de N est. Donc, si vos données est assez bruyant, alors N devra être plus grande et le temps de récupération sera plus longue.

    La ligne verte est l'algorithme que j'ai utilisé. Elle va de pair, tout comme une moyenne mobile, mais lorsque les données se déplace à l'extérieur d'une plage prédéfinie (désigné par la lumière de fines lignes bleues et jaunes), il remet à la moyenne mobile et saute immédiatement. La plage prédéfinie peut également être basée sur l'écart-type de sorte qu'il peut s'adapter à la façon dont bruyant, les données sont automatiquement. J'ai juste mis ces valeurs dans Excel diagramme pour cette réponse si ce n'est pas parfait, mais vous obtenez l'idée.

    Données pourraient être ingénié à rendre cet algorithme ne parviennent pas à être un bon indicateur de temps restant cependant. La ligne de fond est que vous devez avoir une idée générale de la façon dont vous pensez que les données de se comporter et de choisir un algorithme en conséquence. Mon algorithme a bien fonctionné pour les ensembles de données que je voyais, donc nous avons continué à l'utiliser.

    Un autre truc important, c'est que généralement les développeurs ignorer l'installation et le démontage fois dans leurs barres de progression et d'estimer le temps de calcul. Cela se traduit dans l'éternel 99% ou 100% de la barre de progression qui se trouve juste là pour un long moment (alors que les caches sont vidés ou d'autres travaux de nettoyage passe) ou sauvages début d'estimations lors de la numérisation des répertoires ou d'autres travaux d'installation se produit, revenant de temps, mais ne revenant pas n'importe quel pourcentage de progrès, qui jette le tout hors tension. Vous pouvez exécuter plusieurs tests qui comprennent le montage et le démontage des temps et de venir avec une estimation de combien de temps ces temps sont en moyenne ou en fonction de la taille de l'emploi et d'ajouter que le temps de la barre de progression. Par exemple, le premier de 5% des travaux est travaux d'installation et les derniers 10% est le démontage de travail et ensuite les 85% dans le milieu est le téléchargement ou quoi que répéter le processus de suivi de votre colis est. Cela peut aider beaucoup trop.

    De bons conseils! Merci pour le partage.

    OriginalL'auteur rcronk

  2. 113

    Un moyenne mobile exponentielle est excellent pour cela. Il fournit un moyen de lisser votre moyenne, de sorte que chaque fois que vous ajoutez un nouvel échantillon le plus âgé des échantillons de devenir de moins en moins important à la moyenne globale. Ils sont toujours considérés, mais leur importance diminue de façon exponentielle, d'où le nom. Et puisque c'est un "déplacement" de la moyenne, vous ne devez avoir qu'un seul nombre autour de.

    Dans le contexte de la mesure de la vitesse de téléchargement de la formule pourrait ressembler à ceci:

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

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

    lastSpeed est la dernière mesure de la vitesse de téléchargement. Vous pouvez obtenir cette valeur par l'exécution d'un timer toutes les secondes pour calculer combien d'octets ont téléchargé depuis la dernière fois que vous avez couru.

    averageSpeed est, de toute évidence, le numéro que vous souhaitez utiliser pour calculer une estimation de votre temps restant. Initialiser ce pour la première lastSpeed mesure que vous obtenez.

    Simple, mais semble bon!
    Pas très claire sur le temps restant pour le téléchargement. En mesure de calculer la vitesse Moyenne de Déplacement de l'Échantillonnage .

    OriginalL'auteur Ben Dolman

  3. 7
    speed=speedNow*0.5+speedLastHalfMinute*0.3+speedLastMinute*0.2
    c'est à dire pondérée, en mettant l'accent sur plus de la période récente.
    ouais, vous l'obtenez
    +1, c'est chaud!

    OriginalL'auteur TiansHUo

  4. 5

    Je pense que le mieux que vous pouvez faire est de diviser le reste de la taille du fichier par la moyenne de la vitesse de téléchargement (téléchargé jusqu'à présent divisé en combien de temps vous avez été en téléchargement). Cela va fluctuer un peu au début, mais il sera de plus en plus stable, le plus que vous téléchargez.

    mais considérons le cas où l'utilisateur a été télécharger sur les 24 dernières heures et les minutes, il y a la connexion internet est un juste cassé, et l'utilisateur voit le temps de téléchargement n'est pas infinie. C'est que d'un bug ou une fonctionnalité?
    Le temps de téléchargement tendance à l'infini si la connexion est rompue.
    Ouais... je ne pense pas que je l'aime cette solution. Il met trop l'accent sur les vitesses de téléchargement heures. Ce qui surtout me dérange, c'est que les quelques premières secondes de téléchargement sont généralement assez instable comme il rampe jusqu' (torrents de la connexion à plus de graines) ou ralentit (Shaw powerboost dissipe), et donc, je pense, devrait être écarté complètement.
    C'est la solution la plus simple. Mise en œuvre de la moyenne mobile pourrait être plus précise, mais vous permet de suivre la vitesse et de la mise à jour d'une manière cohérente.

    OriginalL'auteur Andreas Brinck

  5. 2

    Dans le prolongement de Ben Dolman de réponse, vous pouvez aussi calculer les fluctuations à l'intérieur de l'algorithme. Il sera plus lisse, mais il permettra également de prédire la avarage de vitesse.

    Quelque chose comme ceci:

    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;

    La Fluctuation ou pas, il sera à la fois aussi stable que les autres, avec les bonnes valeurs pour la prédiction et depencySpeed; vous avez à jouer avec elle un peu en fonction de votre vitesse d'internet.
    Ces paramètres sont parfaites pour un avarage de la vitesse de 600 ko/s alors qu'il varie de 0 à 1 mo.

    Vous pourriez peut-être la base de votre prédiction sur les téléchargements, alors? Des heures supplémentaires, il serait plus exact.

    OriginalL'auteur Tim

  6. 1

    J'ai trouvé Ben Dolman de réponse très utile, mais pour quelqu'un comme moi qui n'est pas des maths enclins toujours il m'a fallu environ une heure pour mettre pleinement en œuvre ce dans mon code. Voici un moyen plus simple de dire la même chose en python, si il y a des inexactitudes laissez-moi savoir, mais dans mon test, il fonctionne très bien:

    def exponential_moving_average(data, samples=0, smoothing=0.02):
    '''
    data: an array of all values.
    samples: how many previous data samples are avraged. Set to 0 to average all data points.
    smoothing: a value between 0-1, 1 being a linear average (no falloff).
    '''

    if len(data) == 1:
        return data[0]

    if samples == 0 or samples > len(data):
        samples = len(data)

    average = sum(data[-samples:]) /samples
    last_speed = data[-1]
    return (smoothing * last_speed) + ((1 - smoothing) * average)

input_data = [4.5, 8.21, 8.7, 5.8, 3.8, 2.7, 2.5, 7.1, 9.3, 2.1, 3.1, 9.7, 5.1, 6.1, 9.1, 5.0, 1.6, 6.7, 5.5, 3.2] # this would be a constant stream of download speeds as you go, pre-defined here for illustration

data = []
ema_data = []

for sample in input_data:
    data.append(sample)
    average_value = exponential_moving_average(data)
    ema_data.append(average_value)

# print it out for visualization
for i in range(len(data)):
    print("REAL: ", data[i])
    print("EMA:  ", ema_data[i])
    print("--")

    OriginalL'auteur Spencer