J'ai une application qui copie une grande quantité de fichiers sur le réseau à un serveur de fichiers (non Web). J'essaie d'afficher une estimation de moitié décente du temps restant.
J'ai examiné un certain nombre d'articles de sorte que le problème n'est abordé aucun que je n'ai pas essayé vraiment de faire ce que je veux. Je veux que le temps estimé reste restant relativement stable I.e. Ne sautez pas autour de la place en fonction des vitesses de transfert fluctuants. p>
La première solution que j'ai examinée était de calculer la vitesse de transfert en octets par seconde p> double secRemain = (TimeTaken.TotalSeconds / totalBytesCopied) * (totalFileSizeToCopy - totalBytesCopied);
4 Réponses :
Vous voudrez probablement calculer l'estimation contre le taux de transfert moyen. Cela devrait aider à stabiliser l'estimation. Il y a une autre question qui pose la même question.
Cela pourrait être un APRACH
Calculez les octets / seconde lorsque les 25% du premier fichier ont été copiés
Utilisez ce calcul pour estimer le reste des 75% de la première opération de fichier
Chaque fois qu'un fichier a été copié magasin, dans une collection, la moyenne de la vitesse en octets / seconde pour chaque fichier copié.
Ensuite, vous pouvez utiliser la moyenne des éléments de la collection pour estimer l'heure de l'opération de copie pour les fichiers qui n'ont pas encore été copiés.
Faites-moi savoir si vous avez besoin de plus de détails ou d'APROCHES
Vous souhaitez calculer le taux basé sur le taux de transfert moyen, mais vous voulez que ce soit une moyenne mobile, car la vitesse du réseau est variable sur la durée de vie du transfert de fichier (en particulier pour les fichiers très volumineux). Voici la méthode JavaScript que j'ai proposée avec qui semble fonctionner bien (doit être facile à convertir en C #).
var rates = [];
var ratesLength = 1000;
for (var i = 0; i < ratesLength; i++)
rates[i] = 0;
/**
* Estimates the remaining download time of the file.
*
* @param {number} bytesTransferred: Number of bytes transferred so far.
* @param {number} totalBytes: Total number of bytes to be transferred.
* @return {string} Returns the estimating time remaining in the upload/download.
*/
function getSpeed(bytesTransferred, totalBytes) {
var bytes = bytesTransferred - oldBytesTransfered;
var time = currentTime - oldTime;
if ((time != 0) && (bytes != 0)) {
rates[rateIndex] = (bytes) / (time);
rateIndex = (rateIndex + 1) % rates.length;
var avgSpeed = 0;
var count = 0;
for (i = 0; i < rates.length ; i++) {
if (rates[i] != 0) {
avgSpeed += rates[i];
count++;
}
}
if (count == 0)
return " ";
avgSpeed /= count;
return (humanReadableTime((totalBytes - bytesTransferred) / avgSpeed) + " remaining");
} else {
return " ";
}
}
Voici un exemple de travail de la manière dont vous allez copier asynchroneusement un fichier de ces données, je prends simplement le taux de transfert moyen de 30 instantanés (le plus récent en premier). De cela, je peux calculer une estimation approximative de la durée de la durée pour transférer le reste du fichier. Cet exemple est fourni tel quel et ne prend pas en charge la copie de plusieurs fichiers en 1 opération. Mais cela devrait vous donner des idées. d: \ dummy.bin à d: \ dummy.bin.copy.copy , avec une minuterie prenant des instantanés du taux de transfert chaque seconde.
Vous voudrez peut-être également considérer que chaque fichier pourrait venir avec un délai de décalage par fichier - pour ouvrir un flux et créer un nouveau fichier quelque part. Faire-t-il plus de temps pour copier un million de fichiers 1 Ko, que pour copier un fichier de 1 Go?
Est-il possible pour vous de montrer une barre de progression avec «Copie 1 de XXX»?
lien Ceci est que vous voudrez peut-être.
@Shellshock Oui Absolument, mais il doit y avoir un moyen de calculer cela et de stabiliser le résultat pour donner une estimation approximative de la quantité de plus longue du transfert total.
Supposons que votre matériel réseau soit déjà sous la charge maximale lorsque vous démarrez le transfert et que la formule indique qu'il prendra 2 heures pour compléter le transfert de fichier. Maintenant, après les 10 premières minutes, le processus qui collant vos ressources de vos ressources et que le reste de votre transfert de fichier ne prendra que 5 minutes de plus. Que voulez-vous que la minuterie indique? Répétez la même expérience de pensée pour 20, 30, 40, ... minutes dans le transfert de fichier.
Ma conclusion est que vous devez baser votre formule sur uniquement les vitesses de transfert les plus récentes. Par exemple, vous pouvez mesurer la vitesse de transfert chaque seconde, puis utiliser la moyenne des 10 dernières secondes pour calculer le temps restant.
Si cela ne fonctionne pas, le problème est probablement lié au fait que la plupart du temps ne consacre pas à envoyer le contenu du fichier, mais plutôt les frais généraux.
@Stevenliekens ok je serai honnête, je devais dire que je reçois tout ça! Je comprends que je ne peux pas compter sur la congestion du réseau, la charge du serveur, etc., mais mes tentatives jusqu'à présent étaient calculées à chaque fois que le filtream a écrit un bloc au chemin de destination. Cela signifie que c'est recalculer chaque 0,2 seconde et donc pourquoi c'est si erratique. Ainsi, en utilisant votre suggestion et que vous apportez la filecompte à compenser d'une manière ou d'une autre, les frais généraux pourraient-ils laisser un peu les choses?
D'accord, alors si vous avez seulement affiché l'estimation une fois en 5 secondes? Ou si vous entendiez la valeur résultante?
@Fred j'ai utilisé 10 secondes à titre d'exemple, mais c'est à vous de décider. Plus le tableau horaire est long, plus votre minuterie sera la transition, mais plus elle prendra plus longtemps que votre minuterie répondra à des changements dramatiques. Supposons que vous tirez le câble réseau. Il faudrait 10 secondes avant que votre minuterie n'indique enfin qu'il faudrait une quantité infinie de temps pour compléter le transfert (à une moyenne de 0 octets / s).
@Fred, je reçois un bon équilibre entre stabilité et précision lorsque je teste avec une moyenne calculée à partir de 1 à 30 mesures les plus récentes, 1 mesure par seconde.