Ethernet : manuel de survie pour l'audiophile

[shal]

mkl a exprimé un souhait d'une explication sur le fonctionnement de l'Ethernet;
Quel câble réseau?

Je m'y lance.
Ce n'est pas un cours sur Ethernet donc je vais oublier certains aspects et me concentrer sur ce que l'audiophile a besoin de comprendre sur ce qu'il se passe chez lui.

Commençons pas enfoncer des portes ouvertes:
L'ethernet c'est un protocole de communication entre deux appareils pour échanger de l'informations.
Alors on arrive super vite à la première difficulté , des gens seraient tenter de me répondre :" comment cela un protocole !, non Ethernet c'est du hardware pas un protocole" . Oui et non.....

En effet il faut pas confondre:
- la connectique. Par exemple RJ45 (ou RJ11 pour les téléphone)
- le câble .Par exemple : paire torsadé de catégorie 5 , 6  blindé ou pas
- le protocole qui gère l’envoi la réception des données : Ethernet

Maintenant que j'ai fait la distinction , je vais mélanger tout  cela par la suite (c'est pas un cours , hein) et me contenter d'expliquer Ethernet sur câble paire torsadé avec connectique RJ45.

Déjà sur une liaison Ethernet , il y a exactement deux personnes : une a chaque bout du fil et il n'y a pas de distinction entre les deux
( Contrairement par exemple à l'USB, le HDMI, le firewire , etc etc).
Chaque personnes (appelons-les carte réseau) peut à la fois (i.e simultanément ) écouter et envoyer des informations le câble.

Le simultanément est important mais on le verra plus tard.

Ça veut dire quoi envoyer de l'information sur le câble ?
Déjà l'information est représenté comme une suite de 0 et de 1 (par paquet de 8 , appelé octet).
Sur le câble, il vas y avoir une tension qui peut prendre deux valeurs possibles (haute et basse on vas dire).
La carte réseau aussi envoi aussi une représentation de ces 0 et 1 en faisant varier la tension sur un (ou plusieurs) fils du câble.

Là, j’hésite dans mon explication , car j'ai pas envie de rentrer dans les détails mais entre l'information et ce qui est réellement envoyer sur le câbles ce n'est pas la même suite de 0 et 1, il y a un encodage spécifique.

Donc j'ai eu envie de passer cela sous silence (comme plein d'autres trucs) mais finalement si je vais m'attarder dessus .
Pourquoi, parce qu'il y a un truc qui vas plaire au audiophile : une horloge  

Désolé ça vas être un peu ardu , accrocher les ceintures.

Ben oui, une suite de 0 et 1 comme cela, c'est aussi pas simple.
Prenons l'exemple, de nous voulons envoyer 10000 octet de 0 . Cela voudrait dire que la tension vas rester la même pendant longtemps sur le câble ?  mais alors comment celui qui réceptionne sait que ce n'est pas 9999 ou 10001  0 qu'il doit recevoir ?
Une solution serait d'avoir des horloges hyper précises et le problème est réglé  
Ouai mais ça coûte cher    
Les ingénieurs ont donc inventé un système pas cher qui résout ce problème de façon fiable.
Attention c'est de la technologie moderne : 1949  codage de Manchester .

En fait l'astuce cela vas pas être de dire que une tension égale une valeur mais que c'est un changement de tension qui veut dire quelque chose.
Par exemple, si la tension change on appelle cela un 1, si elle change pas on appelle cela un 0.

Une horloge précise n'est pas requise.

Ouff , vous avez compris ?  vous avez fait le plus dur  

Cool maintenant, on sais comment sont représenté l'information sur le câble.
Ca y est vous savez tout.

Ha!, j'en vois un au fond de la salle qui me signale que cela marche pas car il n'y a pas d'horloge commune entre l’émetteur et le récepteur.
Bigre il a raison       Merdumm

Je sais , ce que l'on vas faire c'est que a chaque fois que je vais envoyer de l'information je vais commencer par envoyer mon horloge. C'est a dire une suite d'alternance de tension haut et basse à la fréquence de l'horloge de  l'émetteur .
Comme cela le récepteur commence par voir ce préambule et peut en déduite mon horloge et donc interpréter les données suivantes avec cette horloge.
Bien sûr cela vas diverger a bout d'un temps mais en réalité , on ne se sert de cette synchronisation d'horloge que quelques millisecondes (beaucoup moins en réalité).

Ca y est , c'est fini  

Zut, le gars au fond de la classe qui me dit que cela marche pas.
Il me dit que vu que les deux cartes réseaux sont égales , alors les deux peuvent parler en même temps sur le câble (faire varier la tension) et alors les messages sont brouillés.

Humm, pas faux  

Alors, on vas dire que avant d'envoyer, la carte réseau vas écouter ce qu'il se passe sur câble.
S'il ne se passe rien , alors il vas décider d'envoyer le préambule d'horloge puis ses infos .

On pourrait répondre que , oui certes de son coté tout vas bien, mais peut-être que 100m plus loin l'autre carte a fait la même supposition et a envoyer aussi ses données.
En passant , vous voyer ici que le nombre de mètre de câble compte, non pas que pour des raisons électrique mais aussi du protocole qui gère l'envoi et la réception des données.

C'est pour cela que la carte réseau vas dans le même temps écouter ce qu'il se passe sur le câble (le simultané du début) et si ce qu'il reçoit c'est ce qu'il a émis. Il vas alors conclure que l'envoi c'est bien passer. Il est content.

Ok, maintenant l’envoi est OK mais 100m plus loin le signale a peut-être été corrompu lors du voyage.

Pas faux.....
On vas alors rajouter une information aux données envoyées qui vas permettre au récepteur de savoir si les données ont étés corrompu ou pas ( pour les curieux, on appelle cela un CRC).
Petite aparté : une donnée Ethernet arrive ou n'arrive pas mais si elle arrive elle n'a pas été modifié (donc les pertes d'aigu du aux problèmes Ethernet )

On revient en arrière , on a vu que la carte réseau écoute ce qu'il envoi pour voir si c'est identique. Mais qu'est-ce qu'il se passe dans le cas contraire ?
Et ben, la carte vas conclure que quelqu'un d'autre est en train de causer aussi .
Elle vas donc attendre un certains temps avant d'essayer de renvoyer les données.

Comment cela, un "certain temps" !
Ben ouai , on tire une valeur au hasard et on attends cette valeur  
Car dite vous que en face l'autre carte réseau fait la même chose , on peut pas prédéterminer une valeur.

Petite aparté , ça y est vous maîtriser la techno CSMA/CD  Carrier Sens Multiple Acces/ Collision Detection. Techno où les protagoniste sont plusieurs a avoir accès en même temps au médium et  écoute en même temps qu'envoyer et savent détecter les collisions.
Cette technique a été inventé pour la communication radio à Hawai (donc rien a voir avec un câble RJ45) mais si vous réfléchissez c'est le même problème.

Alors pour simplifier j'ai dit que il n'y avait que deux protagonistes: un a chaque bout de câble.
Mais en fait on peut en avoir plusieurs , mais il faut en appareil au centre , un switch avec plein de port RJ45.
Le switch copie ce qu'il se passe sur un câble sur les autres câbles (avec des optimisations dont je ne parlerais pas).
Vous pouvez alors avoir des centaines de cartes réseau sur le même réseau local Ethernet.

Là on a besoin de savoir qui cause a qui . On rajoute donc deux informations : l'identité de l’émetteur et du destinataire.

Donc dans nos informations Ethernet on a maintenant :
- le préambule pour gérer l'horloge
- le nom de l'émetteur et du destinataire
- l'info utile
- le CRC qui permet de vérifier que toute les données sont correctes .

De la bonne réception des données : j'ai expliqué que les données Ethernet sont reçut de façon correcte ou pas.
Donc on ne peut pas avoir de transmission fiable de donnée ?
Si mais ce n'est pas gérer par Ethernet, c'est gérer par d'autres protocoles , notamment TCP/IP qui est un autre sujet.

Passons aux travaux pratiques.
Voici l’état de ma carte réseau (sous linux) cela ressemble a cela :

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.1.58  netmask 255.255.255.0  broadcast 192.168.1.255
       inet6 fe80::16da:e9ff:fef3:fe79  prefixlen 64  scopeid 0x20<link>
       ether 14:da:e9:f3:fe:79  txqueuelen 1000  (Ethernet)
       RX packets 4065545  bytes 4717025368 (4.7 GB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 3061196  bytes 524585945 (524.5 MB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Incompréhensible, non?

Regardons de plus prés.

On voit   ether 14:da:e9:f3:fe:79 c'est en fait l'identité (unique au monde) de ma carte réseau , c'est cela qu'elle envoi dans chaque paquet qu'elle envoit
On voit aussi RX et TX  c'est pour Réception et Transmission
J'ai reçu 4.7Go de données et envoyé 4.7Go
RX errors 0  dropped 0  overruns 0  frame 0 cela corresponds au compteur d'erreur .
Si vous êtes attentif, vous voyez qu'il y a une erreur supplémentaire à TX: collision . C'est en effet spécifique à l'émetteur d’écouter à l'envoi.

Voyez aussi que d'erreur il n'y en a pas en fait.     c'est le cas dans des réseau simple comme une maison, en réseau d'entreprise c'est plus compliqué.

Il y a aussi  mtu 1500  je n'ai pas abordé ce point (comme plein d'autres). et oui sur Ethernet on ne peut envoyer que des petits bouts , il y a une taille maximum des paquet (MTU Maximum Transmision Unit) , en général 1500 octet . C'est de la responsabilité de TCP/IP de découper l'information en paquet de 1500.


Bon, c'était une courte et légère introduction  à Ethernet.

Olivier

PS :
Dans le même style (plus digeste toutefois):
Re: Un petit Dac entre un Mac et un ampli ?...
Re: USB : sa vie , son oeuvre

PPS: j'ai mis trop de smiley donc j'ai pas le droit de poster mon message. Désolé si je doit le rendre encore moins digeste

[Kaneda]

Bravo Shal et merci pour le travail

[papilucio]

Super vulgarisation, merci !  Même quand on connaît, ça fait un bon rappel :)

[mkl]

Merci.

[pagoparis]

Bravo pour la clarté du propos et la pédagogie de l'auteur.
Tout s'éclaire, je comprends !
Merci et n'hésite pas si tu en as le temps à aller plus loin.
Je m'inscris sur ce fil...

Patrice

[corintin]

Je m'y lance.
Ce n'est pas un cours sur Ethernet donc je vais oublier certains aspects...

très sympa à lire... bravo
il reste encore beaucoup de choses à expliquer pour faire de la musique, on compte sur toi !  

[shal]

Petite suite de mon poste.

Une discussion sur les switchs audiophile sur ce post Nas audiofile ssd m’amène a préciser certaines choses sur le fonctionnement d'un switch dans un réseau Ethernet.
Comme cela vas être un peu long, voir un peu chiant (faut être honnête   ), je ne poste pas dans le post en question.
Mais je me dis que cela pourrait intéresser 2-3 personnes sur ce forum.

Pre-requis: relire mon premier post au dessus.


Bon, dans mes explications au début , j'ai pris comme hypothèse que deux appareils discutaient ensemble.
J'avais donc laissé de coté le cas du réseau local comme il y a dans une maison ou une entreprise.

Historiquement, il n'y avait pas de switch mais des hub, on vas commencer par là.

Un Hub c'est un appareil avec pleins de ports (là où on enfiche une câble Ethernet) donc sur un Hub 8 port on peut brancher 8 appareils sur le réseau local.
En fait on peut mettre plusieurs hub si on veut plus d'appareil.

Concrètement que fait un hub ? Il écoute simultanément tous ses ports et des qu'un paquet arrive sur un des ports , le Hub le renvoi sur tous les autres ports. Une simple recopie , sans modification du paquet.
Si on zoom un peu sur l'architecture d'un Hub, il faut plutôt le voir comme pleins de carte réseau indépendante (des mini ordinateur indépendant) qui s'occupe d'un seul port. et il y a un autre processeur qui coordonne tous ces cartes réseaux indépendantes.
Donc si on reprends le cas d'un paquet qui arrive , la carte réseau du port 1 le reçoit, le place dans sa mémoire.
La il prévient le processeur central qu'un paquet est arrivé.
Ici plusieurs possibilités d'architecture mais je simplifie (désolé pour les puristes).
Le processeur central vas copier le paquet en mémoire du port 1 et le copier sur la mémoire de tous les autres ports.
Ensuite il vas signaler a tous les autres ports qu'ils ont un paquet en mémoire a envoyé sur le réseau.
Comme vu précédemment, la carte réseau attends le bon moment où le câbles est libre pour envoyer le paquet.

Si vous avez suivi , vous voyer que pleins d’opération durent un "certains" temps mais que cela prennent 1 ou 10 micro-secondes ce n'est pas très important. La qualité requise des horloges est un facteur pas important .

Ensuite que peux-t-il mal se passer ?
Prenons 2 ordinateurs connectés sur le port 1 et 2 discutent beaucoup ensemble avec un flux proche des limites du réseau, si un troisième appareil (sur la port 3) envoi des données à un quatrième (sur le port 4)
Et bien la carte réseau du port 2 doit trouver le temps d'envoyer à la fois tous les paquets qui viennent du port 1 (et qui sont a destination de l'appareil sur le port 2 donc important) mais aussi les paquets qui viennent du port 3 (dont l'appareils sur le port 2 n'as strictement rien à foutre)
Tous un coup , la carte reçoit donc l'ordre d'envoyer plein de paquets mais il faut du temps pour trouver le bon créneau pour envoyer les paquets.  la pauvre carte réseau voit qu'il y a de plus en plus de paquet a envoyer dans sa mémoire mais n'a pas le temps de tous les envoyer.
La mémoire étant de taille limité , la carte décide de temps en temps de supprimer certains paquets. Ça y est c'est l'embolie ou la congestion réseau.
En effet, je rappelle que rien ne garantie sur un réseau Ethernet l'arrivé des paquets , cela doit être gérer par d'autres mécanismes.
Et cela n'a rien a voir avec la qualité des horloges ou de l’alimentation.

Bon, c'était le Hub. Passons au Switch.
Ben c'est pareil    ou presque , avec une optimisation.

Quand on branche un switch, il se comporte comme un Hub. mais il deviens moins con au fur à mesure.
En effet, on a vu précédemment que dans chaque trame Ethernet il y a l'adresse de l’émetteur et l'adresse de l'expéditeur (un peu comme une lettre la poste quoi). Le switch se souvient donc que tel adresse source est arrivé sur tel port.
Donc ensuite quand un paquet arrive à la destination de cette adresse, le switch ne copie pas sur tous les ports (comme le hub) mais uniquement sur le port associé à cette adresse Ethernet.
Cette optimisation permet d’augmenter de façon considérable le débit possible sur un réseau locale.

Ensuite, il y a pleins de fonctionnalités additionnels possible pour un switch:
- Vlan : création de la réseau virtuel permettant de segmenter le réseau local
- gestion de la qualité de service (QoS) , cela est vu notamment pour les réseau qui transport de la vidéo ou du son

Je me suis contenté de préciser certaines choses de base utile pour l'audiophile, j'ai laissé de coté certaines choses.
(Un truc rigolo c'est de créer des boucles entre switch , voir par exemple https://fr.wikipedia.org/wiki/Spanning_Tree_Protocol )

En fait dans l’implémentation de ces switchs, il y a aussi un savoir faire pour trouver les bons algorithmes. C'est là où un grand constructeur vas être un peu meilleur que le no-name de base.

Et pour parler des switch audiophile, j'avoue que je vois pas. L'horloge on s'en fout comme de l'an 40 .
Les problème d'alimentation doit être gérer par le constructeur du Dac qui doit savoir filtrer ce qui vient de l'extérieur.
Si vous avez des différences de rendu en changeant de switch, changer de Dac.

Olivier

[corintin]

très sympa à lire... bravo
il reste encore beaucoup de choses à expliquer pour faire de la musique, on compte sur toi !  :cool:

c'était mon message de 2017 suite à ta partie 1 ci dessus...

Petite suite de mon poste...

et maintenant la "suite de 2019" qui est toujours aussi sympa à lire, une bonne vulgarisation

Et pour parler des switch audiophile, j'avoue que je vois pas.

mais la, visiblement tu n'as pas beaucoup d'expériences pratiques à nous raconter.. dommage
on en reste donc aux grands principes que personne ne conteste

on suppose donc que tu n'as pas fait d'écoutes et que tu es complètement fermé à la découverte (ou pas...)

ps : point commun entre shal, raphant, muciber... ils ont une approche "assez historique" de la dématérialisation soit encore via un PC et une carte son.. c'est évident que dans ces cas la, l'utilité d'un "switch dit audiophile" n'est pas évidente !  

[shal]

Je n'ai strictement aucune expérience ni théorique ni pratique sur la voyance ou le maraboutage.
Je persiste a dire que la voyance ou maraboutage sont de l'arnaque pur et simple.

Il est parfois inutile d'avoir une expérience pour dire que c'est de l'arnaque.

[papilucio]

bis repetita placent : bravo encore pour cette suite.

-- 14 Aoû 2019, 18:06 --

Il est parfois inutile d'avoir une expérience pour dire que c'est de l'arnaque.

oui, merci.
Ne pas être capable de faire ce travail de ne pas tester tout et n'importe quoi (et souvent n'importe comment) sous prétexte que sinon "on ne sait pas" est un signe soit de grande mauvaise foi, soit d'une hauteur de vue digne d'un platiste ("comment peux-tu dire que la terre est ronde si tu n'en as pas fait le tour ?").

[papilucio]

ps : point commun entre shal, raphant, muciber... ils ont une approche "assez historique" de la dématérialisation soit encore via un PC et une carte son.. c'est évident que dans ces cas la, l'utilité d'un "switch dit audiophile" n'est pas évidente !  :cheesygrin:

le mec vient de te parler de DAC et toi tu dis qu'il parle de carte son. À ce niveau, ce n'est plus de la mauvaise foi, c'est de la manipulation. Je ne sais pas ce que tu fais dans la vie, mais tu devrais essayer la politique si ce n'est pas déjà fait.

[PP_65]

"Je ne sais pas ce que tu fais dans la vie, mais tu devrais essayer la politique si ce n'est pas déjà fait."
Tu ne sais pas ce que fait CorinTuring ? Un truc entre la politique et le curé du village .

[papilucio]

une fusion entre Don Camillo et Peppone ? Ça frise le dangereux  

[mulciber]

Et pour parler des switch audiophile, j'avoue que je vois pas. L'horloge on s'en fout comme de l'an 40 .
Les problème d'alimentation doit être gérer par le constructeur du Dac qui doit savoir filtrer ce qui vient de l'extérieur.
Si vous avez des différences de rendu en changeant de switch, changer de Dac.

Une petite pensée pour tintin

[pagoparis]

Merci pour cette suite, n'hésite pas à continuer quand tu as un peu de temps libre, c'est très intéressant.

[raphant]

Bravo pour le travail de vulgarisation !
Si tu as le courage de faire un tome 3, essaie de nous parler plus en détail de la gestion des collisions, c'est très intéressant.

Ce qui est difficile pour certains audiophiles, c'est de ne pas faire de "fluxaudiomorphisme" lorsqu'il s'agit de réseau informatique.

Une petite pensée pour tintin

Amen !

[ajls]

Bravo Shal, c'est très bien expliqué  

[corintin]

Les problème d'alimentation doit être gérer par le constructeur du Dac qui doit savoir filtrer ce qui vient de l'extérieur.

tant que tu restes au niveau de la théorie, cela va... mais pour la pratique ... c'est beaucoup plus faible

exemple :
donc selon toi, les alimentations des switch ne sont pas un problème, cela doit être géré en aval par le dac ! aahh bon ???

mais ton collègue expert raphant explique (ci dessous..) justement le contraire !  

L’abandon de toutes les alims à découpage va en effet améliorer le rapport signal bruit...
Il est donc très simple de brancher tous les équipements informatiques sur une bonne alim linéaire,:

vous devriez vous mettre d'accord !!
alors, en pratique.. les alimentations des switch, c'est important ou pas ?      

Et pour parler des switch audiophile, j'avoue que je vois pas...

tu devrais plutôt dire que tu n'en as jamais vu...ni testé

[mulciber]

Bravo tintin , c'est une contre argumentation au top, tu as fait des progrès.

On est tous admiratif par tes démonstrations qui sont toujours d'une rigueur irréprochable.

Tu prends soin de ne pas déformer les propos des autres contributeurs.

Pour finir tu fais l’effort de comprendre les messages et les questions de tes contradicteurs.

C'est un vrai plaisir de partager tes convictions.

[Vanel]

Si vous pouviez éviter d'étaler vos scènes de vieux couple sur le forum ce serait très sympa pour nous et respectueux pour Shal qui s'est fendu de posts super intéressants et pédagogiques (merci pour cela, c'est ce qui me manquait)  Tapez-vous sur la tronche via mp, cela fera nous fera des vacances. Merci par avance.

Bravo Shal et on en redemande. Enfin un post digne de ce forum. Pour les enfantillages,merci d'aller sur le bleu.