# Trou de memoire **URL:** \ **Category:** Pause Café\ **Created:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012 "2016-02-20T15:13:18Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![stonfi](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/54ee81/32.png) [@stonfi](https://www.debian-fr.org/u/stonfi)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/1 "2016-02-20T15:13:18Z")
hello, J’ai un fichier de 7G à transferet sur un reseau de 100M : 7100M/100M=71 Secondes c’est bien ça, ca me parait rapide ??? ---
**Author:** ![ggoodluck47](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/g/c67d28/32.png) [@ggoodluck47](https://www.debian-fr.org/u/ggoodluck47)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/2 "2016-02-20T15:13:18Z")
Salut, Le fichier fait 7100 Mo et le réseau 100 Mbits 😊 ---
**Author:** ![avision](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/a9a28c/32.png) [@avision](https://www.debian-fr.org/u/avision)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/3 "2016-02-20T15:13:18Z")
c’est 100Mb (b=bits) faut diviser par 8 😃 ---
**Author:** ![stonfi](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/54ee81/32.png) [@stonfi](https://www.debian-fr.org/u/stonfi)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/4 "2016-02-20T15:13:18Z")
Oui, Ca donne 7100/100\*8=568 secondes / 60 = 9,466666667 Minutes c’est ça ?? ---
**Author:** ![avision](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/a9a28c/32.png) [@avision](https://www.debian-fr.org/u/avision)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/5 "2016-02-20T15:13:19Z")
edit je dis nimporte quoi moi 😆 oui c’est ca, mais c’est théorique… ca durera plus longtemps ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/6 "2016-02-20T15:13:19Z")
Si le transfert se fait de manière optimal, un hdparm te donnera le débit du disque dur. Celui ci sera entre 25Mo/s et 50Mo/s donc ça ne doit pas limiter. Après, tu peux avoir des erreurs réseaux, etc. Compte un temps de 15-20 minutes en gros. ---
**Author:** ![BorisTheButcher](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/d6d6ee/32.png) [@BorisTheButcher](https://www.debian-fr.org/u/BorisTheButcher)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/7 "2016-02-20T15:13:19Z")
7Go=7_1024 Mo = 7_1024_8 Mbits Sur du 100Mega bits (attention Megabits par seconde vaut 1000bits par seconde, pas 1024) 7_1024\*8/100=573.44s=9mn33.44s Mais vu que 100MegaBits c’est le débit ethernet, tu peux enlever les entetes. En gros tu dois arriver à 70/80% données utiles des 100Megabits (ca se calcule, j’ai pas ca en tete). Tout depend de comment les 2 liens sont configurés au niveau tcp/ip. Donc probablement 573.44s\*1.3=12mn A la louche… Si tu restes sur le meme segment ethernet et que tu es seul sur ce segment ethernet (pas de routeur en jeu) et en tcp/ip: 7go=5027 trames de 1460 octets (1500 pour ethernet -entete ip -entete tcp) + 500 trames d’acquitement de 1 octet 7_1024_1024/1460=5027 5027\*1460+500=7339920 \*8/100000 9mn46s minimum 🙂 ---
**Author:** ![barbak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/49beb7/32.png) [@barbak](https://www.debian-fr.org/u/barbak)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/8 "2016-02-20T15:13:20Z")
euh dites moi un truc… ca sert à quoi vos calculs ??? c’est vrai que d’un point de vue théorique c’est sympa de le savoir, mais d’un point de vue pratique (et pour parodier un peu coluche) le temps que vous pensez à calculer le temps de transfert, c’est du temps que vous passez pas à transferer 😆 ---
**Author:** ![avision](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/a9a28c/32.png) [@avision](https://www.debian-fr.org/u/avision)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/9 "2016-02-20T15:13:20Z")
Sans etre zélé comme Boris c’est qd meme pratique d’avoir une estimation a la louche. En plus les gens oublient souvent la différence entre le Mbits utilisé pour les transfères et le Mo pour le stockage. En anglais le MByte est utilisé pour Mo d’ou la confusion tant a l’oral qu’a l’écrit. Normalement il y a differenciation par MB/Mb mais ca n’est pas tres respecté. Ajoutes a ca les 1024 au lieu des 1000 et tu as le combo des confusions. ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/10 "2016-02-20T15:13:20Z")
[quote=“barbak”]euh dites moi un truc… ca sert à quoi vos calculs ??? c’est vrai que d’un point de vue théorique c’est sympa de le savoir, mais d’un point de vue pratique (et pour parodier un peu coluche) le temps que vous pensez à calculer le temps de transfert, c’est du temps que vous passez pas à transferer 😆[/quote] 50 machines à cloner avec auparavant les partitions Windows à sauvegarder. 1. Vaut il mieux compresser avec de transférer ou transférer directement? 2. Vu le travail qu’il y a à faire sur chaque machine après, vaut il mieux lancer les 50 machines pendant la nuit (est ce que ce sera fini?) ou faire des lots de 5? de 10? 3. Le tout doit être prêt dans 2 jours? Puis je aller dormir la nuit? Bref, autant de raisons incitant à estimer même à la louche le temps mis. Et je te prie de croire que dans un tel cas, tu vérifies que tu n’as pas bêtement oublié le DMA sur une machine (temps multiplié par 5) ou que tu n’as pas utilisé par mégarde cette vieille daube de Hub 10Mb/s… ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/11 "2016-02-20T15:13:20Z")
Un de mes premiers exos de temps réel consistait à préconiser une architecture permettant de synchroniser des To de données toutes les nuits entre deux sites administratifs. La seule solution avec les critères géographiques qui étaient donnés et pouvant respecter les critères était la sauvegarde sur support rapide, et le transport de ces supports par camion, en parallèle dans les deux sens. C’est ça le temps réel: on a une contrainte, il faut se garantir qu’elle est respectée. ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/12 "2016-02-20T15:13:21Z")
Ne pas sous estimer la bande passante d’un camion rempli de disquettes (ou de CDs)! ---
**Author:** ![avision](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/a9a28c/32.png) [@avision](https://www.debian-fr.org/u/avision)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/13 "2016-02-20T15:13:21Z")
Il a dit "sauvegarde sur support rapide" Tres drole comme histoire en tout cas 😆 ---
**Author:** ![barbak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/49beb7/32.png) [@barbak](https://www.debian-fr.org/u/barbak)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/14 "2016-02-20T15:13:21Z")
c’est vrai que vu sous cet angle… 😲 tout de suite avec l’exemple de fran.b et de Matt on comprend mieux l’utilité de la chose. et au fait fran.b … dans ton exemple, le mec il peut aller dormir ou pas 😆 > [@](#): > > En plus les gens oublient souvent la différence entre le Mbits utilisé pour les transfères et le Mo pour le stockage oui c’est vrai que beaucoup de personnes tombent dans le panneau. et la difference entre giga-octet et gibi-octet c’est un peu la même chose… ---
**Author:** ![BorisTheButcher](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/d6d6ee/32.png) [@BorisTheButcher](https://www.debian-fr.org/u/BorisTheButcher)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/15 "2016-02-20T15:13:21Z")
Moi zélé? Naaan En fait ca m’a interessé plusieurs fois de calculer ce genre de truc. Ca devient important quand on veut fixer sa MTU (pour le net). On se rend compte que la mettre à 1400 est un bon compromis. Sinon en transport il y a aussi ca, avec QoS: [ietf.org/rfc/rfc2549.txt](http://www.ietf.org/rfc/rfc2549.txt) 😆 ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/16 "2016-02-20T15:13:22Z")
[quote=“barbak”]c’est vrai que vu sous cet angle… 😲 tout de suite avec l’exemple de fran.b et de Matt on comprend mieux l’utilité de la chose. et au fait fran.b … dans ton exemple, le mec il peut aller dormir ou pas 😆 [/quote] Ben le mec c’était moi et oui, il a pu dormir en laissant en batterie 30 machines executant des scripts de transfert de partition. Le choix a été de compresser avant transfert sur le réseau. La journée du lendemain a été pénible parce que l’une des machines «serveur» qui recueillait les images des partitions windows n’avait pas le DMA activé… et ça s’est vu. Boris: pourquoi 1400 est mieux que 1500? ---
**Author:** ![BorisTheButcher](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/d6d6ee/32.png) [@BorisTheButcher](https://www.debian-fr.org/u/BorisTheButcher)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/17 "2016-02-20T15:13:26Z")
[quote=“fran.b”] Boris: pourquoi 1400 est mieux que 1500?[/quote] J’ai dit ca moi? 😆 Oulaaa Sans rentrer dans les details, euh c’est pas lié a ethernet donc (mtu) mais je me rappele que pr pppoe je desactivais le PMTU discovery (en fonction de si les icmp sont filtrés comme expliqué ici en fluo [christian.caleca.free.fr/pppoe/mtu\_mss\_etc.htm](http://christian.caleca.free.fr/pppoe/mtu_mss_etc.htm) ) et ensuite la question c’est pourquoi 1400 et pas 1492 (pppoe) et c’est une bonne question. Je crois que certains equipements ont des limites inferieures. Pu ca en tete non plus 🙂 Pour stonfi en tout cas, ca lui servira pas ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/18 "2016-02-20T15:13:28Z")
Mais non, je crois même que c’est toi qui me l’avait expliqué, si j’ai bien vaguement compris c’est à cause du passage des paquets par des coins ou ils ont une encapsulation supplémentaire. Si à la base ils sont à la limite de taille de fragmentation, ils sont forcément fragmentés dés que tu rajoutes une encapsulation, et c’est pour ça qu’on prend un MTU nettement en dessous des 1492 pour qu’ils puissent être encapsulés sans être fragmentés… ---
**Author:** ![BorisTheButcher](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/d6d6ee/32.png) [@BorisTheButcher](https://www.debian-fr.org/u/BorisTheButcher)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/19 "2016-02-20T15:13:30Z")
Oui oui c’est sur que c’est mieux de le diminuer donc inferieur à 1492 et probablement aussi de desactiver le path mtu discovery. La question c’est quelle valeur mettre. Je crois que c’etait 1400 pour la MSS donc 1440 pour la mtu. Ca depend de la connexion et il faut refaire le pmtu ‘manuellement’ (en gros la mettre plus basse), il n’y a aucun calcul qui n’intervient à ce moment là. Dans certains cas cette modif empeche d’acceder à certains sites (mtu=500 par ex), donc c’est un compromis. ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 3:13 UTC](https://www.debian-fr.org/t/trou-de-memoire/5012/20 "2016-02-20T15:13:32Z")
[quote=“BorisTheButcher”]Oui oui c’est sur que c’est mieux de le diminuer donc inferieur à 1492 et probablement aussi de desactiver le path mtu discovery. La question c’est quelle valeur mettre. Je crois que c’etait 1400 pour la MSS donc 1440 pour la mtu. Ca depend de la connexion et il faut refaire le pmtu ‘manuellement’ (en gros la mettre plus basse), il n’y a aucun calcul qui n’intervient à ce moment là. Dans certains cas cette modif empeche d’acceder à certains sites (mtu=500 par ex), donc c’est un compromis.[/quote]Non, la méthode que j’avais trouvée pour optimiser mon mtu était de faire soit même le pmtu discovery en mettant un flag ipnodefrag et en faisant un ping avec des paquets de plus en plus petit: tant que les paquets sont trop gros, ils sont droppés au lieu d’être fragmentés, et quand ils passent enfin, c’est que tu as trouvé ton MTU. Ca marche aussi sous win même si ce ne sont pas les mêmes options de ping, mais ça doit se faire avec : ```auto ``` [Page suivante](https://www.debian-fr.org/t/trou-de-memoire/5012.md?page=2)