Protocole Diretta

[herisson88]

Désolé les MTU sous windows demande à une IA moi je ne l'ai jamais fait...
Tiens ce soir je teste MTU 16k sur CM4 la limite serait de 16k alors que le RPI4 serait à 10k...
De quoi redonner pas mal d'intérêt au Red et autres C19...

[wgb25]

Bonjour,


Je repointe ces histoires de USB 2 / 3 

Un MTU qui se laisse configurer ne veut pas dire qu'il fonctionne sans erreur côté matériel. La seule façon fiable de vérifier, c'est de regarder le dmesg pendant une session longue, pas juste d'écouter si ça coupe.

Sur mon adaptateur USB-Ethernet (RTL8156B), à MTU 16132 le dmesg montrait des Tx timeout / reset USB récurrents sur ~40 min, malgré un rendu audio stable à l'oreille (le buffer masque ça). Retour à MTU 9000 : plus aucun timeout.

Ça vaudrait le coup de vérifier qu'un MTU de 16k tient vraiment la route et confirmerait ainsi la véracité de ce MTU 16K.



Alain

[herisson88]

C'est l'objet des tests, mais il est fort possible que le dongle soit le maillon faible...
Cela dit sur carte réseau nominale du NUC et du Red j'obtiens 9184 avec un son du tonnerre !

[Bluevelvet]

Bonjour,

MTU 9000 sous Rpi4/CM4 sur Audiolinux
Son incroyable sur mon Red !

@Herisson,

Formidable nouvelle !

Après mon passage en MTU 3824 sur C19/GentooPlayer, décidément les choses s’accélèrent !

Cette fois-ci, je n’aurai même pas à en informer Antonello, puisque je vois qu’il est lui-même dans la boucle sur GitHub et participe aux tests du nouveau patch.

Reste à attendre qu’il considère tout cela suffisamment stabilisé pour, je l’espère, voir au moins arriver le MTU 9000 sur RPi4/CM4 dans une prochaine mise à jour du kernel GentooPlayer.

En tout cas, quand on pense que le CM4 semblait encore récemment limité à un MTU de 1500, l’horizon s’est en très peu de temps largement ouvert, et de manière assez inattendue !

[wgb25]

Bonjour,

vérification MTU / DRUP / Diretta


Test sous Fedora avec DirettaRendererUPnP.
Interface dédiée eth-diretta : MTU 9014, lien UP.
DirettaRendererUPnP lancé avec --mtu 9000.
Surveillance dmesg pendant la lecture : aucune erreur, aucun timeout/reset/watchdog/NETDEV.
Lecture stable.

[Baldoun]

Bluevelvet,

Antonello a déjà publié un nouveau kernel CM4/RPI4 intégrant le patch MTU à 9000.
J'ai reconfiguré mon holo red ce matin et tout a l'air de fonctionner au niveau des logs. Je ferai des écoutes ce soir après le boulot.

[herisson88]

@wgb25 peux tu mettre un commentaire sur la pr en précisant machine/version du patch et tests effectués ?
Nicolaï est content d'avoir des retours de terrain
Merci !

[wgb25]

herisson88,


J'ai pas de RPI/CM4 


Test effectué sur Supermicro X9SCM-F + Xeon E3-1265V2, donc pas sur Raspberry Pi / CM4.
Fedora 44, kernel RT 7.2.0-359.vanilla.fc44.x86_64+rt.
Diretta Target : Minix Z100-0dB.
Interface Ethernet dédiée
eth-diretta
, MTU 9014, DirettaRendererUPnP lancé avec
--mtu 9000
.
Lecture stable, aucun timeout/reset/watchdog ni erreur réseau observé dans
dmesg
.

[herisson88]

Ah, mais ça cela a toujours fonctionné chez toi non ? ?

[wgb25]

En 9K, oui, ça a toujours fonctionné chez moi.

Par contre, avec l’adaptateur UGREEN USB/Ethernet 2,5 Gb basé sur RTL8156B, je pensais au départ être réellement passé en 16K : le contrôle de base indiquait bien un MTU 16K.

Mais avec des logs et des contrôles plus poussés, je me suis aperçu qu’en pratique ce n’était pas réellement stable/validé jusqu’au Target.

En augmentant les buffers, les problèmes disparaissaient, mais au prix d’une latence plus importante. Et cela ne prouvait toujours pas que le MTU 16K passait réellement de bout en bout.

Dans mon cas, la Supermicro ne dispose que d’USB 2.0. Ce n’est pas une interdiction théorique du MTU 16K, mais cela semble clairement être un facteur limitant avec le RTL8156B et cette configuration.

Donc mon conseil : ne pas se fier uniquement au MTU affiché côté Host. Il faut vérifier avec des logs/tests plus poussés que les trames jumbo passent réellement jusqu’au Target, sans fragmentation, erreur ou retransmission

Alain