Questionnements switch

[Guillaume G]

C'est très intéressant. Même si le débat est un peu vif, et que ce n'était pas mon but, j'apprécie de vous lire tous ! Merci !

[bbill]

(03-05-2021, 11:18 PM)phile a écrit : hello bbill,

(03-05-2021, 10:47 PM)bbill a écrit : ... il n'y a pas d'explications démontrées de l'effet des switchs, juste des constats sur les effets ...
la première étape est sans doute de constater le phénomène...  

[HS on] J'ai beau relire ces 2 phrases... je ne vois de versant "technique" dans ces 2 phrases...
sans doute me trompé-je, mais tu as un background technique ou littéraire ?
Aucune malice dans ce post, c'est juste histoire de piger... d'ailleurs sans doute est-ce mon background technique qui m'empêche de percevoir la subtilité de ces 2 phrases...   [HS off]

c'est pourtant pas compliqué à comprendre...
1.- certains constatent parfois les effets des alimentations linéaires, des horloges, des isolations, etc..
2.- il n'y a pas d'explications scientifiques démontrées/mesurées, même pas par les constructeurs de switch
et avec tes bidouillages de switch et ton "background technique", tu ne dépasse pas le point 1 ci dessus !
et finalement il reste juste les suppositions et le blabla..

[phile]

hello bbill,

(03-05-2021, 11:40 PM)bbill a écrit : il reste juste les suppositions et le blabla..

ya pas de mal à dire qu'on est "littéraire" et pas "technique"...   Littéraire n'est pas une tare, c'est une qualité comme une autre
je sais que je suis un peu technique sur les bords et pas trop littéraire... et ce manque vs litt est svt un gros manque (juste avis perso).
Ceci étant, vu que tu es littéraire, et que tu veux des topos techniques fouillés au max pour expliquer ci et ça... => comment feras-tu avec ton background littéraire pour analyser & voir les forces et faiblesses de ces topos technique de haut niveau ? (car si on veut un topo carré, forcément le nivo sera haut, et je suis quasi certain que je serais largué avec mon pov' nivo)
Cdt

[Fledermaus]

(03-05-2021, 10:36 PM)Olivier a écrit : Faux ! 
La ré émission de trame n'est pas systématique entre deux éléments actifs ethernet via TCP/IP.... ce qui est vrai pour du CIFS ou NFS, ne l'est pas pour de la VOIP ou UPNP. La perte de paquet, même si elle est peu probable, n'est pas impossible.

Ah, intéressant, merci !
A-t-on une idée voire des preuves objectives de la fréquence du phénomène, respectivement avec et sans switch ésotérique si possible, et de l'impact éventuellement audible sur le signal analogique produit en bout de chaîne ? Ce qu'on a pour le moment (cf. ASR) n'est pas très convaincant...
Si ce n'est pas le cas, il serait peut-être temps que les fabricants et promoteurs d'accessoires réseau audiophiles (qui doivent bien faire quelques tests objectifs pour developper leur fourbi et pour s'assurer de sa supériorité réelle par rapport à un basique 500 fois moins cher - à moins que non ?) commencent à sortir des vraies données vérifiables - tu imagines l'effet sur les ventes ?

[Olivier]

(03-05-2021, 11:25 PM)r11bordo a écrit :

(03-05-2021, 10:36 PM)Olivier a écrit :

(03-05-2021, 09:40 PM)Fledermaus a écrit :

Citation :Toutefois, j'accepte tout à fait l'idée qu'un signal, au travers cuivre, puisse subir des perturbations pouvant nuire à la qualité dudit signal et, in fine, à la musique. Ces switchs (ou switches?) ne me semblent pas idiots.

Sauf qu'il ne s'agit pas ici du signal (au sens analogique) mais de données (numériques) dont 100% sont préservées par tous les protocoles réseau quels que soient les câbles ou switches présents sur le trajet ; de ce point de vue, ça peut donc sembler complètement idiot.

Voilà,  c'était le moment de controverse et de débat

Faux ! 
La ré émission de trame n'est pas systématique entre deux éléments actifs ethernet via TCP/IP.... ce qui est vrai pour du CIFS ou NFS, ne l'est pas pour de la VOIP ou UPNP. La perte de paquet, même si elle est peu probable, n'est pas impossible.

Vrai ! sur le faux que c'est bien entendu faux que les données sont 100% préservées sur les protocoles réseaux. Tcpip garantie l'acheminement des trames réseaux mais pas UDP...
Et c'est toujours la même rengaine, ne pas oublier qu'un flux réseau est en premier lieu un flux électrique...

Non!
S’il n’y a pas de re émission de trames le tcpip ne garantie rien... il le permet, mais ne le garantie pas. Ce n’est pas de la semantique! C’est d’ailleurs une des prises de tête de mon taf.

[bbill]

(03-06-2021, 12:13 AM)phile a écrit : hello bbill,

(03-05-2021, 11:40 PM)bbill a écrit : il reste juste les suppositions et le blabla..

ya pas de mal à dire qu'on est "littéraire" et pas "technique"...   Littéraire n'est pas une tare, c'est une qualité comme une autre
je sais que je suis un peu technique sur les bords et pas trop littéraire... et ce manque vs litt est svt un gros manque (juste avis perso).
Ceci étant, vu que tu es littéraire, et que tu veux des topos techniques fouillés au max pour expliquer ci et ça... => comment feras-tu avec ton background littéraire pour analyser & voir les forces et faiblesses de ces topos technique de haut niveau ? (car si on veut un topo carré, forcément le nivo sera haut, et je suis quasi certain que je serais largué avec mon pov' nivo)
Cdt

c'est bien ce que je craignais.. tu n'as juste rien à démontrer 
et le jour ou tu publieras un papier crédible pour les switch, on en reparlera...

[r11bordo]

(03-06-2021, 12:18 AM)Olivier a écrit : Non!
S’il n’y a pas de re émission de trames le tcpip ne garantie rien... il le permet, mais ne le garantie pas. Ce n’est pas de la semantique! C’est d’ailleurs une des prises de tête de mon taf.

Beuh beuh beuh que non !
Dis autrement, tcpip implémente un mécanisme d'acquittement des trames TCP entre l'emmetteur et le récepteur qui permet la rémission des trames perdues.
Upd n'a pas ce mécanisme d'acquittement, et lorsqu'une trame est perdue, elle l'est pour de bon.

Enfin, c'est un reste que j'ai quand je développais il y a plus de 20 ans des drivers réseaux basés sur snmp (sur couche de UDP).

Pour ta problématique boulot, tu es sûr que tu n'es pas en UDP ? 

[SuperDupont]

Quand on a juste un marteau comme outil, tous les problemes ressemblent a des clous...
https://fr.m.wikipedia.org/wiki/Loi_de_l%27instrument
Il y a AUSSI des phénomènes liés aux bruits, aux impedances, a la gigue, etc.
Soit vous devenez un centre de recherche sur le sujet avec des vrais compétences et des experiences scientifiques repetables, soit vous experimentez et constatez la réalité dans votre système.

[Olivier]

(03-06-2021, 01:36 AM)r11bordo a écrit :

(03-06-2021, 12:18 AM)Olivier a écrit : Non!
S’il n’y a pas de re émission de trames le tcpip ne garantie rien... il le permet, mais ne le garantie pas. Ce n’est pas de la semantique! C’est d’ailleurs une des prises de tête de mon taf.

Beuh beuh beuh que non !
Dis autrement, tcpip implémente un mécanisme d'acquittement des trames TCP entre l'emmetteur et le récepteur qui permet la rémission des trames perdues.
Upd n'a pas ce mécanisme d'acquittement, et lorsqu'une trame est perdue, elle l'est pour de bon.

Enfin, c'est un reste que j'ai quand je développais il y a plus de 20 ans des drivers réseaux basés sur snmp (sur couche de UDP).

Pour ta problématique boulot, tu es sûr que tu n'es pas en UDP ? 

Tu l’as dit:  « permet » , mais pas systématiquement utilisé par les couches supérieures.
Des pertes de paquets se produisent sur des réseaux d’entreprise en tcpip, sans re émission. Idem pour les box de particulier, certaines ont d’ailleurs un petit monitoring sur le lan et sur le wan.
Mon intervention sur ce sujet est pour relativiser cet argument. Il y a des protocoles réseaux qui permettent de garantir l'intégrité des données, encore faut il qu'ils soient utilisés. Je ne suis pas développeur de couches bas niveau, juste ingé réseau (de formation) et ne fait que constater. Les développeurs doivent avoir leur raison qui m'échappe.
Maintenant, l'utilisation d'un switch "audiophile" ou tweaké ne pourra jamais prétendre résoudre ces problèmes, dans la mesure où cela intervient en dehors de son champs d'action. Par contre celui ci, si j'ai bien compris, intervient sur des paramètres de pollution électrique, d'horloge... Sur ces sujets, je fermerai ma bouche n'ayant qu'un apriori théorique et surtout n'ayant jamais testé ce genre d'équipement.

[phile]

hello Guillaume G,

(03-05-2021, 10:24 AM)Guillaume G a écrit : C'est un sujet qui me semble passionnant, et que j'aimerais expérimenter à plus ou moins court terme (quelques optimisations plus simple à faire avant...) 

quelles "optimisations plus simple" prévois-tu avant ?

(03-05-2021, 10:24 AM)Guillaume G a écrit : Mon but serait d'emmener un "simple" node 2i le plus loin possible. 

Cool !
Tu as farfouillé sur le web / forum : de bonnes modifs ont-elle été faites sur ce modèle ?
Je n'ai pas eu ce modèle mais vu qu'il se branche directement sur le 230V, je dirais qu'il faut l'ouvrir > virer son alim > utiliser une alim faible bruit.
Il faut peut de chose : un multimètre pour connaître la tension de sortie de l'alim.
C'est déjà une modif assez prioritaire à envisager (juste mon avis).

(03-05-2021, 10:24 AM)Guillaume G a écrit : Si je vois et comprends (enfin, je pense), l'idée de base est d'amener le signal, en filaire, jusqu'au streamer, dans un schéma box, petit câble, switch assez simple, câble aussi long que de besoin, switch audiophile ou tweaké (disons optimisé hifi) et câble court et de qualité vers le streamer.
Certains ayant même cumulé 2 à 3 switchs optimisés sur la fin. 

En gros c'est ça mais comme le sujet est en développement, il n'y a pas vraiment de schéma type.
Le mieux, vu que tu pars du départ   , est d'y aller pas à pas et déjà d'alimenter la box avec une alim linéaire. 

(03-05-2021, 10:24 AM)Guillaume G a écrit : Dernièrement, certains ont pu tester une "horloge", afin que le flux soit optimisé. C'est très intéressant, mais je me demandais où était placé cette horloge BG7TBL, en l'occurrence. Avant ou après le switch optimisé ? Juste après la box ? 

Ce type d'horloge est à brancher sur des appareils hifi (c'est pas fait pour switch & Co, c'est uniquement pour appareil "hifi") qui ont une entrée notée "WordClock". Elle "injecte" dans l'appareil hifi un signal d'horloge bien joli, qui est utilisé par l'appareil à la place de son horloge interne.
Exemple : cette interface USB/spdif, cf photo de la face arrière pour voir la connexion MCLK/WCK (WCK=WordClock, MCLK="Master Clock" qui est l'autre terme parfois utilisé)
Il n'y a pas ce type d'entrée sur le Node2i, donc cette horloge ne concerne pas ton système. Pas grave, il y a d'autre trucs plus cool 

(03-05-2021, 10:24 AM)Guillaume G a écrit : La première optimisation d'un réseau est, semble-t-il, de déjà mettre une alimentation linéaire correcte sur la box et les appareils présents sur le réseau ?  

Exact.
Néanmoins, inutile dans un 1er temps d'en mettre 12 si on a 12 appareils sur le réseau.
1er temps : une sur le routeur/switch. Si c'est ta box => une alim linéaire sur la box.
Ton réseau s'articule comment ? quels autres appareils y sont connectés ?

(03-05-2021, 10:24 AM)Guillaume G a écrit : Sur les optimisations de switchs en DIY, vous êtes des fous avec toutes vos soudures et tests divers ...
Je suis très loin de tout comprendre, mais c'est super intéressant. Merci pour votre travail (qui semble aussi être une passion !) 

1. on n'est pas fou, c'est pas une passion : on est forcé de faire ça car les boiboites fournies par les marchands ont des lacunes... 
2. c'est pas une passion en soi mais effectivement c'est très intéressant, et on se prend vite au jeu car les effets de quelques modifs simples / rapides / pas cher sont importants.
Tu es curieux ? alors c'est OK, ca suffit   Un fer à souder (20eur) + une loupe (50eur) + pinces et autres trucs (10eur) + un multimètre (50-70eur) et c'est parti (facture de départ qui peut paraître cher, mais elle sera très vite amortie, et elle sera vite oubliée face aux gains sur le rendu   )
Cdt