Computing Horaires estimés des copies / mouvements de fichier?

regarder sur Ma réponse à une question similaire (et les autres réponses là-bas) sur la manière dont le temps restant est estimé dans l'Explorateur Windows.

À mon avis, il n'y a qu'un seul moyen d'obtenir de bonnes estimations:

• Calculez le nombre exact d'octets à copier avant de commencer le processus de copie
• Recalculez votre estimation régulièrement (toutes les 1, 5 ou 10 secondes, YMMV) sur la base de la vitesse de transfert actuelle
• La vitesse de transfert en cours peut fluctuer fortement lorsque vous copiez sur un réseau, utilisez donc une moyenne, par exemple en fonction de la quantité d'octets transférés depuis votre dernière estimation.

  Notez que le premier point peut nécessiter un certain travail, si vous copiez plusieurs fichiers. C'est probablement pourquoi les gars de Microsoft ont décidé d'y aller sans elle. Vous devez décider vous-même si les frais généraux supplémentaires créés par ce calcul vaut la peine de donner à votre utilisateur une meilleure estimation.

Je pense que les dialogues devraient simplement admettre leurs limitations. Ce n'est pas gênant parce que cela ne fait pas de donner une estimation de temps utile, c'est ennuyeux, car il propose une estimation qui est une estimation évidente.

Donc, si vous aimez, en fonction du taux actuel ou du taux moyen jusqu'à présent, des moyennes roulantes jusqu'à présent, des moyennes qui roulent des valeurs aberrantes, ou peu importe. Dépend de l'opération et des durées typiques des événements qui le retardent, vous pourriez avoir des algorithmes différents lorsque vous connaissez la copie du fichier implique un lecteur réseau. Mais jusqu'à ce que votre estimation ait été assez cohérente pendant une période de temps égale à la moindre de 30 secondes ou 10% de l'heure estimée, affichez "Oh chère, il semble y avoir une sorte de maintien" lorsqu'il est massivement ralenti, ou juste ignorer C'est si c'est massivement accéléré. p>

Par exemple, des messages de dialogue prises à des intervalles de 1 seconde lorsqu'une connexion stipule brièvement: P>

remaining: 60 seconds               // estimate is 60 seconds
remaining: 59 seconds               // estimate is 59 seconds
remaining: delayed [was 59 seconds] // estimate is 12 hours
remaining: delayed [was 59 seconds] // estimate is infinity
remaining: delayed [was 59 seconds] // got data: estimate is 59 seconds
// six seconds later
remaining: 53 seconds               // estimate is 53 seconds

Je réfléchis à celui-ci moi-même. J'ai une routine de copie - via une interface de style de l'Explorateur Windows - qui permet de transférer des fichiers sélectionnés à partir d'un périphérique Android, à un PC.

Au début, je connais la taille totale du ou des fichiers à copier et, comme j'utilise C # .NET, j'utilise un chronomètre, pour obtenir le temps écoulé et pendant que la copie est En cours, je tiens au total ce qui est copié jusqu'à présent, en termes d'octets.

Je ne l'ai pas encore testé, mais la meilleure façon semble être celle-ci -

estimé = écoulé * ((totassize - copiedsofar) / copielfar)

Je ne l'ai jamais vu comme vous l'expliquez-les, par des octets TraSfeed et des octets totaux.

L'expérience "a toujours fait beaucoup plus de sens (pas bon / précis) si vous utilisez plutôt des octets de chaque fichier, et le nombre de fichiers. C'est ainsi que l'estimation balance sauvagement.

Si vous transférez d'abord des fichiers volumineux, l'estimation va longtemps, même avec la connexion statique. C'est comme si elle pense naïvement que tous les fichiers sont la taille moyenne de celles ainsi transférées, puis fait supposer que la taille moyenne du fichier restera exacte pour tout le temps.

Ceci, et les autres manières, tout s'aggrave lorsque la connexion "vitesse" varie ...