Journal De la capacité d'un lien Ethernet

Posté par .
Tags : aucun
25
31
déc.
2010
Bonjour chers amis.

Comme c'est vendredi, j'en profite pour écrire un journal culturel.

On lit un peu partout à gauche et à droite qu'une liaison 100Mbps que l'on a tous chez soi (sauf au WC où on utilise le Wifi) est capable de supporter un débit théorique de 12.5Mo/s. J'imagine que les auteurs de ces lignes ont naïvement calculé que l'octet étant traditionnellement valorisé à 8 bits, il suffisait de faire une petite division pour obtenir le débit en Mo/s.

Seulement voila, en réalité, dans 100Mbps, vous vous doutez bien que selon une tradition marketing largement établie, on prends la valeur la plus élevée, soit la fréquence de transmission des informations. En réalité, d'après Wikipedia, une liaison 100Mbps est en réalité une liaison à 25 MHz qui transferts les bits 4 par 4 [1]. Il s'agit donc du débit le plus brut possible, et non pas le débit auquel on va pouvoir transférer ses petits (ou gros) fichiers (En réalité en 100BASE-TX on ajoute des bits pour avoir un signal plus facile à transmettre, la fréquence physique sur le cable est donc un peu plus élevée).

Il est temps de lister les lignes que l'on a sur la facture:

Premièrement, l'accès à la ligne ne doit pas se faire n'importe comment. La norme impose un délais de 12 octets entre deux trames [2].
Rentrons dans la trame ethernet: [3] Elle est composée d'un préambule de 8 octets de valeurs constantes, de 14 octets d'entête (adresses et taille), des données pour un maximum de 1500 octets, et de 4 octets de CRC.

Bilan: Ethernet 38 octets de taxe sur 1538

On continue a remonter les couches OSI comme à l'école, et on tombe sur IP. Pour éviter de vous faire coucher tard, nous négligerons l'impact de la résolution ARP.

Hopla, trame IPv4 de 1500 octets:
20 octets d'entête (version cheap) [4].

Continuons, en remontant on a UDP et TCP. Selon ce que vous utilisez, ce sera l'un ou l'autre. En dehors de NFSv3, je pense que tous les autres protocoles utiliseront TCP (FTP, HTTP, SSH, SMB/CIFS, NFSv4...).

Chez UDP, la facture est de 8 octets [5], mais en TCP on a le droit à une taxe plus importante: 20 octets [6].

On va abandonner là le calcul pour le cas UDP, parce que je ne sais pas calculer le coût des couches supérieures.

Pour TCP, on va calculer le total en négligeant la facture des couches supérieures, une réponse HTTP contient souvent 300 à 400 octets d'entête, ce qui est négligeable à coté d'un fichier de 1Mo. Les entêtes ne sont pas répétés dans chaque paquet.

Au final, pour une fenêtre temporelle de 1538 octets, nous avons 1480 octets d'octets utiles, ce qui donne un taux utile de 96.2%, soit un débit maximal d'environ 96.2Mbps ou encore 12Mo/s et non pas 12.5Mo/s.

Voila, la vérité devait être rétablie.

[1] http://en.wikipedia.org/wiki/Fast_Ethernet#General_Design
[2] http://en.wikipedia.org/wiki/Ethernet_frame#Interframe_gap
[3] http://en.wikipedia.org/wiki/Ethernet_frame#Structure
[4] http://en.wikipedia.org/wiki/IPv4#Packet_structure
[5] http://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_s(...)
[6] http://en.wikipedia.org/wiki/Transmission_Control_Protocol#T(...)
  • # Regrets

    Posté par (page perso) . Évalué à  9 .

    Qu'est ce que je regrette le temps où des fils passaient partout chez moi, j'avais au moins un débit de 12Mo/s....

    Maintenant avec le Wifi, je me traine à 3Mo/s et je dois attendre la fin de mon transfert pour allumer mon micro-onde pour ne pas risquer la coupure de connexion...

    Les fils, c'était vraiment un mal pour un bien...
    • [^] # Re: Regrets

      Posté par . Évalué à  4 .

      bein recable non ?
      Chez moi c'est tout cablé et ca marche du feu de dieu. Bon ok j'ai fait passer les cables dans les murs.

      Sinon y a ca aussi : http://www.ldlc.com/fiche/PB00096471.html

      Mais je sais pas ce que ca donne en therme de débit utile. En tous cas ca peut pas etre pire que le wifi si bien en terme de débit qu'en terme de sécurité.
      • [^] # Re: Regrets

        Posté par (page perso) . Évalué à  4 .

        bein recable non ?

        On voit que tu n'es pas marié toi...

        Bon ok j'ai fait passer les cables dans les murs.

        Ah zut, peut-être que si :).
        Faut que je me motive à faire la même chose, depuis que je suis passé au WiFi pour faire plaisir à madame, je pleure le débit (ah le bon vieux Gigabit Ethernet, il me manque)
        • [^] # Re: Regrets

          Posté par . Évalué à  1 .

          "On voit que tu n'es pas marié toi..."
          Des fois au contraire, la femme n'est pas contente du wifi car ça perturbe le micro-ondes, et la télé qui utilise un transmetteur sans fil. Comme quoi... :)
          • [^] # Re: Regrets

            Posté par . Évalué à  3 .

            Vous êtes surs qu'ils vont bien vos fours micro-ondes ? Je viens de faire l'essai en téléchargeant linux-2.6.32.2.tar.bz2 (70 Mo) avec le four micro-ondes au maximum placé entre le portable et la box, et ça marche... Je perds 10 % en débit (pas la mort quoi) et la somme de contrôle est correcte.

            Je me rappelle un numéro de 60 Millions de consommateurs qui mettaient en garde contre les micro-ondes mal fichus qu'avaient des fuites...
          • [^] # Re: Regrets

            Posté par . Évalué à  4 .

            Le wifi perturbé par le microonde, je veux bien l'admettre à la limite. Mais l'inverse me semble étrange.

            Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

            • [^] # Re: Regrets

              Posté par . Évalué à  1 .

              Vous me faites douter, je ne me rappelle plus bien, peut-être qu'en fait le micro ondes influençait le transmetteur de la télé, mais l'impact le plus visible du wifi était sur la télé à cause du transmetteur.
              • [^] # Re: Regrets

                Posté par . Évalué à  1 .

                Moi aussi j'avais un wifi perturbé par le four à micro-ondes. Après pas mal de recherches, j'en ai conclu deux choses :
                - dans un premier temps, tester d'autres fréquences wifi (chez Free c'est assez simple, dans configuration wifi, changer le canal qui est par défaut sur le canal 11), premier problème à court terme résolu.
                - dans un second temps, se méfier de son four à micro-ondes parce qu'effectivement, un four qui fuit c'est pas bon signe du tout... et c'est plutôt sur le long terme que ça se chope, un cancer. Les résultats d'expériences sur des rats exposés à des micro-ondes en petites quantités (telle une grosse fuite de four) sont moches, très moches.
                • [^] # Re: Regrets

                  Posté par (page perso) . Évalué à  10 .

                  Les résultats d'expériences sur des rats exposés à des micro-ondes en petites quantités (telle une grosse fuite de four) sont moches, très moches.

                  Les résultats étaient écrits en Comic Sans?

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Femme parfaite

          Posté par . Évalué à  6 .

          héhé si je suis marié mais avec une femme parfaite

          L'autre jour elle veux changer de distribution (oui elle est sous linux) je me pointe avec les cd ... " non pousse toi c'est moi qui fait je veux apprendre, mais reste à a coté tu vas m'aider j'ai peur de faire une betise." :D Je l'aiiiiiiiime

          Sinon pour le cable, je proposais d'utiliser des boitiers cpl. Petit, discret, efficace. Les boitiers que je te propose sont censé etre 200Mb compatible. alors avec un réseau 10/100 ca doit le faire. En tout cas ca doit etre bien plus rapide que le wifi.

          Sinon pour les cables ethernet en plein milieu du salon ca m'arrive des fois et c'est au bout de deux semaines que j'ai droit à un ... "hmm tu penses que ca va rester encore longtemps ? " avec un petit air triste. Donc je m'arrange pour les retirer rapidement quand même mais bon ..... Parfaite je vous disais ... parfaite .

          :D
          • [^] # Re: Femme parfaite

            Posté par . Évalué à  3 .

            Femme parfaite, femme parfaite. C'est vite dit. Prendre des CD pour installer un OS, c'est n'importe quoi. Quand on a un réseau rapide, on installe bien plus vite via le réseau. Et sinon un stick usb reste bien plus performant qu'un horriblement lent et bruyant lecteur cd.
            • [^] # Re: Femme parfaite

              Posté par . Évalué à  3 .

              Un jour j'ai voulu installer un Windows 7 par réseau. Et j'ai été effaré qu'il faille télé-charger une collection d'outil distribuées sous la forme d'un iso de 800 Mo, juste pour pouvoir préparer une image. Oui les 800 Mo n'incluent pas de serveur TFTP, et les outils ne fonctionne que sous Windows, donc c'est un serpent qui se mort la queue si l'OS n'est pas déjà installé.

              Alors j'ai voulu tenter la solution clef-usb : Mis à part que l'outil ne tourne que sous windows, celui ci veut obligatoirement détruire le contenu de ma clef, au revoir. Ça fait 20 ans que le concept de "partition" existe, mais chez MS ça doit être encore tout nouveau.

              Quand je pense à ceux qui doivent se farcir l'administration de tout ça toute la journée ...
    • [^] # Re: Regrets

      Posté par . Évalué à  8 .

      +1 pour la solution ethernet.

      Voici mon classement entre les 3 grandes technos du moment selon divers critères, basé sur mes propres expériences (wifi : diverses solutions avec le temps, CPL : 2 essais avec du CPL sans marque, puis avec les trucs de chez Free, à chaque fois prêtés pour un week-end).

      Prix de revient
      1er - ethernet (bien loin devant tout le monde)
      2e - wifi
      3e - CPL

      Débit
      1er - ethernet (je fais réellement du 10Mo/s entre mon ordi dans la chambre et mon serveur de disque dans le garage)
      2e - wifi
      3e - CPL (j'ai fait 2 essais avec un CPL sans marque, puis avec un CPL de chez Free : débits ridicules dans les 2 cas)

      Fiabilité de la connexion
      1er ex-aequo : ethernet / CPL
      3e : wifi

      Facilité de mise en oeuvre
      1er : CPL (rien à faire)
      2e : wifi (il y a des clés à établir, un SSID à choisir, un canal à choisir éloigné de celui de ses voisins...)
      3e : ethernet (faut juste pêter les murs...)

      Sécurité
      1er : ethernet
      2e : CPL (je l'ai pas mis 1er car il parait que des fois éventuellement ça peut passer au-delà du compteur, + les ondes émises peuvent être captées et analysées... mais c'est vraiment une considération théorique)
      3e : wifi

      J'ai la chance d'habiter une maison où les combles sont accessibles (fermettes), et l'espace entre le mur et le placo permet facilement de glisser un cable reseau. Après 2 journées dédiées à ça, j'en suis à avoir cablé toutes les chambres, reste salon + cuisine (mais vu qu'il n'y a aucun appareil ethernet dans ces pièces pour l'instant... rien ne presse).
      • [^] # Re: Regrets

        Posté par (page perso) . Évalué à  1 .

        Tu as oublié de parler du coût au mètre. Et dans ce cas, je placerais:

        1. Ethernet
        2. CPL
        3. WiFi

        Parce qu'à partir du moment où il a des étages, le WiFi n'est pas bon du tout. Après, pour le CPL ça dépend du réseau électrique.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Regrets

        Posté par (page perso) . Évalué à  1 .

        Nocitivité en terme d'ondes:
        1° CPL
        2° Wifi
        3° Ethernet
        • [^] # Re: Regrets

          Posté par (page perso) . Évalué à  10 .

          [reference needed]

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Regrets

            Posté par . Évalué à  3 .

            Oui, reference needed parce que je veux bien croire que le CPL balance des ondes (vu que les fils électriques ne sont pas blindés), mais de là à ce que ce soit pire que le wifi (qui, lui est prévu pour balancer des ondes)...
            • [^] # Re: Regrets

              Posté par . Évalué à  0 .

              http://www.greenit.fr/article/materiel/reseau/cpl-attentions(...) pour le plus alarmiste que j'ai trouvé
              mais en cherchant un peu on trouve plein d'articles sur le net
              • [^] # Re: Regrets

                Posté par . Évalué à  4 .

                j'ai commencé à lire, mais il enfonce des portes ouvertes et confond un certain nombre de choses :
                si le CPL est interdit sur certains sites, ce n'est pas forcément pour la pollution électromagnétique "aérienne" mais pour les parasites qui pourraient (par exemple) remonter à travers l'alimentation de certains appareils.

                Quant au paragraphes sur les limites d'émissions et de santé des émissions radio, on devrait indiquer à ce cher monsieur quel est la puissance d'une station BTS ou autre ...

                Les normes de santé dépendent de l'environnement (pro ou pas), de la fréquence etc...

                Bref cet article ne m'a pas du tout convaincu
              • [^] # Re: Regrets

                Posté par . Évalué à  4 .

                Je vote comme gbetous. Les articles de Wikipédia n'ont même pas de mention des effets sur la santé, alors qu'on s'attendrait à une controverse acharnée s'il y avait un doute sérieux. Déjà que pour les téléphones portables les études ne sont pas claires (et il faut avoir l'antenne à 1 cm de sa tête pendant des heures par jour pour avoir un effet mesurable)... Et l'émission résiduelle par des câbles qui passent dans le mur doit être nettement plus faible.
                • [^] # Re: Regrets

                  Posté par . Évalué à  5 .

                  surtout que l'émission du 50 Hz de ces cables je vous raconte pas sa puissance ;)
                  • [^] # Re: Regrets

                    Posté par . Évalué à  3 .

                    Bon je me suis pris un 0, je suppose que mon lien n'a pas plu, trop alarmiste pour être crédible surement.

                    Perso, et à mon grand regret, je n'y connais pas grand chose, donc je me permet de ramener mon avis ;)

                    Le défaut du cpl semble être sa proximité (nos murs), et le fait que les fils électriques nous englobent. Néanmoins il me semble qu'un rayonnement est dangereux s'il il est ionisant, et plus la fréquence est importante, plus le rayonnement est ionisant. Donc à partir de là:

                    cpl (3 à 30 MHz selon wikipedia) est moin dangereux que le wifi (2,4Ghz, qui est de plus la fréquence de résonance de l'eau) à puissance d'émission égale

                    Bon donc vu que j'ai surement dis une connerie dans cette reflexion des plus basique, je veux bien qu'on me corrige, ne serait ce que pour ma culture G
                    • [^] # Re: Regrets

                      Posté par . Évalué à  3 .

                      dans le principe, d'après mes maigres connaissances en rf, tu as raison.
                      Mais ça serait trop simples, il faut voir les fréquences d'absorption et l'effet desdit fréquences in vivo.

                      Certaines fréquences sont très vite arrêtées par l'air ou l'eau, et donc ne pénètre pas forcément le corps humain. Elles sont donc moins dangereuses que des fréquences qui pourraient être plus basses.
                    • [^] # Re: Regrets

                      Posté par (page perso) . Évalué à  3 .

                      Il me semble que tu oublie la puissance d'émission qui est auss un facteur à prendre en compte.

                      2,4Ghz, qui est de plus la fréquence de résonance de l'eau

                      Non, ce n'est pas la fréquence de résonnance de l'eau, c'est une fréquence qui fait « bouger » les molécules d'eau assez vite pour qu'elles chauffes mais ce n'est pas du tout leur fréquence de résonnance qui est beaucoup plus élevée.

                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                      • [^] # Re: Regrets

                        Posté par . Évalué à  2 .

                        Il me semble que tu oublie la puissance d'émission qui est auss un facteur à prendre en compte.

                        En effet, mais j'ai pas trouvé dans ma rapide recherche les chiffres pour le cpl (ou plutôt j'ai trouvé trop de chiffres différents, mais je suppose que ça doit être normé quelque part), c'est pour ça que j'ai précisé à puissance égale.

                        Non, ce n'est pas la fréquence de résonnance de l'eau, c'est une fréquence qui fait « bouger » les molécules d'eau assez vite pour qu'elles chauffes mais ce n'est pas du tout leur fréquence de résonnance qui est beaucoup plus élevée.

                        autant pour moi
                      • [^] # Re: Regrets

                        Posté par . Évalué à  1 .

                        Rappelons également que 2,4GHz n'est pas la fréquence truc, mais une fréquence proche. Les effets des ondes sur les molécules sont non linéaires. Si l'eau s'échauffe à 2 432 456 768 Hz, à 2 430 000 000 Hz, il ne se passera plus grand chose de spécifique.

                        Du coup, il suffit, en restant dans la bande autorisée, d'être décalé d'une grosse poignée de MHz par rapport à la fréquence truc pour qu'en plus d'avoir une puissance à mourir de vieillesse avec d'avoir fait cuire un oeuf de caille, il n'y ait aucun effet particulier.
                        • [^] # Re: Regrets

                          Posté par (page perso) . Évalué à  5 .

                          Un petit article:
                          http://fr.wikipedia.org/wiki/Four_%C3%A0_micro-ondes#Action_(...)

                          Je resume: Si le micro onde ne chauffe pas a exactement la frequence de l'eau, c'est pas juste pour faire joli. C'est parce si tu envoies a la frequence de resonnance de l'eau, tu te retrouves a ne chauffer qu'en surface. Si tu baisses trop en frequence (jusqu'a 1GHz), ton aliment ne va au contraire absorber aucune onde et ne pas chauffer.

                          La frequence 2,4GHz resulte donc d'un compromis pour que l'aliment chauffe en profondeur et absorde tout de meme la puissance emise.

                          Donc dire que si l'on s'ecarte un chouia de la frequence 2,4 GHz, il ne se passe rien, c'est juste faux. Tu vas juste cuire differement, mais tu vas tout de meme réagir.
                          • [^] # Re: Regrets

                            Posté par . Évalué à  1 .

                            la fréquence de résonnance de l'eau n'est PAS de 2.5Ghz, ni même approchant.

                            C'est une fréquence qui permet de chauffer l'eau, mais ce n'est pas celle de résonnance de l'eau.

                            http://www.howeverythingworks.org/page1.php?QNum=1456 [trouvé à partir de wikipedia en]

                            De plus dans la page anglaise de wikipedia on peut lire :
                            Moreover, large industrial/commercial microwave ovens operating at the common large industrial-oven microwave heating frequency of 915 MHz - wavelength 328 millimetres (12.9 in) - also heat water and food perfectly well.
      • [^] # Re: Regrets

        Posté par (page perso) . Évalué à  10 .

        Moi j'ai un autre classement:

        Prix de revient, débit, Fiabilité de la connexion, Facilité de mise en oeuvre, Sécurité
        1er largement: loopback
        2ième (loin derrière): les autres
        • [^] # Re: Regrets

          Posté par . Évalué à  2 .

          Rigole pas, j'ai déjà eu un problème avec l'interface loopback qui ne se monte pas (ma première tentative avec Ubuntu Serveur).

          http://ubuntuforums.org/showthread.php?t=1458456

          Depuis j'ai résolu mon problème : réinstallation complète d'une Ubuntu plus récente (10.04 LTS)
      • [^] # Re: Regrets

        Posté par (page perso) . Évalué à  2 .

        Je rajouterais comme critères la latence et la montée en nombre de clients (dans le cas d'Ethernet, on résout ça facilement avec des switchs). Je ne sais pas trop comment se comporte le CPL mais dans ces deux cas Ethernet est loin devant le wifi.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Regrets

      Posté par . Évalué à  2 .

      Une solution qui marche pas mal c'est le wifi N en le forçant à 5GHz (tous les routeurs, AP et carte 802.11N ne le supportent toutefois pas, il faut des dual bande).

      C'est ce que j'utilise chez moi et j'arrive à monter à un peu plus de 10Mo/s, alors que sur la bande 2,4GHz ou mixte 2,4/5GHz j'ai des débits de quelques centaines de ko/s à peine car il y a énormément de réseaux autour de chez moi, sur la bande 5GHz je dois être quasiment tout seul :-)

      Je pense que ça doit résoudre les problèmes de certains avec les micro-ondes et les transmetteurs vidéo sans fil. L'inconvénient c'est qu'on perd la possibilité d'utiliser tous les appareils n'ayant que du b ou du g.
  • # Ben quoi ?

    Posté par (page perso) . Évalué à  2 .

    Il y a bien 100 millions de bits qui circulent par seconde, et ceux qui ne contiennent pas l'information de l'application servent quand même à acheminer les données. Quand tu envoies un paquet par la poste, tu penses pouvoir retirer le poids de l'emballage pour calculer le prix des timbres ?

    C'est un peu pareil que ceux qui achètent un disque dur de 100 Go et qui vont se plaindre que Windows n'affiche que 99,2 Go de libres (valeur complètement arbitraire, je ne sais même pas si les disques durs de 100 Go existent).

    Pour les réseaux ethernet ou wifi, en général pour avoir à la louche le débit "application" en octets, tu prends le débit nominal en bits et tu divises par 10. C'est relativement proche de ce que tu obtiens.
    • [^] # Re: Ben quoi ?

      Posté par . Évalué à  0 .

      "C'est un peu pareil que ceux qui achètent un disque dur de 100 Go et qui vont se plaindre que Windows n'affiche que 99,2 Go de libres (valeur complètement arbitraire, je ne sais même pas si les disques durs de 100 Go existent)."
      Je pense que ce problème vient de la confusion entre les préfixes 1000 et 1024 entretenue par l'OS en question (http://fr.wikipedia.org/wiki/Fichier:%C3%89crit_Go_au_lieu_d(...) )
      • [^] # Re: Ben quoi ?

        Posté par . Évalué à  2 .

        Ca vient (je pense) et du fait que les constructeurs comptent en puissance de dix alors que le stockage est en puissance de 2 et du fait qu'une partie de l'espace sera reservée pour le système de fichier lui-même.
        • [^] # Re: Ben quoi ?

          Posté par (page perso) . Évalué à  1 .

          non non, je parle bien de puissances de 10, même si Windows affiche en puissances de 1024.

          Je parlais de la confusion entre la taille brut d'un support de stockage, et de la place restante disponible sur un système de fichiers fraîchement formaté. Les méta-données (inodes ou FAT, liste de blocs libres, répertoires) ne sont pas considérées comme de la place occupée sur le disque, pourtant il y en a besoin. Une fois ces méta-données créées, la place libre est diminuée par rapport à l'espace physique du disque.
          • [^] # Re: Ben quoi ?

            Posté par . Évalué à  2 .

            La perte à cause méta données est négligeable comparée à la pseudo-perte à cause de la confusion 1000/1024

            100 "Go" fait 93 "Gio" http://www.google.fr/#hl=fr&q=100+*+10^9+bytes+in+gibiby(...)
            Les méta données ne représentent certainement pas 7 Go (7% de "perte" simplement à cause d'un affichage incorrect)
            (http://fr.wikipedia.org/wiki/Pr%C3%A9fixe_binaire#Tableaux_d(...) )
            • [^] # Re: Ben quoi ?

              Posté par . Évalué à  1 .

              Faut pas oublier non plus les secteurs de réserve du disque en cas de crash temporaire.
              • [^] # Re: Ben quoi ?

                Posté par . Évalué à  4 .

                Les secteurs de réserve utilisés pour remapper les secteurs défectueux ne sont pas numérotés ni adressables, ils ne sont donc pas comptés.
            • [^] # Re: Ben quoi ?

              Posté par . Évalué à  -4 .

              « 100 "Go" fait 93 "Gio" »

              Non. Autant en réseau les constructeurs et autres font de la puissance de 10, autant dans le cas des disques durs, il s'agit bien de capacité en "Gio" avant formatage.
              • [^] # Re: Ben quoi ?

                Posté par (page perso) . Évalué à  1 .

                Vous pouvez pas vérifier un minimum avant de dire ça?
                Je viens de vérifier :
                - Disque de 1.5 To affiché par le constructeur
                - Donc 1 500 000 000 000 octets affichés par le constructeur
                - capacité réelle après formatage 1 500 299 264 000

                Le constructeur prend quand même un peu de marge, et même avec cette marge la capacité formatée, en prenant de la marge pour ces secteurs défectueux, est supérieure à ce qui est affiché, et non pas inférieure comme vous le dites.

                Les constructeurs jouent certes sur le système 1000/1024, mais pas de la à avoir une capacité utile inférieure à ce qui est annoncé.
              • [^] # Re: Ben quoi ?

                Posté par (page perso) . Évalué à  4 .

                Pas du tout, les constructeurs de disque parlent bien en puissance de 10. Voir par exemple http://www.wdc.com/en/products/products.aspx?id=110 où on peut lire: 1 gigabyte (GB) = 1 billion bytes.

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Ben quoi ?

              Posté par (page perso) . Évalué à  2 .

              C'est vrai mais c'est un autre sujet.

              Ce n'était pas le propos de l'article qui montre que l'encapsulation à plusieurs niveaux des données entraîne le fait qu'une part non négligeable des données transférées ne sont pas les données "utiles" à l'application utilisatrice, même si elles sont utiles à l'acheminement, la détection/correction d'erreur, etc.

              Je faisais le parallèle entre cela et un système de fichiers dont les méta-données ne contiennent pas les données utilisateur mais restent indispensables, et occupent une part non négligeable de la place disque.

              Pareil avec l'emballage d'un colis, qui n'est pas utile au destinataire, mais est indispensable à son acheminement.
          • [^] # Re: Ben quoi ?

            Posté par (page perso) . Évalué à  4 .

            Les méta-données (inodes ou FAT, liste de blocs libres, répertoires)

            Ca, c'est le problème de ton système de fichier, le disque s'en fout, il fournit 100 Go, et tu en fait ce que tu veux (comme mettre un système de fichier, ou pas), point.
            Charge à toi de prendre le système de fichier qui optimise (un système de fichier qui permet un seul fichier de 100 Go? ;-) )
            • [^] # Re: Ben quoi ?

              Posté par . Évalué à  1 .

              Pas d'accord. Par exemple au temps des disquettes de 1.44 Mo, on pouvait des disquettes préformattées « DOS » (FAT16 quoi). Ben si on me dit « ta disquette est préformattée DOS et fait 1.44 Mo », ben je m'attends à juste ça : 1.44 Mo utilisables sous DOS. Pas 1.2 ou 1.3 Mo parce que les méta-données prennent de la place.

              Une fois qu'on sait comment calculent les constructeurs, « ça va », mais n'empêche, c'est de l'arnaque à la base pour pouvoir gonfler les chiffres.
              • [^] # Re: Ben quoi ?

                Posté par (page perso) . Évalué à  2 .

                Pas d'accord sur ton pas d'accord.
                avec ta logique, une clé USB de 4 Go contenant une distro Linux de 4 GB devrait être affichée 0 GB, ben non, c'est une clé de 4 GB sur laquelle on t'a facilité la vie en pré-installant un truc qui prend de la place.

                Ta disquette de 1.44 Mo, elle fait bien 1.44 Mo. (au passage, c'était encore l'époque, 1.44 Mio, soit 1.51 Mo.), même si on te pré-installe un système FAT (tu peux le virer), surtout que la taille prise par la FAT dépend du nombre de fichiers (et de leur taille), donc on peut pas donner un chiffre de taille utile FAt!
                • [^] # Re: Ben quoi ?

                  Posté par (page perso) . Évalué à  2 .

                  Une disquette HD faisait 2Mo. C'est pour ajouter de la redondance qui permettait d'espérer la relire que le formatage 1.44Mo était le plus courant. Mais on pouvait aussi faire de 1.72Mo (distribution Toms RTBT) et même jusqu'à 1.9Mo. Mais là, tu ne relisais ta disquette que sur le lecteur qui l'avait écrite.

                  "Virtually all 1.44 drives support 1.722 just fine, but it is possible for
                  an extended format to break a floppy drive, use tomsrtbt at your own risk.
                  The install does mknod to make /dev/fd0u1722 if you don't have it already."



                  cf. http://en.wikipedia.org/wiki/Floppy_disk#Efficiency_of_disk_(...)

                  ⚓ À g'Auch TOUTE! http://agauch.fr

                  • [^] # Re: Ben quoi ?

                    Posté par . Évalué à  5 .

                    Ce n'est pas de la redondance, c'est juste des paramètres d'écriture (gap entre secteurs, etc.) suffisamment larges pour tolérer les imperfections de lecture.
                    (je ne crois pas qu'il y ait la moindre redondance sur les formats de disquette standard, sauf si tu appelles redondance une somme de contrôle à la fin d'un secteur)
                    • [^] # Re: Ben quoi ?

                      Posté par (page perso) . Évalué à  2 .

                      Autant pour moi. Et dire que j'y croyais...

                      ⚓ À g'Auch TOUTE! http://agauch.fr

                • [^] # Re: Ben quoi ?

                  Posté par . Évalué à  2 .

                  Non, la taille de la FAT (table d'allocation des fichiers) ne dépends pas du nombre de fichiers, elle est fixée par la taille du média. Chaque secteur du média est représenté par un certain nombre de bits.

                  Au bout d'un moment, on en a mis deux, mais elles ont toujours une taille fixe.

                  Ce qui varie avec le nombre de fichier, c'est la taille occupée par les répertoires, mais a ma connaissance c'est le cas avec tous les systèmes de fichiers.
                • [^] # Re: Ben quoi ?

                  Posté par (page perso) . Évalué à  1 .

                  Chipotage chipotage, mais la capacité annoncé des disquettes est de 1440 Kio, soit 1.40 Mio, soit 1.47 Mo

                  http://en.wikipedia.org/wiki/Floppy_disk

                  Oui oui, les gens mélangaient les unités de base 10 et les base 2 dans le même nombre
                  • [^] # Re: Ben quoi ?

                    Posté par (page perso) . Évalué à  1 .

                    Argh exact, j'avais oublié la subtilité.
                    C'est bien 720 Kio (multiple de 1024) qu'ils ont doublé, et donc un "1.44" qui voulait plus rien dire.

                    C'est beau le marketing. (Mais bon, depuis qu'Orange parle de Mo pour des débits, et que les gens même ici le reprennent sans sourciller, je me dis qu'il ne faut plus s'étonner de rien...)
            • [^] # Re: Ben quoi ?

              Posté par (page perso) . Évalué à  2 .

              oui je suis tout à fait d'accord, c'est la taille du support physique qui est vendue, c'est bien ce que j'ai dit ;)

              on peut se servir d'un disque de 100 Go pour faire des sauvegardes avec tar/gz en écrivant directement sur les secteurs bruts, on aura bien 100 Go.
    • [^] # Re: Ben quoi ?

      Posté par (page perso) . Évalué à  2 .

      C'est un peu pareil que ceux qui achètent un disque dur de 100 Go et qui vont se plaindre que Windows n'affiche que 99,2 Go de libres

      Ca n'a presque rien à voir.
      - Il y a très peu d'octets qui servent au "contrôle" (l'OS met son boot, et le partitionnement, sinon le reste est utile)
      - Juste que les constructeurs ont changé en cours de route, passant de 1K=1024 à 1K=1000, et que Windows est resté sur 1K=1024. Le mieux est donc d’utiliser les normes qui vont bien (1K=1000 et 1Ki=1024).

      Il y a bien 100 Go d'utile (utilisable par l'OS qui y met son boot) sur une disque de 100 Go, et les octets de contrôle (de souvenir, 4 octets de CRC pour 512 octets) ne sont pas comptés, alors que pour Ethernet les octets de contrôle sont comptés.
      Bon, après, tout le monde de la transmission joue à ça (essaye avec un 20 Mbps ADSL, vu qu'ils compte le débit couche basse, tu as le droit à la couche ATM, puis IP puisque tu ne peux pas communiquer directement en ATM j'aurai dit qu'il faut compter en IP, mais bon... Pour la défense des FAI, de souvenir un lien 512Kbps avait 640Kbps en réalité, pour avoir du 512K HTTP, ils ne mentaient pas et prenaient de la marge. Au début)
      • [^] # Re: Ben quoi ?

        Posté par . Évalué à  5 .

        un k, pas un K, pour 10³.
        Désolé, et bon réveillon.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

        • [^] # Re: Ben quoi ?

          Posté par (page perso) . Évalué à  2 .

          eh! D'habitude c'est moi le pointilleux ;-).

          D'ailleurs, quelqu'un a-t-il une explication sur le fait que "k" est la seule lettre minuscule pour les puissances de 1000 positives?
          Je me serai plus attendu à une logique du style puissances de 1000 positives = majuscules (1K - marche pas celui la c'est 1k - , 1M, 1G, 1T, 1P...), puissances de 1000 négatives = minuscules (1m, 1µ, 1n, 1p...).
          • [^] # Re: Ben quoi ?

            Posté par . Évalué à  5 .

            > D'ailleurs, quelqu'un a-t-il une explication sur le fait que "k" est la
            > seule lettre minuscule pour les puissances de 1000 positives?

            Peut-être parce que le K est pour les degrés Kelvin ?
            Juste au hasard, quoi, avant d'aller m'enfiler un petit champagne et quelques toasts.
            • [^] # Re: Ben quoi ?

              Posté par . Évalué à  3 .

              Puisqu'on en est a ergoter sur des détails:
              On dit kelvin, et pas "degré kelvin".
              • [^] # Re: Ben quoi ?

                Posté par . Évalué à  2 .

                et même Kelvin avec une majuscule sur le K, ce dont il était bien question ici /o\
                • [^] # Re: Ben quoi ?

                  Posté par . Évalué à  1 .

                  D'après l'article de wikipedia
                  http://fr.wikipedia.org/wiki/Kelvin
                  l'unité s'écrit en minuscule car c'est un nom commun, même si ça vient de lord Kelvin (William Thomson), comme la plupart des unités physiques.
                  La version anglaise en parle également
                  http://en.wikipedia.org/wiki/Kelvin
                  même si elle n'est pas cohérente avec elle-même et l'acrit souvent avec une majuscule...
                  • [^] # Re: Ben quoi ?

                    Posté par . Évalué à  2 .

                    ah bon merci, désolé pour le bruit alors. Je me coucherai moins bête ce soir.
          • [^] # Re: Ben quoi ?

            Posté par . Évalué à  3 .

            kilo n'est pas le seul multiple à s'écrire avec une minuscule, il y a aussi hecto et déca (voir ici : [http://www.industrie.gouv.fr/metro/aquoisert/prefixe.htm]).
            Il semble que les majuscules résultent de la mise en place du Système International (entre 1948 et 1960), dernière évolution majeure du Système Métrique de 1790. Initialement, il avait été choisi des préfixes grecs pour les multiples et des préfixes latins pour les sous-multiples, le tout écrit en minuscule (sauf pour micro). Cependant, la plage de valeurs prévues s'est révélée insuffisante et il a fallu en ajouter (femto et atto en 1964, par exemple).
            Il me semble, que pour ces ajouts, il est plus simple de décider : majuscule pour les multiples, minuscule pour les sous-multiples que de respecter le critère grec/latin (il y a de nombreuses entorses à cette règle dans ceux choisis récemment).
            Une petite histoire ici : [http://www.industrie.gouv.fr/metro/aquoisert/etymol.htm]
      • [^] # Re: Ben quoi ?

        Posté par (page perso) . Évalué à  2 .

        oui. le débat Kio/Ko est hors sujet. Je parle de la place occupée par les méta-données d'un système de fichiers qui font que Madame Michu ne verra jamais exactement la place libre sur le disque correspondre avec la taille du support physique.
        • [^] # Re: Ben quoi ?

          Posté par (page perso) . Évalué à  1 .

          Je parle de la place occupée par les méta-données d'un système de fichiers qui font que Madame Michu ne verra jamais exactement la place libre sur le disque correspondre avec la taille du support physique.

          Tu peux parler de ce que tu veux, mais si tu ne parles pas de la capacité d'un disque, ben ce n'est pas la capacité d'un disque.

          Si Mme Michu installe un système de fichier même sans le savoir, c'est normal que ça prend de la place et que Mme Michu voit moins, ça n'enlève pas la capacité du disque (sans système de fichier), on a la démonstration dans le fait que même Mme Michu peut virer le système de fichier (il n'a absolument rien d'obligatoire).

          Les constructeurs de disques vendent des disques (si si), pas des systèmes de fichiers (c'est toi qui fait ce que tu veux), c'est normal qu'ils indiquent la taille du disque hors système de fichiers (l'installation d'un système de fichier étant à la discrétion de Mme Michu, la taille du système de fichier dépendant en plus de son choix du système de fichier)

          Mettons ton argumentation à l’extrême : mon système de fichier inventé laisse toujours 1 octet libre, quelque soit la taille du disque. Doit-on obliger les constructeurs à indiquer 1 octet comme taille disque? CQFD.

          Note : ceci reste de la théorie, car en pratique même avec un système de fichier, la taille du disque reste encore largement supérieure à la taille affichée https://linuxfr.org/comments/1195201.html#1195201 .
          • [^] # Re: Ben quoi ?

            Posté par (page perso) . Évalué à  4 .

            Je répète : je suis d'accord avec toi. C'est normal que la place libre soit inférieure à la taille physique.

            Où ai-je dit le contraire ?
  • # Collisions

    Posté par . Évalué à  2 .

    ET tout ça, c'est sans compter sur les problèmes de collision qui arrivent imanquablement.
    • [^] # Re: Collisions

      Posté par . Évalué à  4 .

      Pour avoir des collisions, il faut partager le média entre plusieurs interfaces; pour cela il faut avoir un hub et non pas un switch, ce qui est quand même très rare de nos jours, surtout en 100Mbps.
      • [^] # Re: Collisions

        Posté par . Évalué à  -2 .

        Oui et non. Essaie de transférer un fichier en UDP avec un simple câble croisé (cat | nc -u); tu verras que le fichier que tu récupères est corrompu, il manquera des morceaux.

        Comme tous les protocoles sont conçus avec en tête un réseau non fiable (TCP garantit la retransmission, et UDP ne garantit pas la réception des données), les cartes réseaux elles-mêmes s'autorisent des pseudo-collisions dans leurs tampons d'émission et de réception : elles acceptent toutes les données qui leur arrivent mais ne traitent effectivement que ce qu'elles peuvent.
        • [^] # Re: Collisions

          Posté par (page perso) . Évalué à  5 .

          C'est tout à fait possible, mais ça n'a strictement rien à voir avec une collision. Ça n'a aucun sens d'utiliser ce terme pour parler d'une queue qui déborde.
          • [^] # Re: Collisions

            Posté par . Évalué à  -3 .

            C'est vrai que ce ne sont pas de vraies collisions (c'est pour ça que j'ai mis "oui et non").

            Mais, d'une part, c'est précisément la possibilité de collisions qui autorise ce comportement, et d'autre part, ça a exactement le même effet : contraindre à employer un protocole à détection de pertes et contrôle de congestion pour transférer des données de façon fiable. Ce qui réduit légèrement le débit maximal utilisable, puisque c'est ce dont on parle.

            Bref, ce ne sont pas de vraies collisions, mais c'est lié, et l'effet et le remède sont identiques.
            • [^] # Re: Collisions

              Posté par . Évalué à  3 .

              c'est précisément la possibilité de collisions qui autorise ce comportement

              Non, même si historiquement le traitement des collisions dans les vieux ethernet a été un thème important, la fiabilité de certains protocoles de couches supérieures n'est clairement pas due à la nécessité de traiter uniquement ces collisions lors de la conception initiale, suivi d'une utilité plus large par effet de bord par la suite. La logique a été au contraire dès le départ de traiter tout type de perturbation ; collisions certes, mais aussi corruption provenant de la couche physique, puissance trop faible du récepteur pour suivre le rythme, débits dispos différents sur un routeur (ou un switch), et justement aussi des pertes internes rares dans les équippements pour simplifier leur conception, à tous les niveaux, que ça soit l'interface PHY / MAC, puis dans le MAC, puis l'interface MAC / CPU, puis enfin dans le logiciel. Les aspects fiabilités du TCP restent utiles même si par exemple tu passes sur un lien synchrone de très haute qualité au lieu de passer sur de l'ethernet.

              Donc il n'y a aucune raison de désigner une perte de paquet quelconque n'étant pas due à une collision par ce ; ce n'est même plus de l'abus de langage compréhensible, c'est juste une fausse désignation de la cause de la perte de paquet.
              • [^] # Re: Collisions

                Posté par . Évalué à  1 .

                Ce n'est pas ce que j'ai dit. Ce que je dis, c'est que les cartes réseaux s'autorisent à faire passer pour des pertes des paquets qu'elles omettent simplement de traiter, et que la possibilité de pertes par collision les a autorisé à procéder ainsi.
                • [^] # Re: Collisions

                  Posté par . Évalué à  2 .

                  Même en oubliant les couches supérieures, la possibilité de pertes par collisions n'est qu'une possibilité de perte parmi d'autres, et une perte rare de paquet n'est pas impossible même sur un lien full-duplex sur lequel il ne peut y avoir de collisions. Ce que je voulais faire passer dans mon commentaire précédent est que toutes les piles de protocoles sérieuses traitent les possibilités de perte de paquet, y compris des protocoles qui ne sont employés que sur des liens sur lesquels il ne peut intrinsèquement y avoir de collision (et pour lesquels cela a historiquement toujours été le cas) -- et que une source tierce de perte de paquet sur de l'ethernet, eut-elle été évitable moyennant une conception plus coûteuse, n'a pas à chercher de bénédiction du côté des collisions qui sont d'ailleurs de moins à moins à l'ordre du jour (du fait de l'utilisation massive de switches). Certes les collisions étaient à une époque une source peut être plus important que d'autres de perte de paquets dans certains contextes, mais les collisions ne sont sûrement pas ce qui a "autorisé" au sens causal le choix volontaire de conceptions plus simples ne garantissant pas une réception et un traitement complet des paquets (une telle garantie serait de toute manière ridiculement difficile et coûteuse à atteindre -- notamment seuls les systèmes temps réels durs pourraient utiliser de l'ethernet...) Les collisions font partie intégrante du standard ethernet (d'ailleurs nommé Carrier Sense Multiple Access with Collision Detection) et impactent même les interfaces MII. Il n'y a pas plus de lien entre la possibilité d'une collision (avec d'ailleurs le signal correspondant sur le MII) et une source de perte de paquet inhérent à la conception du MAC ou à une latence malheureuse à la récupération des paquets par le CPU qu'avec un mauvais CRC (en fait il y a même *plus* de lien entre un mauvais CRC et une source arbitraire de perte de paquet interne au MAC qu'avec une détection de collision, ce dernier cas étant retranscrit sur le lien et dans les MII, alors que les deux autres non)
                  • [^] # Re: Collisions

                    Posté par . Évalué à  1 .

                    Effectivement, maintenant que tu le dis... J'étais persuadé que c'étaient les collisions qui étaient la considération principale, mais en lisant ton argument, c'est assez évident que ce n'était qu'un facteur mineur. Merci pour la correction!
        • [^] # Re: Collisions

          Posté par . Évalué à  1 .

          UDP ne garantissant pas l'ordre de réception des paquets, je n'essayerais même pas.
          • [^] # Re: Collisions

            Posté par . Évalué à  1 .

            Un réordonnancement de paquet, dans le cas d'une transmission directe? Je ne peux pas exclure que les cartes réseaux fassent aussi ce genre de choses, mais cela me semble improbable.

            De toutes façons, ls -l te montrerait que le fichier reçu est plus petit que celui envoyé, ce qui indique bien que tous les paquets n'arrivent pas à destination.
  • # ...

    Posté par . Évalué à  -3 .

    Et si tu changes un des protocoles de ta stack tu changes l'inscription sur la boiboite en carton ? Et si tu fais un tunnel ? C'est le débit offert à la couche qui va l'utiliser qui compte et c'est ce qui est indiqué.

    Calculer en terme de payload est débile et n'a aucun sens (sans compter les methodes de calcul et d'approximation validées par robert et dédé du PMU de muneville-le-bingard).
    • [^] # Re: ...

      Posté par . Évalué à  4 .

      C'est parce que tu n'as pas son niveau. Il fallait lui demander : Le Telnet, ca prends combien de raw sockets en sur-adressage sur un FDDI ?
    • [^] # Re: ...

      Posté par (page perso) . Évalué à  3 .

      Il n'a jamais écrit qu'il fallait changer l'affichage, il a écrit qu'il fallait réfléchir à ce que ça voulait dire.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: ...

        Posté par . Évalué à  -2 .

        Y'a besoin de réfléchir pour un truc aussi trivial que "L'efficacité du point de vue de la couche N = octets utiles / octets transmis par la couches 1" ce qui est rarement supérieur à 1 ?

        Sachant que le calcul est entièrement bidon effectivement ca donne à réfléchir...
    • [^] # Re: ...

      Posté par . Évalué à  0 .

      c'est con que tu dis que ça n'a aucun sens, parce que justement l'overhead est pris en compte dans un dimensionnement correct...
      • [^] # Re: ...

        Posté par . Évalué à  3 .

        J'ai dit où le contraire ?

        C'est juste le raisonnement qui est:
        - foireux: à la base on suppose que les gens parlant de "débit théorique" voulait parler de "débit offert à la couche applicative" mais pas de "débit offert à la couche Ethernet"
        - inutile: par ce qu'après tout ca on à 4.8% d'écart sur une unité pifométrique et non définie
        - mauvais: par ce qu'on suppose du TCP/IP mais on oubli des petits truc comme des ACK et ce que ca engendre sur les 3 couches alors qu'on calcul à l'octet près l'overhead
        - approximatif : par ce qu'on suppose qu'un header TCP en 2010 fait 20 octets, qu'il y a pas de VLAN, qu'il y a pas de tunnel et des milliers d'autres trucs.

        Tout ca pour conclure sur quelque chose que tout le monde sait.
        • [^] # Re: ...

          Posté par . Évalué à  5 .

          J'ai dit où le contraire ?
          En disant que calculer en terme de payload est débile, ce qui équivaut à dire que calculer en terme d'overhead n'a aucun sens non plus.

          Ensuite je suis d'accord sur certains de tes arguments, mais tu ne les avais pas du tout développé dans ton premier commentaire.

          Peut être aurait il fallu commencer par là plutôt que jouer les oracles insultants, non ? (oui débile n'est pas un mot particulièrement gentil).


          - foireux: à la base on suppose que les gens parlant de "débit théorique" voulait parler de "débit offert à la couche applicative" mais pas de "débit offert à la couche Ethernet"
          Je vois pas en quoi c'est foireux, vu que c'est bien souvent le cas.

          - inutile: par ce qu'après tout ca on à 4.8% d'écart sur une unité pifométrique et non définie
          Elle est pas définie, normal vu que c'est une division de deux valeurs de même grandeur (et ca sera pas la seule valeur ayant une unité non définie en science).
          Pifométrique non.

          Ne prenant pas en compte tout, je suis d'accord (voir ton "mauvais") mais à part ça ...


          - mauvais: par ce qu'on suppose du TCP/IP mais on oubli des petits truc comme des ACK et ce que ca engendre sur les 3 couches alors qu'on calcul à l'octet près l'overhead
          Si la fenêtre de tcp est suffisament grande, tu n'as pas besoin de prendre en compte le ACK.
          Si tu travaille en fulle duplex, même chose tu t'en fous du ack.

          Si tu demandes aux gens d'être ultra précis, soit le toi aussi.

          - approximatif : par ce qu'on suppose qu'un header TCP en 2010 fait 20 octets, qu'il y a pas de VLAN, qu'il y a pas de tunnel et des milliers d'autres trucs.
          Clair que sur un PAN y'a toujours des vlan et qu'on fait du OpenVPN sur PPoE sur MPLS sur IP ...


          Tout ca pour conclure sur quelque chose que tout le monde sait. Et ben non tout le monde ne le sait pas forcément.


          bref un peu de tolérance que diable.
  • # CPL

    Posté par . Évalué à  1 .

    Surtout que le CPL, outre le débit qui chute selon ton installation électrique, c'est juste horrible quand t'as des onduleurs bon marché à côté.
  • # C'est le moins mensonger

    Posté par (page perso) . Évalué à  2 .

    soit un débit maximal d'environ 96.2Mbps ou encore 12Mo/s et non pas 12.5Mo/s.

    Perso, j'arrive plutôt à 10 Mo/s soutenu même avec du matériel bas de gamme, ce qui est déjà pas mal (80% du débit annoncé).
    Surtout quand je compare au 450 Mbps annoncé par du Wifi n par exemple, que je met côte à côte et qui dépasse péniblement les 5 Mo/s avec du matériel bas de gamme (10% du débit annoncé). Est-ce que vous arrivez à mieux avec du matériel haut de gamme?
    • [^] # Re: C'est le moins mensonger

      Posté par . Évalué à  0 .

      Avec une airport express entre un mbp et un mac mini, j'etais *bien* au dela des 5 Mo/s.
      Plus de l'ordre de qq dizaines. Tout etait dans la meme piece cela dit, et c'etait les seuls appareils connectes.
      C'est ce qui m'a pousse a cable la ps3 pour pouvoir mettre un reseau full N en fait.
      Je sais pas dans quelle gamme tu mettrais ca, perso je dirais milieu de gamme (ie pas de la merde, mais grand public quand meme).

      Nouvel appart, plus grand, avec une borne en plus pour repetiteur+musique, le panneau d'admin me donne des debits qui varient beaucoup.
      Le mbp susmentionne vient de passer de 150mbps a 54 d'un coup. Il est litteralement assis sur la borne (sous le canape). Dans qq minutes il sera de retour a 150.
      L'imac, loin avec 2 murs qui le cachent fait du 75-100 en moyenne. Le mbp du taff pose a cote n'a jamais depasse les 50, avec des chutes a 20 et qq. Ramene dans le salon, le meme mbp revient dans les 150.
      L'ipad tres mobile reste dans les 70 a la louche.

      Tout sur du 2.4ghz, le 5 n'ayant pas fait une grande difference, voire pas du tout.

      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: C'est le moins mensonger

      Posté par (page perso) . Évalué à  2 .

      Avec une « carte » Alfa Network j'arrive à me connecter chez le voisin, et en changeant l'antenne (je trouve triste que les antennes amovibles soient remplacés par des intégrées par ailleurs) la connexion est utilisable.

      DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # Euh

    Posté par . Évalué à  10 .

    La capacité d'un cable, c'est en (fractions de) farads, pas en Mpbs !
    Voila, ça, c'est fait.

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

  • # GIGA ?

    Posté par . Évalué à  2 .

    je suppose que tes câbles son en CAT5e ?

    bon pour 2x 10 euros, je te propose d'utiliser une technologie adapté :

    le 1000Mbits ethernet !

    et là c'est du 120Mo/s !!! au revoir Wifi CPL et consor !!!

    Un petit NFS dessus, et tu ne sais plus si tu est en local ou sur le réseau.

    Bref, on n'y peut rien si tu roules à 30km/h avec ta porche, parce que tu ne veux pas change r les pneus ....
    • [^] # Re: GIGA ?

      Posté par (page perso) . Évalué à  3 .

      bon pour 2x 10 euros, je te propose d'utiliser une technologie adapté :

      Ça coûte beaucoup plus cher que ça: il faut des cartes réseau mais aussi des routeurs adapté.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: GIGA ?

        Posté par . Évalué à  3 .

        s/routeur/switch/
      • [^] # Re: GIGA ?

        Posté par . Évalué à  1 .

        Je rêve ....

        imaginons que tu aies du matos d'il y a plus de 2 ans.

        il te faut : 2 cartes réseaux + 1 switch GIGA

        soit : http://www.ldlc.com/b-44f51eb7a68241a1.html

        = 43,64 euro

        Un routeur GIGA ? -> tu as un accès internet a plus de 100Mbits/s chez toi ?
        Rien ne t’empêche de bancher ton routeur/box ou autre chose en 100Mbits/s

        Car mis a part entre serveur ou PC équipé de disques pouvant atteindre 100Mo/s, rien ne sert de passer en GIGA.
        • [^] # Re: GIGA ?

          Posté par (page perso) . Évalué à  0 .

          = 43,64 euro

          On est à plus du double du prix annoncé, je considère ça comme beaucoup plus cher.

          il te faut : 2 cartes réseaux + 1 switch GIGA

          Je pensais aussi aux portables.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: GIGA ?

      Posté par (page perso) . Évalué à  0 .

      je te propose d'utiliser une technologie adapté :

      Ou pas.
      (cf les commentaires avant).

      Bref, on n'y peut rien si tu roules à 30km/h avec ta porche, parce que tu ne veux pas change r les pneus ....

      Tu peux proposer des solutions correctes par rapport au besoin? Si on élimine Ethernet filaire, ce n'est certainement pas pour rien, c'est qu'il ne répond pas au besoin (pas en terme de débit, il y a d'autres critères). Le proposer est H.S., on sait que ça poutre Ethernet, mais bon, ça a un très très gros défaut, je te laisser trouver lequel.
      • [^] # Re: GIGA ?

        Posté par . Évalué à  10 .

        J'ai beau chercher, j'arrive pas à trouver ton gros défaut. Au contraire, moi j'y vois un super avantage : je ne savais pas où étendre mon linge propre-mais-mouillé, et depuis que je suis repassé (haha) en Ethernet, je suis heureux.
      • [^] # Re: GIGA ?

        Posté par . Évalué à  3 .

        Les câbles téléphoniques ne sont pas terrible en ethernet 100Mbps ?

        De nos jours, quand on construit un immeuble de bureau, on installe des câbles cat5 ou cat6 dans les murs et les sols.

        Quand on construit une maison ou un immeuble d'habitation, on installe des câbles cat3 (16Mhz max).

        Le gros défaut est là.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.