Comprendre un système Linux minimaliste ...

[0000]

Bonjour,
Voici quelques articles trouvés sur le web, qui nous permettent peut-être de mieux comprendre (ou comparer) les systèmes Linux minimalistes de lecteurs réseaux du commerce ou des bidouilleurs ou des images que vous téléchargez et utilisez sans regarder comment elles fonctionnent.
Solutions pour Linux embarqué - Panorama et critères de choix
Les premières pages de cette formation Buildroot
Linux pour l'embarqué

[0000]

La mode actuelle des images OS Linux pour un player est d'utiliser un Realtime Kernel.

Dans une démarche complètement opposée pour tester, je tourne depuis quelques temps avec un noyau non préemptif et un kernel timer minimal config_hz=100. J'ai l'impression que ça marche très bien.

Quelques lectures intéressants :
Pour comprendre la préemption : https://devarea.developpez.com/linux-com...ion-noyau/
On y trouve quelques avantages d'un noyau non préemptif : http://retis.sssup.it/~giorgio/slides/rt...im-pre.pdf (un paragraphe de http://retis.sssup.it/~giorgio/rts-MECS.html )
kernel timer : https://lwn.net/Articles/145973/

[0000]

Mon test continue. Voilà ce qu'on peut faire avec buildroot pour créer un système minimal :



On voit 7 Tasks (ou processes). Mais ça ne reflète pas la vraie situation.
En fait, 3 (un des deux dropbear, sh, htop) sont temporaires, liés à ma connexion ssh.
De plus, avant de quitter cette session ssh, je vais arrêter le serveur ssh (le premier dropbear), donc plus moyen de connecter sur le player avant un prochaine redémarrage.

Ainsi le player tourne avec seulement trois programmes utilisateurs indispensables en plus du noyau : init, mpd et un très petit dhcp client (udhcpc).

Le CPU a 4 cores. Deux cores (2 et 3 sur la capture d'écran) sont réservés à mpd (voir Isolating CPUs)

A coté de 46 kthr (kernel threads), on voir aussi 4 thr. Ce sont les 4 threads créés par le task mpd.
htop permet d'afficher leur noms. On voit que "output:interfac" a une rtprio=50 (voir https://www.musicpd.org/doc/html/user.ht...scheduling ). On voit aussi ffmpeg dans le nom "decoder:ffmpeg" car mon minimserver fait un transcodage flac:wav24, ensuite mpd utilise ffmpeg pour faire le decodage du fichier wav reçu. Sinon on peut voir aussi  "decoder:flac" si mpd reçoit un flac.

[Jacques92]

Salut bz31,
Très intéressant. Une démarche identique a été mise en œuvre sur Archphile (qui tourne sur tous mes streamers maintenant et que j'apprécie beaucoup). Buildroot c'est sympa mais un peu monolithique. Tu devrais essayer Yocto. C'est un peu plus compliqué au début mais beaucoup plus souple pour créer différentes distributions. En plus, la plupart des fournisseurs de cartes pour l'embarqué livre un projet yocto avec le BCB qui va bien. C'est assez facile d'adapter ensuite en fonction des besoins pour faire du "minimal par ajout".
Quant à LinuxRT, tu peux l'oublier, il a beau s'appeler real time, il ne sait pas gérer le temps réel critique. Après quelques vérifications poussées, on l'a sorti des solutions pour le RTC au boulot.

[0000]

Bonsoir Jacques92,
Merci pour ta suggestion. Je vais essayer Yocto avec une RPi3.

[funkyalf]

@bz31 donc tu as fait un script pour mettre ton CPU au minimum, l'as tu fait pour la chaleur? ou autre chose

@jacques92 merci pour yocto je vais regarder aussi

[0000]

(12-03-2018, 10:31 PM)funkyalf a écrit : @bz31 donc tu as fait un script pour mettre ton CPU au minimum, l'as tu fait pour la chaleur? ou autre chose

Tu parles de la RPi3 ?
Je n'ai rien modifié la config noyau par défaut de raspberrypi 64bit.
Il y a que deux fréquences CPU disponibles : 600MHz et 1.2GHz.
J'ai seulement changé la gestion de fréquences CPU de powersave en ondemand, ce dernier est peut-être plus réactif.  Ça tourne presque tout le temps en 600MHz.

C'est un bidouille informatique, je ne prétends pas que ça améliore le son.
Je n'ai pas cherché à contrôler les autres fréquences RAM, GPU, et la mémoire GPU non plus (la RPi3 a 1Gb de RAM, suffisant pour gaspiller un peu. J'ai laissé les valeurs par défaut car je n'ai pas encore bien compris le core_freq. Dans ce doc https://www.raspberrypi.org/documentatio...locking.md ils disent "Frequency of the GPU processor core in MHz. It has an impact on CPU performance because it drives the L2 cache and memory bus."

[funkyalf]

étonnant le fréquence du GPU aurait un impact sur le memory bus mais il n'y a pas de chiffre .... n'empêche que pour un lecteur audio simple l'impact doit être négligeable...

tu sais bien que tout améliore le son ...
j'essaye encore de poser un brevet sur l'impact des extensions systemes sur le son

.................; ok je sors

[0000]

(12-03-2018, 11:57 PM)funkyalf a écrit : tu sais bien que tout améliore le son ...
j'essaye encore de poser un brevet sur l'impact des extensions systemes sur le son  

.................; ok je sors

Je ne veux pas me contredire, je suis objectiviste

[Jacques92]

Tu perds pas de temps toi !