Alims linéaires NAS, switch, box...

[JBert]

(12-18-2017, 02:43 PM)bbill a écrit :

(12-18-2017, 02:28 PM)JBert a écrit :

(12-18-2017, 01:56 PM)bbill a écrit :

(12-18-2017, 10:56 AM)JBert a écrit : il faut se poser la question du fonctionnement d'un réseau. La perte de qualité en passant par un routeur n'est pas due à des problèmes d'alimentation mais à des problèmes IP. IP n'est pas fait pour du temps réel, il y a des phénomènes de jitter, surtout en UDP.

il n'y a pas de problème de temps réel pour un lecteur réseau qui a un buffer.. le réseau n'est la que pour transférer des fichiers qui sont par definition exacts et "reçus" avant d'être utilisés

Euh... Si. Ce n'est pas que je veuille absolument vous contredire...

Il faut que le buffer de réception ne se vide pas entièrement. La plupart des buffers des équipements de réception sont notoirement insuffisants (quelques Ko) parce qu'ils coûtent cher en silicium et en gestion par les programmes. Lorsqu'il n'y a qu'un seul émetteur et un seul récepteur sur le réseau, ça passe. Lorsqu'il y a du trafic annexe, ça casse.

Je viens de vérifier sur un appareil qui a le bon goût d'avoir une console série. La taille par défaut du buffer RX est de 4k. Le programmeur est gentil, il a collé en dur une taille de 88Ko (je pense que c'est le maximum avant que ça déborde de a mémoire parce que c'est plutôt étrange comme valeur). Avec un flux correspondant à une qualité CD, ça fait 0,5s d'écoute dans le buffer de réception. Pas lourd en cas de congestion ou de routeur un peu léger.

je ne sais pas de quel lecteur réseau tu parles ??? tu parles bien de lecteurs réseau pour de la hifi ??

Eh oui. Je ne donnerais pas le type parce que j'ai dû faire du retro dessus et que je n'en ai normalement pas le droit.

Citation :je n'ai jamais eu ce problème avec tous les lecteurs réseau hifi qui sont passés par chez moi... jamais

ps : de plus, parler de "temps réel", comme tu le fais, pour un réseau Ethernet n'a pas de sens...

Pour Ethernet, ça n'a pas de sens. Pour l'application, ça en a un. Et c'est bien pour cela que TCP/IP utilise deux mécanismes de QoS différents. Ça fait cataplasme sur une jambe de bois, mais ça fait son boulot raisonnablement. Enfin, ça le fait pour des switches L3, pas pour les switches à 3 francs 6 sous qui sont L2.

De toute façon, si on veut éviter ce genre de problème, on ne prend pas un réseau Ethernet avec TCP/IP par dessus.

Cordialement.

---

(12-18-2017, 06:10 PM)bz31 a écrit :

(12-18-2017, 10:56 AM)JBert a écrit : Le RPi est incapable de gérer le réseau sans jitter important (parce que le truc est partagé avec l'USB et la flash) et que sa mémoire tampon interne est ridicule. Vous courez déjà à handicap.


Personnellement, j'investirais plutôt dans un switch manageable de niveau 3 (et un beaglebone à la place du RPi puisqu'il a une vraie mémoire eMMC et une vraie interface ethernet). Mais vous faites ce que vous voulez.

Intéressants ces points. Tu peux développer ?

Le CPU des RPI utilise le même bus USB (il n'en a que deux de mémoire, un host et un device) pour ses quatre ports externes et le réseau ethernet qui est en fait au cul d'un convertisseur USB/Ethernet. C'est n goulot d'étranglement car l'USB ne sait pas gérer les interruptions et l'électronique fait du polling. Ce n'est pas vraiment efficace (ça marche, mais côté performance, ça tire beaucoup sur le CPU).