Pourquoi mon fichier réseau copie-t-il la vitesse d'une vague?

Avec la mise à niveau vers Windows 10, j'ai maintenant ce joli graphique lors de la copie de fichiers.

Lorsque je copie un seul fichier volumineux, la vitesse prend toujours cette forme d'onde raisonnablement cohérente. Qu'est-ce qui cause ça?

La connexion est

My PC <- cable -> gigabit switch <- cable -> Netgear ReadyNAS

Les fichiers sont copiés via SMB, ce graphique en montre une copie en une minute environ:

Il n'y a pas de problème ici, je veux juste comprendre comment les choses fonctionnent.

networking nas

— Gricey
source

Quelques informations supplémentaires sur la configuration du disque ReadyNAS seraient utiles. Utilisez-vous RAID 5 sur trois disques? Quelle est la vitesse d'écriture sur chaque lecteur? Quelle est la mémoire tampon sur chaque lecteur et y a-t-il un cache utilisé par ReadyNAS? Avez-vous essayé d'autres outils comme TeraCopy pour voir si vos taux de transfert diffèrent? Sinon, il pourrait y avoir un goulot d'étranglement lors de l'écriture du cache disque, en particulier si votre taux d'écriture n'est pas bon (Seagate Barracuda, par exemple).

— Sun

Avez-vous fermé tous les autres processus pouvant utiliser le NAS à intervalles?

— Arjan

Réponses:

Réponse courte: cache en écriture

TL; DR: Tout d’abord, la copie d’un seul fichier volumineux nécessite moins de temps système que la plupart des fichiers plus petits. Cela signifie que PC et NAS ne "gaspillent" pas beaucoup de temps à rechercher des fichiers, à mettre à jour des métadonnées de table de fichiers et de système de fichiers. Cela signifie également un débit beaucoup plus élevé, susceptible de révéler certains des goulots d'étranglement de la bande passante dans la configuration.

Les pics et les creux du graphique de bande passante semblent se produire à intervalles assez réguliers, et compte tenu du fait que vous copiez un seul fichier volumineux (bande passante maximale, surcharge minimale), je dirais que vous voyez l'effet de la mise en mémoire tampon / mise en cache .

Il me semble que vous envoyez probablement des données au NAS plus rapidement que vous ne pouvez les écrire sur le disque. Grâce à l'écriture en cache / mémoire tampon, il est toujours en mesure de le recevoir plus rapidement (les pics du graphique), mais vous ne pouvez pas continuer à recevoir des données sans les enregistrer sur le disque.

Finalement, la mémoire tampon sera pleine et devra être écrite sur le disque. Pendant ce temps, le NAS ne peut pas recevoir les données aussi rapidement qu’avant, car il n’a nulle part où les stocker (la mémoire tampon est pleine et les disques sont plus lents). C'est là que vous obtenez les vallées du graphique.

Il semble que Windows est en train de lisser le graphique de débit. Avec des graphiques plus précis (à partir de Performance Monitor, par exemple), vous pouvez estimer la taille de la mémoire tampon en écriture en analysant les intervalles et les octets transférés.

La raison pour laquelle les pics et les creux ne se produisent pas à des intervalles parfaitement uniformes est probablement parce que PC, NAS ou les deux font quelque chose de différent pendant la copie du fichier.

— abstrask
source

Cela ne donnerait-il pas une ligne horizontale avec des pics soudains (jusqu'à zéro) une fois que la mémoire tampon est pleine?

— Arjan

Le graphique de copie de fichier semble être lissé, probablement pour un appel visuel. PerfMon produirait probablement un graphique beaucoup plus précis. En outre, cela dépend de l’algorithme utilisé pour le vidage sur le disque - par ex. arrêtez de recevoir des données jusqu'à ce que tout soit écrit sur le disque plutôt que de limiter la réception de données à une vitesse plus lente, ce qui permet d'écrire sur le disque plus rapidement que la réception de nouvelles données.

— abstrask

Il est difficile de répondre avec autorité sans beaucoup d’enquêtes supplémentaires. Merci d'avoir mis à jour votre question avec l'échelle de temps et le protocole.

Il pourrait normalement "pétoncles" TCP. TCP va aussi vite que possible jusqu'à la perte de paquets. Ensuite, il recule un peu et redémarre. Donc, il continue de "cogner la tête contre le plafond". C’est ainsi qu’il maximise la bande passante disponible sans aggraver la congestion. Je regarde habituellement les pétoncles TCP dans un graphique TCPTrace, qui est un peu différent de ce graphique. Je m'attendrais à ce que cela ressemble un peu plus à une dent de scie dans ce genre de graphique, mais il peut y avoir un certain lissage dans ce graphique. Et maintenant que j'y pense, les pétoncles TCP se situeraient dans une échelle de temps beaucoup plus petite que ce que semble montrer ce graphique.

Il se peut également que votre protocole de système de fichiers distant (SMB) lise le fichier un morceau à la fois, et que les plongées correspondent à la fin de la lecture d’un morceau et à la demande du prochain.

— Spiff
source

Désolé pour le manque de détails, je n'étais pas sûr de ce que les gens auraient besoin de savoir. J'utilise qn et ce graphique couvre une période d'environ une minute

— Gricey

@ Gricey: Ne commentez pas cela: résolvez la question !!

— Lightness Races in Orbit

-1 pour le nitpicking inutile

— Mehrdad

@LightnessRacesinOrbit corrigé

— Gricey

@ Gricey, je m'excuse d'être si difficile en ce qui concerne les détails. Je comprends le sentiment que si vous ne savez pas de quels détails les gens vont avoir besoin, il est difficile de vouloir documenter un tas de choses. Il est difficile de documenter suffisamment pour que les personnes qui aident ne soient pas frustrées et de penser que vous perdez peut-être votre temps à documenter des choses qui ne comptent pas.

— Spiff

je pense Microsoft introduit cette fonction dans la barre de progression sous Windows 8.

De gauche à droite montre le progrès en pourcentage & amp; Up-down le mouvement montre la taux de transfert en Mo / s .

Les taux de transfert sont déterminés par la vitesse du support (BUS ou réseau), le nombre et l'intensité; taille des fichiers, système de fichiers & amp; disponibilité des ressources, etc ...

Également lors d'un transfert de fichier, un lot de métadonnées en lecture / écriture a lieu.

Vous constatez une onde raisonnablement cohérente, car cette surcharge de lecture / écriture de métadonnées est réduite & & amp; d'autres ressources sont utilisées au même rythme. Les baisses occasionnelles pourraient être les événements de perte de paquet, la prochaine lecture de bloc, l'interrogation de ressource, etc.

Pour plus de précisions, voici d'autres lectures

— pun
source

Cela ne répond pas vraiment à la question.

— Lightness Races in Orbit