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.
Journal Gigabit, processeurs, câbles et parasites
17
sept.
2008
# La légende
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Sinon journal sympathique. :)
[^] # Re: La légende
Posté par Kerro . Évalué à 5.
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 Big Pete . Évalué à 6.
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 Guillaume Knispel . Évalué à 1.
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 Gof (site web personnel) . Évalué à 2.
# liaison symétrique
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 5.
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 Kerro . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 5.
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 Victor . Évalué à -5.
[^] # Re: liaison symétrique
Posté par vrm (site web personnel) . Évalué à 3.
# tu aurais pu avoir de meilleurs resultats
Posté par libre Cuauhtémoc . Évalué à 9.
Tant pis pour toi
# tunning des OS ?
Posté par Bruno Muller . Évalué à 3.
- 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 Kerro . Évalué à 4.
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 Bruno Muller . Évalué à 5.
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 kowalsky . Évalué à 2.
equipement ne le supporte pas.
[^] # Re: tunning des OS ?
Posté par Michel Pastor . Évalué à 4.
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 Bibinsa . Évalué à 8.
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 Bibinsa . Évalué à 5.
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 kallix . Évalué à 2.
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 Michel Pastor . Évalué à 2.
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 pampryl . Évalué à 4.
[^] # Re: Tu bosses où?
Posté par jardiland . Évalué à -10.
[^] # Re: Tu bosses où?
Posté par Kerro . É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 jardiland . Évalué à 0.
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 Earered . Évalué à 4.
(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 -=[ silmaril ]=- (site web personnel) . Évalué à 4.
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 Kerro . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 Kerro . Évalué à 2.
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 jjl (site web personnel) . Évalué à 3.
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 Fabien Engels . Évalué à 3.
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 Kerro . Évalué à 3.
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 Bactisme (site web personnel) . Évalué à 2.
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 Gof (site web personnel) . Évalué à 10.
Quels moniteurs ? Il n'en est pas fait mention dans la liste des chose utilisée.
# Le milieu
Posté par kowalsky . Évalué à 5.
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 syj . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 syj . Évalué à 1.
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 Sytoka Modon (site web personnel) . Évalué à 2.
J'ai jamais eu un seul problème avec les Gbic HP sur les commutateurs HP et pourtant, j'ai presque toutes les générations de Gbic intégrable dans un switch HP depuis 14 ans...
Bref, éviter les convertisseurs et attaquer directement le switch (de préférence HP pour moi). D'ailleurs, il parait que les mini-Gbic CISCO sont des HP en réalité !
[^] # Re: La limite des 100m dans une installation Fullduplex ,çà a encore u
Posté par syj . Évalué à 1.
[^] # Re: La limite des 100m dans une installation Fullduplex ,çà a encore u
Posté par fasthm . Évalué à 2.
Quid des problèmes de potentiel électrique ?
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: La limite des 100m dans une installation Fullduplex ,çà a encore u
Posté par syj . Évalué à 1.
Enfin, çà ne devrait pas être un problème vu que tout doit être sur groupe electrogène en cas de coupure. D'un point de vue electrique, la terre doit être la même pour les deux batiments.
[^] # Re: La limite des 100m dans une installation Fullduplex ,çà a encore u
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
A priori, oui. Il parait que c'est tout de même la différence entre une carte réseau no-name et une carte 3com : sa capacité a respecter les 100 m.
"La première sécurité est la liberté"
[^] # Re: La limite des 100m dans une installation Fullduplex ,çà a encore u
Posté par Kerro . Évalué à 2.
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 Zorro (site web personnel) . Évalué à 2.
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.