xkcd

Je sais que la boîte de dialogue de copie Windows (sous Windows XP) enregistre d’abord la copie en mémoire, et qu’elle est toujours en cours de copie après la fermeture de la boîte de dialogue. si inexact, même lorsque la copie en mémoire a été désactivée (sous Vista et Windows 7)? Cela semble tellement arbitraire! Comment fonctionne la procédure de copie dans son ensemble et pourquoi Windows ne peut-il pas l’estimer correctement?

En bref: les mauvais algorithmes et l'estimation instable sont en réalité une faiblesse d'implémentation.

D'autres outils comme TeraCopy font un meilleur travail. Je pense qu'il n'est pas utile d'expliquer pourquoi leur mise en œuvre n'est pas bonne. Ils l'auront remarqué et s'amélioreront.

Ce qui est difficile:

1. Vous devez tenir compte des fluctuations des ressources (CPU / bande passante réseau / vitesse du disque dur principalement)
2. Vous devez extrapoler le temps que cela prendra en prévoyant le comportement (ce que la copie de fichier Windows fait définitivement mal maintenant).
3. Apportez des ajustements dans le temps à votre estimation initiale (je veux dire de petits ajustements qui ne ressemblent pas à l'image amusante ci-dessus!)

Pour cela, non seulement le nombre d'octets, mais également le nombre de fichiers à créer jouent un rôle. Si vous avez un million de fichiers de 1Ko ou des milliers de fichiers de 1Mo, la situation sera assez différente car le premier supporte la surcharge de créer beaucoup de fichiers. Selon le système de fichiers utilisé, cela peut prendre plus de temps que le transfert des données.

Ce dialogue m'a rendu fou plusieurs fois également:

• Sur un système WinNT plus ancien, si vous aviez beaucoup de petits fichiers à copier, le nom et l'animation sympa affichés pour chaque fichier ralentissaient tout le processus et devenaient pratiquement inutilisables.

La copie moderne de Windows n’est guère meilleure:

• Pour calculer la quantité de données à transférer, il semble commencer par effectuer une recherche (c'est ce que je suppose qu'il fait). Il faut donc un certain temps si vous sélectionnez plusieurs répertoires jusqu'à ce que le travail commence réellement.
• Certains délais d’exécution intégrés empêchent la copie de gros fichiers (> environ 60 Go sur mon système). Le problème, c'est que cela vous dit qu'après avoir déjà copié plus de 30 Go sur le réseau, la bande passante et le temps sont perdus, car vous devez tout recommencer à zéro!
• La copie de fichiers d'un ordinateur à un autre est extrêmement lente pour une raison quelconque. (Je veux dire par rapport à la bande passante disponible du réseau. L'utilisation d'autres outils est plus rapide, donc ce n'est pas une limitation informatique.)

Raymond Chen a écrit un très bel article à ce sujet. Fondamentalement, le dialogue ne fait que deviner :).

http://blogs.msdn.com/b/oldnewthing/archive/2004/01/06/47937.aspx

"Parce que la boîte de dialogue de copie ne fait que deviner. Elle ne peut prédire l'avenir, mais elle est obligée d'essayer. Et au tout début de la copie, quand il y a très peu d'historique, la prédiction peut être très mauvaise.

Voici une analogie: supposons que quelqu'un vous dise: "Je vais compter jusqu'à 100, et vous devez donner des estimations continues quant au moment où j'aurai terminé." Ils commencent, "un, deux, trois ...". Vous remarquez qu’ils atteignent environ un chiffre par seconde, vous estimez donc 100 secondes. Uh-oh, maintenant ils ralentissent. "Quatre ... ... cinq ... ..." ... Maintenant, vous devez modifier votre estimation à peut-être 200 secondes. Maintenant, ils accélèrent: "six-sept-huit-neuf" Vous devez mettre à jour votre estimation à nouveau.

Maintenant, quelqu'un qui n'écoute que vos estimations et non la personne qui compte pense que vous êtes en dehors de votre rocker. Votre estimation est passée de 100 secondes à 200 secondes à 50 secondes. quel est votre problème? Pourquoi ne pouvez-vous pas donner une bonne estimation?

La copie de fichier est la même chose. Le shell sait combien de fichiers et combien d'octets vont être copiés, mais il ne sait pas à quelle vitesse va être le disque dur, le réseau ou Internet, il faut donc deviner. Si le débit de copie change, l'estimation doit être modifiée pour prendre en compte le nouveau taux de transfert. "

Je vais compter jusqu'à dix, 1....2....3....4combien de points faut-il pour arriver à dix?

5.6.7Et maintenant? Prenez-vous en compte tous les points passés entre les nombres et faites-vous la moyenne, ne prenez-vous que les 4 derniers intervalles et utilisez-vous cette moyenne, ne regardez-vous que le dernier intervalle?

Vous avez le même problème avec les transferts de fichiers. La vitesse à laquelle le fichier est transféré n'est pas constante, il accélère et ralentit en fonction de nombreux facteurs. La raison pour laquelle le nombre saute tellement est que Microsoft s'est penché vers le côté "ne compte que le dernier intervalle" du spectre.

Il n'y a rien de mal à ce côté du spectre, cela vous donne des "secondes par seconde" plus précises (une seconde en temps réel fait baisser le compteur d'une seconde), mais l'ETA total de la minuterie varie beaucoup .

Un bon exemple du côté opposé est 7-Zip lorsqu’il se compresse. Si la vitesse de compression diminue au fur et à mesure de son traitement, vous constaterez que l’ETA ne saute pas de façon spectaculaire, contrairement à un transfert ETA de transfert de fichier. Toutefois, il peut s'écouler 2 à 3 secondes réelles avant que le minuteur ne se déclenche une seconde (ou même il peut commencer à compter) ) jusqu'à ce qu'il se stabilise à la nouvelle vitesse.

En fait , Raymond Chen, de Microsoft, a répondu à cela de WAAAAAY de manière presque canonique , et le puzzle comporte quelques pièces.

Parce que le dialogue de copie ne fait que deviner. Il ne peut prédire l'avenir, mais il est obligé d'essayer. Et au tout début de la copie, quand il y a très peu d'histoire à parcourir, la prédiction peut être très mauvaise.

Premièrement, Windows est en train de deviner. Il sait combien de fichiers et quelle est leur taille, mais le taux de transfert par fichier est très variable. Cela dépend dans certains cas de la taille ou même de l’emplacement sur le lecteur. À mesure que le temps passe, il ajuste son estimation en fonction des conditions actuelles et passées et, de ce fait, vous obtenez des vitesses de transfert estimées inexactes dans des conditions réelles.

Voici l'explication de Raymond Chen , ingénieur principal en conception de logiciels chez Microsoft:

Pourquoi le dialogue de copie donne-t-il des estimations si horribles?

Parce que le dialogue de copie ne fait que deviner. Il ne peut prédire l'avenir, mais il est obligé d'essayer. Et au tout début de la copie, quand il y a très peu d'histoire à parcourir, la prédiction peut être très mauvaise.

Voici une analogie: supposons que quelqu'un vous dise: "Je vais compter jusqu'à 100, et vous devez donner des estimations continues quant au moment où j'aurai terminé." Ils commencent, "un, deux, trois ...". Vous remarquez qu’ils atteignent environ un chiffre par seconde, vous estimez donc 100 secondes. Uh-oh, maintenant ils ralentissent. "Quatre ... ... cinq ... ..." ... Maintenant, vous devez modifier votre estimation à peut-être 200 secondes. Maintenant, ils accélèrent: "six-sept-huit-neuf" Vous devez mettre à jour votre estimation à nouveau.

Le billet de blog cité ci-dessus discute longuement de cette question, avec quelques commentaires intéressants.

Raymond Chen est une personne légendaire, "Chuck Norris de Microsoft", je suppose que vous n'obtiendrez pas une réponse plus autoritaire. Je suis sûr qu'il a au moins vu le code en question.

La raison évidente est que la vitesse du transfert varie avec le temps, de même que la moyenne, de même que la prédiction. Pour expliquer cela à un ami non-tech, j'ai utilisé une analogie impliquant un voyage en avion. Vous allez survoler l'Atlantique. Lorsque vous arrivez avec un taxi à l'aéroport de départ, votre ETA dure environ deux mois. Lorsque vous débarquerez à l'aéroport d'arrivée, en fonction de votre vitesse moyenne jusqu'à présent, vous arriverez chez votre ami en 5 secondes.

Mais vous devez comprendre à quel point la vitesse peut varier, même avec ce qui semble être un scénario prévisible, comme la copie de fichiers sur le même disque ou entre deux disques locaux. Une des nouvelles fonctionnalités que j'aime dans Windows 8 est la possibilité de représenter graphiquement la vitesse au fil du temps si vous cliquez sur "plus de détails". Si vous n'avez pas accès à un ordinateur Windows 8, recherchez des exemples dans la boîte de dialogue de copie de Windows 8 . Beaucoup d’entre eux sont assez plats, mais beaucoup sont aussi troublants, au point qu’on se demande si le disque dur est réellement en bon état, alors qu’il tombe à zéro.

Certaines de ces difficultés sont probablement dues à des variations de taille de fichier (des champs plus petits donnent plus d’accès, ce qui ralentit la tâche, en particulier sur un disque dur mécanique qui doit chercher en déplaçant sa tête de lecture), mais il peut s’agir d’un lecteur bon marché qui stalle au moindre contact pour éviter d'endommager les plateaux.

Il existe des algorithmes de prédiction ETA meilleurs et pires, mais pour une prédiction précise, l'ordinateur devrait tout connaître. Si vous essayez de rendre cet algorithme «intelligent», vous risquez de créer de nouveaux cas, imprévus, où il est encore plus hilarant.

Le seul moyen de savoir combien de temps il faudra pour compresser un ensemble de fichiers est de les compresser. Parfois, la meilleure estimation de Windows est proche, parfois, elle est totalement erronée. Il en va de même pour la copie d'un grand nombre de fichiers, comme vous l'avez sûrement remarqué.

Ce n'est pas tant un bug qu'un affichage inutile d'informations peu précises. La meilleure façon de résoudre ce problème est de fermer les yeux. Ignore le. ;-)

Peut-être existe-t-il un programme capable de copier / compresser des fichiers et de déclencher une alarme à la fin. Ce serait vraiment utile. Nous pourrions faire une petite sieste en attendant que Windows ait terminé le ménage.

Je pense que la raison a été bien expliquée dans l'un des commentaires de l' article de blog lié à la réponse de Roald:

Il a un algorithme d'estimation horrible. Il n'y a pas d'excuses. S'il doit copier 1000 fichiers de 1 Ko et 10 fichiers de 1 Mo, il pense que le fichier de 1 Mo sera aussi occupé que les fichiers de 1 Ko.

La raison pour laquelle il donne des estimations aussi horribles est que ce n'est pas bien fait. Évidemment, cela ne peut jamais être précis à 100%, mais cela pourrait être beaucoup, beaucoup mieux.

Afin d’accélérer le processus de copie (sans perdre trop de temps à calculer les estimations de temps au lieu d’effectuer des opérations liées à la copie), l’utilitaire de copie Windows intégré à Explorer conserve une quantité limitée d’informations sur la rapidité des opérations d’écriture précédentes. Chaque fois qu'il a besoin de calculer le temps restant, il calcule simplement la durée moyenne des opérations d'écriture, puis multiplie par le nombre d'opérations d'écriture restantes.

Le problème est que le temps nécessaire pour effectuer une opération d'écriture n'est pas constant - il peut en réalité varier considérablement. Cela produit donc des changements importants dans l’estimation du temps.

Il y a 3 facteurs à prendre en compte:

1. La taille totale du transfert.
2. Le nombre de fichiers à transférer.
3. Le "occupé" du média, et éventuellement la connexion.

Les chiffres 1 et 3 semblent avoir l’effet le plus évident sur le calcul du temps de transfert, mais un grand nombre de personnes ne prennent pas en compte le nombre 2. Cela peut avoir un effet énorme sur la durée du transfert et est difficile à quantifier.

Fondamentalement, chaque fois qu'un fichier est écrit, le système de fichiers doit écrire un peu de métadonnées sur le fichier, par exemple. droits de propriété, autorisations, création / modification / accès, etc. Selon le système de fichiers concerné, ces informations peuvent être écrites sur une partie du disque très "éloignée" de l'endroit où le fichier est en cours d'écriture. Cette surcharge du système de fichiers est ce qui peut faire qu'un transfert apparemment simple prenne beaucoup de temps et / ou que l'estimation du temps fluctue énormément.

Exemple: lorsque vous transférez un fichier volumineux, vous remarquerez que l'estimation est stable et assez précise, mais le transfert de centaines de fichiers de tailles différentes, mais de la même taille totale, peut prendre plus de temps et entraîner une adaptation de l'estimation de temps.

Les algorithmes d’estimation actuels présentent trois lacunes.

Contrairement à la croyance populaire, ils ne sont pas assez difficiles à lever les mains en l'air.

La plupart des gens qui écrivent des blogs et dont les gens ici ne sont pas conscients de cette possibilité sont aussi optimistes que je puisse dire en raison de l'étendue de leur domaine d'études et de leur formation. Un remède modeste mais aussi très confortable devrait être possible pour [un diplômé ayant une formation plus récente que les rédacteurs de blogs] [une entreprise de plusieurs milliards de dollars] Microsoft.

Je vais essayer d'expliquer pourquoi.

Les points d'échec sont les suivants. Le noyau:

1. ne peut prédire de manière fiable la charge future d'E / S en raison de circonstances extérieures au noyau

• rien ne devrait être fait à ce sujet car c'est un problème très sans bornes P = NP.

2. ne suit pas l'heuristique IO avec un niveau de détail utile. L'utilisation est un concept beaucoup plus large que la vitesse de lecture / écriture sur disque / réseau .

• il reste très peu de choses à faire à ce sujet, rien de plus que de suivre les informations les plus élémentaires sur l'utilisation d'E / S

  • du disque
    • la dimension moyenne de la vitesse de lecture 1a
    • la vitesse d'écriture moyenne des fichiers de dimension 2a
  • par quanta * selon
    • la dimension de taille du fichier b
    • l'emplacement du fichier sur la dimension du disque c
  • * quantifié en [probable] pas plus de 3 catégories. La réduction de la dimensionnalité nous aiderait à déterminer avec certitude mais 3 devrait être suffisant pour des mécanismes de prédiction meilleurs que probablement (probablement assez efficaces):
    • taille du fichier
      • lumière
      • moyen
      • lourd
    • location [informe de la latence de recherche]
      • début
      • milieu
      • tu obtiens le point
    • la taille et l'emplacement du fichier sont redondants / se chevauchent avec la vitesse de lecture / écriture, ceci est intentionnel
  • nous devons savoir à quel point le disque a été "occupé" pour pouvoir supposer qu'il continuera d'être cette dimension occupée d
    • calculé à partir de la quantité de fichiers en cours de lecture, convertis par résolution avec leurs poids respectifs
    • utilisé pour estimer le temps au début de la copie ... boîte de dialogue basée sur la charge future attendue si tout le reste, mis à part cette boîte de dialogue de copie, se poursuit tel qu'il est maintenant
  • la méthode d'enregistrement aux fins de ... ici est brevetable

3. s'ils étaient suivis , ils n'auraient pas été utilisés pour les heuristiques

• peu de choses ont été faites ici, où nous faisons la plupart du travail
• c’est là que nous mettons les données du n ° 2 à utiliser
  • une analyse statistique approximative des poids et des emplacements des fichiers afin de déterminer la quantité de sauts que nous allons effectuer. Le poids + l'emplacement nous donne une prédiction
  • combiner avec les poids et les emplacements de charge de disque actuels
  • pour estimer ce que nous pensons que la vitesse moyenne de lecture / écriture du nombre de fichiers dimension f sera
  • que nous comparons pour affiner notre modèle
  • ce qui nous permettra d’estimer avec assez de précision la barre de progression et le temps de réalisation
• la méthode d'analyse à des fins de prédiction ... ici est brevetable

Le but de tout ceci est que notre modèle est seulement 2a = F * (bxc) + d complexe

Où a, b et c ont 3 états chacun: le gestionnaire de fichiers jette un coup d'œil sur les fichiers (ou seulement les métadonnées) avant la copie, et F * (bxc) + d n'est pas un calcul coûteux; si vous voulez quelque chose de plus précis, utilisez une table de recherche avec plus d'états - il n'y a pratiquement aucun calcul.

note: les dimensions ici sont pour un plateau, serait différent avec un SSD - début / milieu / fin n'importe pas

La différence essentielle entre ce que j’ai décrit et les implémentations précédentes que nous avons vues jusqu’à présent serait, en bref, d’observer la taille du fichier et la distribution / entropie de fichier sur le disque et de l’utiliser pour rendre compte plus précisément de l’élément temps de l’utilisation du disque.

(le brevet est laissé comme un exercice pour le lecteur ...)

Il y a beaucoup de variables "inconnues" lorsque vous essayez de prédire combien de temps cela va prendre. Par exemple, bien que le programme sache qu'il existe 3 500 fichiers et que leur nombre s'élève à 3,5 Go (3 500 Mo), cela signifie-t-il que chaque fichier mesure 1 Mo? Pas nécessairement. Il pourrait y avoir beaucoup de fichiers de 4 Ko et beaucoup de fichiers de 100 Mo, entre autres. De plus, vous devez prendre en compte l'origine et la destination des fichiers (par exemple, les supports). Quel est le plus gros goulot d'étranglement? Comment compte-t-on essayer de copier des fichiers d'un disque dur via un tunnel VPN ? Vous donnez un meilleur scénario, puis ajustez vos compteurs en temps réel. C'est pourquoi vous voyez ces indicateurs de progression changer à la volée.

Le modèle mathématiquement correct consiste à effectuer une moyenne et une extrapolation naïves:

transfer speed = data copied / time elapsed
time remaining = data remaining / transfer speed

La raison en est que, selon la loi des grands nombres, les fluctuations locales annulent la vitesse de transfert moyenne , ce qui vous donnera le résultat le plus stable.

Ce que Microsoft semble faire, c'est calculer la vitesse de transfert au plus tard. Cela signifie que chaque fluctuation locale modifie le résultat de manière significative.

There is some way to refine or correct this kind of "bug"?

Comme Roald van Doorn l'a dit, il s'agit essentiellement de deviner. Bien sûr, cela ne signifie pas que cela ne pourrait pas être un meilleur devineur. Il y a beaucoup d'heuristiques qui pourraient être utilisées pour calculer cela.

1. Le meilleur moyen, le plus coûteux, serait de conserver un historique des "copies" précédentes, puis d'utiliser des algorithmes d'intelligence artificielle pour calculer une estimation.
2. On pourrait construire une formule basée sur la recherche de combien de temps cela devrait prendre. Ils pourraient prendre en compte des éléments tels que: système de fichiers, nombre de fichiers, taille des fichiers, durée de recherche du disque, vitesses de lecture / écriture en bloc, emplacement des fichiers sur le disque (fragmentation), utilisation actuelle du disque.
3. Un mélange des deux. C'est à dire. Faites des repères pour déterminer la durée de certaines opérations, puis utilisez-les comme historique pour des formules simples.

Évidemment, rien de tout cela n’est facilement implémenté… et j’ai seulement mentionné les copies de fichiers. Un travail similaire devrait être fait pour toutes sortes de transferts.
La question que vous devez vous poser: préféreriez-vous que Microsoft passe le temps de vous donner une meilleure estimation ou préféreriez-vous que vos fichiers soient transférés plus rapidement?

Cependant, si vous compressez quelque chose avec 7-zip, vous remarquerez que c'est beaucoup mieux que de deviner que Windows. Je doute que cela fasse quelque chose d'aussi compliqué, juste un peu meilleur devineur.

En bref, le calcul est basé sur la vitesse de transfert actuelle .

Par exemple: si votre taux de transfert diminue du fait que Windows doit copier une quantité énorme de fichiers minuscules, la durée attendue augmente de manière linéaire et inversement pour les fichiers volumineux.

Il est presque impossible de prédire quelle sera la vitesse de transfert sur l'ensemble du processus de transfert, car elle dépend de nombreux facteurs tels que la taille du fichier, l'utilisation du processeur, les erreurs de transmission, etc.

Ce billet de blog MSDN contient des réponses intéressantes. Amélioration des bases de la gestion de fichiers: copier, déplacer, renommer et supprimer ces informations. Pourquoi est-ce difficile?

Il est presque impossible d'estimer avec précision le temps restant pour terminer une copie car de nombreuses variables imprévisibles et incontrôlables sont impliquées - par exemple, combien de bande passante réseau sera disponible pour la longueur du travail de copie? Votre logiciel anti-virus va-t-il démarrer et commencer à analyser des fichiers? Une autre application devra-t-elle accéder au disque dur? L'utilisateur commencera-t-il un autre travail de copie?

Et comment ils s'améliorent,

Plutôt que de passer beaucoup de temps à établir une estimation de confiance faible qui ne serait que légèrement améliorée par rapport à l’estimation actuelle, nous nous sommes concentrés sur la présentation des informations en lesquelles nous avions confiance de manière utile et convaincante. Ceci met à votre disposition les informations les plus fiables dont vous disposez pour que vous puissiez prendre des décisions plus éclairées.

Cela dit, si vous voulez vraiment améliorer l'estimation donnée et conserver la barre de progression telle qu'elle est, vous pouvez faire quelque chose suggéré dans un commentaire Slashdot :

Conservez un tableau des vitesses attendues pour chaque périphérique de stockage du système de fichiers. Enregistrez le temps nécessaire pour lire les informations du système de fichiers. Lorsqu'un dispositif est monté, si cela est raisonnable pour son type, cherchez au milieu et à la fin, en mesurant les vitesses là aussi. Obtenez des courbes approximatives pour les vitesses de lecture et d'écriture sur plusieurs emplacements et utilisez-les pour des estimations futures. Pour les futures opérations de lecture et d’écriture, prenez note de leur emplacement et de leur vitesse, puis ajustez les courbes en conséquence.

Quand une opération commence, examinez les courbes d’entrée et de sortie pour les appareils respectifs. Trouvez la vitesse attendue pour l'emplacement cible. Quelle que soit la vitesse la plus basse, elle doit être utilisée pour l’estimation.

Je voulais juste ajouter que le nombre total de fichiers est le facteur le plus fastidieux en termes de copie de fichiers sur un PC. En tant que jeune étudiant, je me souviens toujours d'avoir induit délibérément une défaillance des ordinateurs dans mon cours d'informatique en commençant par 1 fichier sans contenu, en le copiant, en sélectionnant les 2 fichiers, en copiant à nouveau, etc. Après avoir dépassé environ 1024 fichiers, il a commencé à prendre énormément de temps, même quand il ne copiait aucune information, à l'exception de l'en-tête du fichier. Essayez vous-même, même sur un nouveau système d'exploitation, une copie de fichier exponentielle et vous verrez ce qui se passe. Nourriture pour la pensée.

Je viens de copier 200 Go de disque dur USB sur mon lecteur principal. Il y avait environ 130000 fichiers

Après les 4-5 premières minutes, j'ai observé que:

• Pour les plus petits fichiers, le taux était d'environ 100 fichiers par seconde à environ 600 Ko / s
• Et pour les gros fichiers, c'était comme 70 Mo / s

Au début de la fenêtre, l’estimation passait d’environ 1 heure à plus de 5 heures, puis de nouveau à 1 heure, etc. À la fin, comme dans 95% des cas, l’estimation passait toujours de 10 minutes à plus de 10 heures. Ainsi, au lieu de devenir plus précis, les résultats étaient de moins en moins précis.

Spectacles mathématiques simples:

130 000 fichiers à 100 fichiers par seconde = 22 minutes

200 000 Mo à 70 Mo par seconde = 47 minutes

22 minutes - en attente de temps en copiant des fichiers de quelques kilo-octets. 47 minutes - le temps nécessaire pour transférer les données réelles s'il n'y a pas de temps de recherche.

La somme des 22min + 47min est le temps maximum absolu que cela pourrait prendre.

Alors évidemment, l'estimation devrait être quelque part entre 47 et 69 minutes.

Ce que la boîte de dialogue indique à environ 90%: "Je copie des petits fichiers à 1 Mo / s, il y a 20 Go de données supplémentaires, cela prendra 5h30.

Quelques secondes plus tard: "Je copie un fichier volumineux ici, à 70 Mo / s, il faudra 4 minutes pour le terminer.

Ce que l'homme voit réellement dans le même dialogue: 120 000 fichiers et 180 Go sont déjà copiés pendant 40 minutes. Les 10000 fichiers restants et 20 Go devraient prendre environ 5 minutes

La boîte de dialogue fournit suffisamment d’informations pour effectuer des calculs de plus en plus précis à chaque seconde. Il sait à quelle vitesse les petits fichiers sont copiés. Il sait à quelle vitesse les gros fichiers sont copiés. Il sait également combien de fichiers et combien d'octets il reste.

Il est si simple de formuler une hypothèse aussi précise qu'en définissant les limites supérieure et inférieure.

La boîte de dialogue affiche un peu plus de données correctes dans le cas où les gros fichiers sont avant les petits fichiers. Si tel est le cas, cela commence à 40 minutes, et après 30 minutes, il commence à copier les petits fichiers et dit "bon, il me faut 20 minutes de plus".

Mais quand les petits fichiers au début et les gros fichiers sont à la fin. La boîte de dialogue ne s’intéresse pas vraiment à ce que "fichiers par seconde" transfère les petits fichiers. Son calcul, comme le nombre de petits fichiers, est infini, et comme si ce serait toujours petit.