Journal Gigabit, processeurs, câbles et parasites

Posté par  .
Étiquettes :
47
17
sept.
2008
Cher journal,

je t'écrit en cachette histoire d'archiver de modestes informations suite à des tests que nous avons effectués.

Nous avons utilisé:
- 2 ordinateurs très ordinaires avec chipset intégrant de l'Ethernet Gigabit (cartes-mères ABIT AN-M2HD)
- un commutateur Ethernet Gigabit (switch Netgear)
- 2 livecd Ubuntu
- du câble Ethernet catégorie 5e SFTP
- des câbles Ethernet divers
- des prises mâles et femelles
- une pince coupante
- une pince à sertir les prises Ethernet
- deux personnes
- une heure et demie
- divers (abonnement EDF, un local, de l'air...)

Notre but était d'explorer les limites du Gigabit en fonction de la longueur de câble, des perturbations, etc.

Avec un câble court et blindé pour chaque ordinateur, tout fonctionne parfaitement. Nous obtenons 112 Mo/s avec iPerf. C'est exactement 10 fois plus qu'en 100 Mb/s. Bon début. Les taux d'occupations processeurs sont affichées entre 140% et 150% avec "top" (doubles coeurs, donc 75% de la puissance totale, ouch).

Si l'un des ordinateurs est chargé artificiellement alors le débit chute. Par curiosité nous avons essayé avec une des machines embarquant une machine virtuelle utilisant plus de 25% du processeur, le débit chute, logique.

Nous essayons avec les câbles non blindés livrés avec les modems/routeurs ADSL que nous utilisons. Mêmes résultats.

Bien, passons aux choses sérieuses:
Le premier ordinateur est maintenant relié avec un câble SFTP de 101 mètres de long. Ce câble est vraiment très plié vers 70 mètres (le plastique est très marqué). Il y a quelques autres pliures mineures. On l'a équipé d'une prise RJ45 femelle à une extrémité et les fils sont nus sur environ 10 cm (gruick). Le blindage n'est relié à rien à aucune extrémité. Abouté à ce câble, un autre câble d'environ 4 mètres non blindé et un troisième câble d'environ 7 mètres (blindage relié au commutateur).
Le second ordinateur est relié de la même manière mais avec le grand câble de seulement 56 mètres de long. Ce câble a été un peu endommagé par des lapins (si si, réel) et est légèrement marqué de pliures ici et là. Pendant les manipulations, nous avons allègrement marché sur les câbles.

On teste... suspens... toujours 112 Mo par seconde.

On met les câbles en vrac au dessus des moniteurs cathodiques (les câbles pendent n'importe comment et font des boucles). On place un téléphone celullaire en contact avec la prise mal cablée (les fils nus sur 10 cm) donc 2 téléphones en tout. On place un téléphone DECT dans chaque tas de câble et on fait appeler les DECT vers les portables en même temps. Le débit est encore et toujours de 112 Mo par seconde pendant les sonneries et pendant les communications. Ca devient vexant.

Mon collègue arrive à faire s'écroule le débit en touchant un câble (à cause des problèmes causés par les lapins je suppose). Dès qu'il relâche, ça refonctionne parfaitement. Mais bon, joie, nous avons réussi à avoir la certitude que le logiciel n'affiche par 112 Mo par seconde tout le temps. Nan parceque ça aurait pu être un bug :-)

Nous n'avons pas de gros moteur à disposition histoire de vérifier la légende :-) Par contre j'ai déjà vérifier en 100Mb/s et ça ne changeait rien.

Nous avons utilisé du câble catégorie 5e endommagé, des prises volontairement mal faites, nous avons tenté d'introduire des parasites légers. Le débit est toujours au maximum théorique.

Un bémol: nous avions environ 170 m entre les deux ordinateurs, ce qui veut dire que les collisions auraient été très visibles en introduisant un autre ordinateur. Mais cela ne dépend pas de l'état physique des câbles.

  • # La légende

    Posté par  (site web personnel) . Évalué à 4.

    C'est quoi la légende avec le moteur ?

    Sinon journal sympathique. :)

    • [^] # Re: La légende

      Posté par  . Évalué à 5.

      Soit disant qu'un câble Ethernet passant près d'un moteur électrique ou d'un éclairage fluorescent est perturbé. L'explication pour le moteur est que ça génère des champs électriques (bof) et des perturbations radio à cause des balais/charbons. Pour les tubes fluo c'est soit disant à cause des ballasts.
      Il y a également des on-dit à propos des moteurs thermiques qui génèrent des perturbations radios à cause des bougies. Tout le monde peut le constater lorsqu'un bricolo-mobyletteux passe à moins de 100 mètres d'une antenne TV. Je n'ai jamais testé avec de l'Ethernet. Vu les puissances en jeu, je ne pense pas que ça puisse agir, mais ça reste à démontrer.

      • [^] # Re: La légende

        Posté par  . Évalué à 6.

        J'ai constaté le problème sur une liaison spécialisée passant à coté d'un climatiseur. Il y avait perte de synchro dés que le climatiseur se mettait en route. La syncro revenait quand le moteur était lancé. A noter que le climatiseur se trouvait à coté de la tête de câble, c'est à dire le boîtier à vis avec les arrivées des paires. J'en avais déduis que c'était le relais de mise sous tension du moteur qui causait la perte de synchro.

        Du coup le patron de ce PMU coupais la clim quand c'était l'heure d'enregistrer les paris !

        Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

      • [^] # Re: La légende

        Posté par  . Évalué à 1.

        ça génère des champs électriques (bof) et des perturbations radio à cause des balais/charbons

        C'est la même chose et c'est vrai. Un câble Ethernet étant à base de paires torsadé, il s'en "fiche" presque totalement de toute manière.

        • [^] # Re: La légende

          Posté par  (site web personnel) . Évalué à 2.

          Le fait que se soit torsadé aide beaucoup pour la réduction des parasites, mais c'est pas parfait non plus, il y a encore quelques parasites qui viennent interférer.

  • # liaison symétrique

    Posté par  (site web personnel) . Évalué à 5.

    Normal
    en Ethernet on utilise des paires torsadé,
    cela veux dire que à l'entrée de la carte on fait une amplification différentiel entre les deux fils.
    Si un parasite arrive il sera de même niveau sur les deux paires de ce fait il y aura aucune différence (vus que nous sommes en libre de potentiel).

    On utilise des liaison symétrique pour tous aujourd'hui:
    - Ethernet
    - ligne TT et dérivé (technologie dsl)
    - Sonorisation (tous les microphones on une sortie symétrique)
    - RS 422 (qui est la version RS 232 mais en symétrique)
    - DMX (c'est sur du RS485)

    • [^] # Re: liaison symétrique

      Posté par  . Évalué à 3.

      "c'est normal" n'est valable que pour les cas courants. En sonorisation par exemple, malgré les amplifications différentielles, ont a tout de même des parasites qui arrivent à se faufiler. Les effets capacitifs et selfiques introduisent des décalages, les imperfections des câbles également, l'électronique au bout, et surement bien d'autres effets que j'ignore.

      Nous avons poussé ce test très loin en dehors des spécifications, et c'est toujours 100% de débit. Ca, ce n'est pas normal du tout :-)

      • [^] # Re: liaison symétrique

        Posté par  (site web personnel) . Évalué à 5.

        Ce n'est pas comparable. Une liaison gigabit utilise une modulation spécial avec de la correction d'erreur. Pour le 10 gigabit, ils vont utiliser une correction d'erreur très forte (ldpc).

        En gros, tout est fait pour que de faible perturbation ne change rien au signal. Pour l'audio, c'est l'inverse. Il n'y a aucun code correcteur. En plus, l'oreille est sensible 16 bits sur des signaux de 1V, cela fait un step en µV. C'est très faible, les perturbations sont de l'ordre du mV en général.

        "La première sécurité est la liberté"

    • [^] # Re: liaison symétrique

      Posté par  (site web personnel) . Évalué à 3.

      Et la vidéo LVDS/DVI/HDMI c'est du différenciel aussi

  • # tu aurais pu avoir de meilleurs resultats

    Posté par  . Évalué à 9.

    Et toucher même le nirvana, et tes linux calculer l'origine de l'univers si ton cluster avait été relié par des câbles de 42 m 42 cm
    Tant pis pour toi

  • # tunning des OS ?

    Posté par  . Évalué à 3.

    Est ce que vous avez fait des modifications sur les ubuntu genre :
    - jumbo frames
    - paramètres des modules des cartes réseau
    - sysctl -w sys.net.... ?

    (en particulier pour essayer de faire baisser l'occupation CPU.)

    • [^] # Re: tunning des OS ?

      Posté par  . Évalué à 4.

      Rien, niet. On démarre les CD, on modifie les sources des paquets pour récupérer iPerf (universe + multiverse) et c'est tout.

      C'est vrai que c'est impressionnant d'avoir 75% d'occupation processeur avec des AMD X2 5000+. Ce ne sont pas les processeurs les plus performants du monde, mais ça traite minimum heu... beaucoup d'instructions par seconde :-)

      Par curiosité, comment faire baisser ce taux ?
      A mon avis, un grosse partie de la charge vient du logiciel iPerf lui-même. Je n'ai pas vérifié du tout.

      • [^] # Re: tunning des OS ?

        Posté par  . Évalué à 5.

        Par curiosité, comment faire baisser ce taux ?

        Le but est de passer moins de temps dans le noyau :
        - Envoyer des paquets plus gros que les 1500 octets habituels : jumbo frames.
        - Ne pas générer 1 interruption à chaque paquet reçu : Ca dépend des drivers des cartes...

        On trouve assez facilement des infos sur la net à ce sujet. Par exemple : http://datatag.web.cern.ch/datatag/howto/tcp.html

        Après, pour le mettre en pratique dans ton environnement réseau, c'est une autre paire de manches...

        • [^] # Re: tunning des OS ?

          Posté par  . Évalué à 2.

          Mais les JumboFrames ne sont pas standard il me semble certain
          equipement ne le supporte pas.

      • [^] # Re: tunning des OS ?

        Posté par  . Évalué à 4.

        Salut,

        déjà tu peux utiliser les "jumbo frames" ça permet de faire baisser significativement la fréquence des interruptions liées à la carte Ethernet étant donné que ça consiste à augmenter la taille maximum des trames Ethernet à 9000. C'est à dire qu'étant donné que le MTU (Maximum Transmit Unit) par défaut vaut 1500 tu génères 6 fois moins d'intérruptions pour la même quantité de données.

        Le MTU peut se changer avec : ifconfig ethX mtu 9000

        Tout en sachant qu'il faut que le pilote le supporte. De ce que j'en sais: forcedeth: oui, skge: oui, rtl8169: non.

        Sinon pour les chipset rtl8169 tu as NAPI, une nouvelle API pour diminuer la consommation cpu. Je n'en sais malheureusement pas plus.

  • # Concernant l'occupation CPU

    Posté par  . Évalué à 8.

    iperf est un très bon outil pour mesurer la bande passante TCP/IP ou UDP/IP mais l'algo utilisé pour faire une tempo entre deux émissions de paquet est très bourrin et consomme donc plus de CPU que de raison...
    D'ailleurs je crois que l'auteur le dit qqpart (dans le code ou sur son site, je ne sais plus)

    D'où ton CPU load très élevé....

    • [^] # Re: Concernant l'occupation CPU

      Posté par  . Évalué à 5.

      (auto-reply inside)

      D'ailleurs, si tu souhaites vraiment faire des tests de perf en by-passant toute la stack IP de l'OS Linux tu peux utiliser pktgen (voir http://www.linuxfoundation.org/en/Net:Pktgen).

      Au boulot on a fait des tests avec et c'est le bus PCI qui nous a bloqué :D
      Bon là en général c'est plutôt pour tester les capacités de commutation du switch ou du trunk inter-switch.

    • [^] # Re: Concernant l'occupation CPU

      Posté par  . Évalué à 2.

      Pour avoir pas mal utilisé Iperf il y a quelque mois, j'avais remarqué que la version Linux occupait 99% du CPU alors que la version Windows avait une consommation cpu plus raisonnable (même machine, débit de quelques dizaines de Mbit/s ).
      Mais contrairement à ce que l'on pourrait penser, je n'ai pas constaté de limitation de débit due à la "saturation" du CPU par Iperf sous Linux : Iperf utilisait 99% du CPU pour 20 Mbit/s, mais cela ne l'empêchait pas de réussir à saturer un lien gigabit....

      Il existe aussi pas mal de différences entre une carte réseau et une autre (et entre leurs drivers). Les cartes "haut de gamme" gèrent plus de choses matériellement que du rt8139 ou autre chipset "basique".
      Certaines cartes/drivers permettent de faire du polling, plus efficace que de générer une tetrachiée d'interruptions à la seconde.

    • [^] # Re: Concernant l'occupation CPU

      Posté par  . Évalué à 2.

      J'ai aussi eu besoin de faire des mesures de bande passante et pour cela j'ai utilisé netperf: http://www.netperf.org/netperf/ .

      Ce qui est bien c'est qu'il permet aussi de mesurer la consommation CPU.

      D'après les tests que j'ai pu faire avec cet outil l'utilisation en Gigabit d'un MTU à 9000 fait baisser significativement la consommation CPU et lors de l'utilisation de cartes PCI permet de saturer le lien Ethernet et me permettait d'atteindre le débit des cartes Gigabit PCI-Express.

  • # Tu bosses où?

    Posté par  . Évalué à 4.

    ça à l'air drôlement passionnant ces petites expériences (beaucoup plus que mon taf en tout cas...)

    • [^] # Re: Tu bosses où?

      Posté par  . Évalué à -10.

      Je peux me tromper mais ça pue le TP scolaire son truc, je pense pas qu'une boîte s'amuse à faire ce genre de choses (l'intérêt commercial me semble très limité).

      • [^] # Re: Tu bosses où?

        Posté par  . Évalué à 10.

        ça pue le TP scolaire
        ?! Peux-tu expliquer pourquoi les TP scolaires puent ?

        l'intérêt commercial me semble très limité
        C'est clair que c'est limité de connaître les limites de ce que nous utilisons en permanence :-) C'est limité de savoir qu'on peut passer une site en Gigabit sans avoir à recâbler puisque ce test tends à démontrer que de la catégorie 5e malmenée permet de passer avec zéro pépins.

        Je suis le respons^Wcoupable informatique d'une PME. Et souvent nous passons des heures à savoir comment fonctionne telle ou telle chose et à essayer de "casser" le truc. Ca permet de prendre des décisons. Par exemple entre Xen, Qemu et vmware, seul vmware tient le choc en virtualisant du Windows lorsqu'on sollicite beaucoup le disque et/ou le réseau. Donc nous avons choisi vmware.
        Pour le gigabit, nous souhaitons avoir une idée de ce qui peut amener des problèmes. Certains de nos sites ont des soucis réseau et visiblement c'est le câble qui est de trèèèèès mauvaise qualité. Ce test nous permet d'en être un peu plus certain.

        • [^] # Re: Tu bosses où?

          Posté par  . Évalué à 0.

          ?! Peux-tu expliquer pourquoi les TP scolaires puent ?
          Désolé, c'est une expression que j'utilise souvent qui n'a aucun rapport avec l'odeur réel de ce que je décris.

          Quand à l'intérêt commercial, vu sous cet angle, effectivement ça peut servir.

          Encore désolé de t'avoir vexé (je suis surement un peu jaloux parce que je m'amuse pas autant au boulot).

      • [^] # Re: Tu bosses où?

        Posté par  . Évalué à 4.

        C'est des TP qui m'auraient amusé en physique :)
        (on avait pas de lapin pour détériorer les câbles)

        Plus sérieusement, pour un service achat, savoir que la "qualité" d'un câble n'a pratiquement pas d'importance, vu les différences de prix qui peuvent exister c'est utile (la somme en jeu n'est pas forcément astronomique, mais c'est à retenir. En tout cas merci pour ce journal).

        • [^] # Re: Tu bosses où?

          Posté par  (site web personnel) . Évalué à 4.

          >Plus sérieusement, pour un service achat, savoir que la "qualité" d'un câble n'a pratiquement pas d'importance, vu les différences de prix qui peuvent exister c'est utile (la somme en jeu n'est pas forcément astronomique, mais c'est à retenir. En tout cas merci pour ce journal).

          Sauf que malheureusement, en pratique ce n'est absolument pas vrai.

          Les tests de Kerro montrent que même avec un cable endommagé on atteint le débit théorique du gigabit, mais bon si c'est interessant, la donnée vraiment utile c'est quel est le niveau de pertes sur ces envois.

          En NFS par exemple et dans d'autres protocoles types SAN/NAS, la perte de paquets, si elle n'est pas génante en soit, va ralentir notablemment les systèmes. ce qui à des impacts en cascade.

        • [^] # Re: Tu bosses où?

          Posté par  . Évalué à 3.

          La qualité des câbles est probablement très importante. Certains de nos sites sont en effets câblés avec du catégorie 5e blindé, posé par des électriciens (ahem...) et le résultat est nul de chez nul.
          Lorsque nous prenons un câble d'une de nos bobine (catégorie 5e également) ça fonctionne toujours. Même lorsque c'est posé par un électricien qui tire dessus comme un âne. Et nos câbles ne coûtent que 0€40 le mètre (et nous n'achetons pas en direct, donc ça inclus la marge du revendeur. Nous payons 400€ la bobine d'un kilomètre).

          • [^] # Re: Tu bosses où?

            Posté par  (site web personnel) . Évalué à 3.

            J'avais entendu que certain bâtiment câblé en câble blindé avait un niveau de bruit très élevé beaucoup plus que d'autre bâtiment câblé en non blindé : la cause était les boucles de masses faites avec le blindage.

            Sur tes tests avec téléphones, reboucles les masses (connecte ensemble les blindages des 2 bouts), cela devrait être terrible.

            "La première sécurité est la liberté"

            • [^] # Re: Tu bosses où?

              Posté par  . Évalué à 2.

              Je crois (à vérifier) que ce n'est pas une question de masse mais de boucle radio. Ma modeste expérience dans ce domaine est que deux bâtiments reliés pas un câble blindé peuvent faire passer un courant relativement important dans le blindage. Nous n'avons cependant pas constaté de perturbations sur le débit des données. Nous avons débranché le blindage d'un côté parceque nous en avions marre de nous prendre du jus en touchant les équipements. Et puis bon, ça ne semblait pas sain.

              Selon la théorie pure et dure, il faut que le blindage soit relié à une seule extrémité afin de ne pas créer de boucle radio. La réalité est que bien souvent la boucle radio existe tout de même, et là on s'en rends compte facilement: ça fonctionne très mal :-) Et parfois il faut chercher longtemps.
              Ca dépends vraiment des cas. J'ai toujours les problèmes de boucle dans des pièces "toutes simples" alors que je n'en ai jamais constaté à l'échelle d'un étage de bureau ou à l'échelle d'un site entier. J'ai des lacunes dans la théorie, mais la pratique m'a montré que la bonne méthode est de câbler propre puis de tester :-)

      • [^] # Re: Tu bosses où?

        Posté par  (site web personnel) . Évalué à 3.

        Si si, ce genre de tests est indispensables. En particulier dans des boites qui produisent du hardware, dans le cadre des tests CEM ( http://fr.wikipedia.org/wiki/Compatibilit%C3%A9_%C3%A9lectro(...) )

        On vérifie que le matériel continue de fonctionner normalement en environnement perturbé. Cela inclus de le bombarder d'ondes de diverses fréquences, de lui balancer des décharges ...
        Je pense en particulier à un test ou on fait cela sur un câble ethernet dénudé, ou avec des câbles de 10m faisant des boucles.
        Et pendant tous ces mauvais traitements le débit ne doit pas chuter et les paquets ne doivent pas être perturbés.

        Bon par contre, on utilise du matériel de test un peu plus perfectionné que des téléphones mobiles :) (ça permet de mesurer plus précisément les perturbations)

  • # Perf d'iPerf

    Posté par  . Évalué à 3.

    Apparemment depuis le nouveau timer implémente dans la version 2.6.21, iPerf consomme beaucoup plus de ressources :

    http://fr.wikipedia.org/wiki/Iperf#IPERF_avec_Linux_2.6.21_e(...)

    Voila :)

    (cette fois ci dans la bonne fenêtre)

    • [^] # Re: Perf d'iPerf

      Posté par  . Évalué à 3.

      Merci pour l'info :-)

      Je me pose une question depuis longtemps à propos de cette page wikipédia. Dans la copie d'écran, le commentaire "les fréquences hautes sont fortement atténuées par la distance" me laisse perplexe ; bien que le commentaire soit juste, il n'a rien à voir du tout avec ce qui est affiché. J'avoue ne pas avoir une opinion favorable lorsque je constate ce genre de conclusion. Son débit ADSL est d'environ 1 Mb/s dans un sens et 5 Mb/s dans l'autre. Sa copie d'écran ne fait que constater ce fait. Alors ça jette un sérieux discrédit sur le reste de l'article.

      • [^] # Re: Perf d'iPerf

        Posté par  (site web personnel) . Évalué à 2.

        C'est vrais que sans vraiment savoir pourquoi, on a l'impression que l'article manque de professionalisme,

        ca fait très .. "blog pseudo technique"

        A moins que ça soit la référence au mode patate en pleine capture d'écran :P,

        et les captures d'écran au milieu du texte

  • # Moniteurs cathodiques

    Posté par  (site web personnel) . Évalué à 10.

    On met les câbles en vrac au dessus des moniteurs cathodiques

    Quels moniteurs ? Il n'en est pas fait mention dans la liste des chose utilisée.

  • # Le milieu

    Posté par  . Évalué à 5.

    Si ton but etait de voir quelle etait les paramètres pouvant faire baisser
    les perfs, il faut voir que dans un environnement maitrisé, câble SFTP ou
    pas, çà ne change rien,
    mais dans des milieu industriel ou assimilé, ça aide enormement.

    De même que de passer pres de fluo pendant une grande partit du
    trajet, un courant fort pourrat beaucoup perturber les choses et
    generer des erreur CRC.

    Ensuite, dans une baie de brassage, si il y a plein de lien gigabit
    cuivre à pleine charge, sur de l'utp, ça peut perturber aussi.

    Si tu veux reelement voir les "choses" bouger sur ton lien cuivre,
    utilise un reflectometre et renseigne toi sur les valeurs suivante :

    NEXT
    FEXT
    paradiaphonie
    etc,

    Je n'ai malheureusement pas le temps de develloper, mais c'est
    passionnant le monde de la metrologie ( les tests quoi :) )

  • # La limite des 100m dans une installation Fullduplex ,çà a encore un se

    Posté par  . Évalué à 3.

    Puisqu'on parle de cable réseau une interrogation qui me trotte dans le tête depuis quelques temps.

    La fameuse limite de 100m pour les câbles Ethernet est elle vrai dans le cas d'une liaison directe full duplex sur un Switch.

    De souvenir, cette limite était induite par le temps de propagation des trames sur le cable ?

    • [^] # Re: La limite des 100m dans une installation Fullduplex ,çà a encore u

      Posté par  (site web personnel) . Évalué à 2.

      "cette limite était induite par le temps de propagation des trames sur le cable"

      C'est la limite de la norme pour lequel cela doit encore marcher. Par exemple, la puissance d'émission doit être assez forte, la sensibilité aussi, pour passer 100m de câble. La modulation et le traitement d'erreur sur le câble le moins chère possible sont taillés pour que cela marche sur 100m.

      "La première sécurité est la liberté"

      • [^] # Re: La limite des 100m dans une installation Fullduplex ,çà a encore u

        Posté par  . Évalué à 1.

        Alors dans la pratique dépassé les 100m de cable ethernet de Switch à Switch , çà marche ?

        En fait, je pose cette question car je vais bientôt relier deux bâtiment via un faisceau de câble Ethernet pour relier deux salle serveur.

        La distance final sera aux environs des 100m de cable ethernet.

        Dans mon établissement, j'ai des postes qui sont relié avec des distance supérieur à la distance envisagé sans rencontrer de problème ou d'erreurs réseaux.

        J'ai fait ce choix aussi car je ne voulais pas encore investir dans des convertisseurs fibres qui peuvent tomber eux aussi en panne.

        D'ailleurs, c'est l'expérience qui parle car j'ai eu pendant la canicule des convertisseurs fibres dans une armoire de bâtiment qui chauffait et planté régulièrement.

    • [^] # Re: La limite des 100m dans une installation Fullduplex ,çà a encore u

      Posté par  . Évalué à 2.

      Je réponds en retard :-)

      Nous avons relié pour dépannage deux bâtiments avec un câble de 156 mètres (celui rongé par les lapins, que nous avons coupé en deux pour nos tests avant de le poubelliser).
      Aucun défaut de fonctionnement, aucune perte de débit. D'un coté carte réseau RealTek de base, de l'autre un switch 8 ports d'entrée de gamme (composants RealTek également). On ne peut pas dire que c'est du haut de gamme, et zéro pépin pendant plusieurs semaines. La "vraie" liaison a ensuite été rétablie, donc récupération du câble.

      Dans les magains dont je m'occupe, nous avons également souvent nettement plus de 100 mètres entre le switch principal et les ordinateurs tout au fond du bout de l'extrémité. Pas de problèmes non plus. Notre maximum a été d'un peu plus de 200 mètres sans constater quoi que ce soit d'anormal (mis à part le fait, anormal, que ça foncitonne). Et le mythe des collisions qui augmentent avec la longueurs, ça reste à démontrer.

  • # Encore plus vite !

    Posté par  (site web personnel) . Évalué à 2.

    Et en mettant les doigts dans la prise électrique, ça accélère pas ?
    Ou en jetant de l'eau sur la carte réseau, t'as essayé ?
    Et la poudre verte ?

Suivre le flux des commentaires

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