Discussion :

[Altess]

Bonjour,

Je souhaiterais savoir si il existe un moyen d'estimer le temps de copie d'un fichier ? L'objectif étant d'autoriser la copie, uniquement si celle si à une durée inférieure à 3 min environ.

Pour information, je suis sous Windows, je code en C++ et j'utilise les API Windows, ainsi que Qt.

Cordialement,
PKO

[ram-0000]

Pour cela, il faut estimer la bande passante de ta copie.

Soit faire une estimation a priori, c'est à dire que tu lances un test qui te permet de calculer la bande passante entre tous tes supports (cela va être dur pour ceux que tu n'a pas genre USB, FTP, ...). Si la taille du fichier et la bande passante calculée préalablement ne permettent pas une copie en 3 minutes, tu refuses le lancement.

Sinon, tu calcules ta bande passante au fur et à mesure et au bout de 20 secondes (par exemple) tu as déjà une idée du temps que cela va mettre (en admettant que cette bande passante reste stable ce qui n'est pas garanti avec FTP par exemple). Au bout de ces 20 secondes, tu sais calculer une durée de transfert et tu peux donc décider de continuer ou alors d'arrêter.

[Altess]

Donc si j'ai bien compris je dois faire un truc du genre :

- Lancer une copie de 20 Mo
- Calculer le temps de copie pour ces 20 Mo
- Déterminer d'après le temps nécessaire pour 20 Mo, le temps nécessaire pour la totalité de ce que je souhaite transférer.

Je lance donc d'un coté ma copie, et de l'autre un chrono.
Et suite à tout ceci, je saurais à peu de chose prêt si le transfert total est réalisable en +/- 3min.

C'est bien cela ?

[LittleWhite]

C'est plutot compliqué ce que tu demande. Car par exemple on lance une copie pendant que le périphérique est occupé, ainsi la vitesse est ralentie.
Disons que la vitesse est ralentie que lors du test de 20Mo, donc tu refuse, alors qu'il est possible qu'après le disque dur soit plus rapide, donc copie possible.
Exemple inverse, le test passe correctement, et d'un coup le périphérique est occupé, tu auras fait une copie de plus de 3 minutes, à cause de cette occupation que tu n'aura pas vu...

[Altess]

LittleWhite > Bonjour. Effectivement, c'est un des nombreux paramètres à prendre en compte. Je pense que la méthode de ram-0000 peut me convenir. A tester. Mais je me pose une question : Lors de la copie sous windows, une petite fenêtre apparait avec les fichiers transférés, et le temps estimé. Comment est obtenu ce temps ?

Cordialement,
PKO

[white_tentacle]

C'est une estimation "à la louche" en fonction du taux de transfert sur les premiers fichiers (tu noteras qu'elle met un peu de temps à apparaître).

C'est un chiffre nécessairement faux, mais suffisamment juste dans beaucoup de cas pour être une bonne indication. De toute façon, on ne sait pas faire mieux.

Après, il y a deux écoles pour l'estimation du temps restant. Celle qui consiste à se baser sur le taux moyen depuis le début de la copie, et celle qui consiste à se baser sur le taux moyen depuis un certain delta de temps.

Ça change les résultats de l'estimation pour des copies assez longues à vitesse non constante. Mais de toute façon, ce chiffre étant faux, il n'y en a pas un de plus juste que l'autre, ça dépend .

[camboui]

Ne pas confondre "faux" et "imprécis"

[3DArchi]

Ne pas confondre "faux" et "imprécis"

Ou plutôt indéterminé... qui peut devenir faux au moment de la réalisation.

[Altess]

Bonjour, et merci de votre aide.

Effectivement, tous les utilisateurs de windows ont pu se rendre compte que le temps estimé lors d'une copie était, souvent, obsolète. Un ami m'a fait prendre en compte un autre paramètre :

Si on copie un fichier vers un disque inactif, alors la copie sera plus longue du fait que le disque devra se "mettre en route".

Est-ce vrai ?

Pour revenir a cette estimation proposée par windows lors de la copie de fichier. Même si cette dernière est "imprécise", y a t'il un moyen de la récupérer ? Une API Windows peut être ?

Cordialement,
PKO

[camboui]

Oui, CopyFileEx() prend en paramètre une fonction callback.

[loufoque]

Un disque a un accès séquentiel.
Si tu étais en train d'écrire à un endroit, puis tu veux écrire à un autre endroit, il faut déplacer la tête de lecture, ce qui prend du temps (c'est un processus mécanique et non électronique).

Donc si tu as plusieurs processus qui veulent écrire sur le disque en même temps, ça fait zigzaguer la tête de lecture et tu perds du temps.
Après c'est le job du système d'exploitation d'ordonnancer les différents accès pour éviter de trop faire bouger la tête.
Une approche est aussi d'écrire en RAM et de laisser l'OS mettre ça sur le disque quand il a le temps. Ce que linux essaie de faire au maximum par exemple.

[camboui]

Quelques cas vécus de copie de fichiers de serveur à serveur.

Il est plus rapide de copier un seul fichier de 2Gb que 1000 fichiers totalisant 1Gb. Solution quand on doit copier plein de fichiers: zipper sur la machine source dans un seul fichier (éventuellement en mémoire en envoyant "à la volée"), faire la copie du zip, dézipper sur la machine destination. Au total c'est plus rapide (mais complexe, il faut des services qui se "parlent" entre eux sur les deux machines).

Copie de fichiers depuis un serveur sur plusieurs serveurs. Ne pas faire la copie serveur par serveur depuis le seul serveur source, mais en cascade. Dès qu'un serveur a reçu les fichiers, il peut devenir à son tour source pour d'autres serveurs (encore une fois c'est complexe, il faut des services qui se "parlent" entre eux sur les toutes les machines).

[Altess]

Bonjour.

Merci pour toutes ses informations. J'ai obtenue réponse à mon problème. Étant donné qu'il s'agit d'une copie locale, je calcul le temps estimé pour 50Mo (ça ne dépasse pas les 5s en général), puis j'en déduis le temps total nécessaire à la copie de la totalité de mes fichiers. Si ce temps est aux alentours des 3min, je lance la copie, sinon, je passe à la suite.

Merci de votre aide.