08-18-2017, 06:09 PM
(Modification du message : 01-13-2018, 07:46 PM par Olivier.
Raison de la modification: Changement d'hébergeur d'images
)
(08-18-2017, 05:30 PM)LittleScarabee a écrit : Merci pour tes tests et ton retour Olivier. J'ai vu hier qu'il y a avait des processus "RoonAppliance" qui restait en mode normal ! Je vais regarder comment corriger mon script. Par contre j'ai constaté qu'au niveau du PC il ne faut pas faire trop d'adminstration ou autre tâche en parallèle lorsque l'on réalise ce "tunning" : on quelques lenteurs lorsqu'on utilise du SSH.Je n'ai pas de problème de lenteur, mais avec le Ryzen (même sans SMT), j'ai du coeur ! De plus la mise en RT amène un risque de stabilité en surcharge. J'ai eu quelques plantage, même plus dus au Kernel 4.9 avec Ryzen.
(08-18-2017, 05:30 PM)LittleScarabee a écrit : De plus il faut aussi s'assurer que le processus "RoonAppliance" sur la partie analyse des fichiers est bien terminé car cela consomme environ 35% sur un CPU 4 coeurs, juste histoire de ne pas avoir de truc qui tourne en parallèle.C'est préférable, car ça bouffe pas mal de ressource, ceci étant dit, et sans mise en RT, je ne perçois pas de différence à l'écoute, durant analyse ou non. Le Scheduler fait bien le job en donnant la prio aux bons processus.
(08-18-2017, 05:30 PM)LittleScarabee a écrit : Pour le mode "FIFO" ou "Round Robin" je ne sais pas si je serais capable de faire la différence, mais sur le papier on est sur potentiellement deux modes à choisir selon son installation technique :
- FIFO : Installation Mono Serveur et on a uniquement le processus "RoonAppliance" qui est utilisé
- Round Robin : Installation Multi-Serveur et on a deux processus "RoonAppliance" et "RAATServer" qui sont utilisés
Qu'en penses-tu ?
"SCHED_FIFO (also called static priority scheduling) is a realtime policy that defines a fixed priority for each thread. This policy allows administrators to improve event response time and reduce latency, and is recommended for time sensitive tasks that do not run for an extended period of time.
SCHED_RR is a round-robin variant of SCHED_FIFO. This policy is useful when multiple threads need to run at the same priority level.
Like SCHED_FIFO, SCHED_RR is a realtime policy that defines a fixed priority for each thread. The scheduler scans the list of all SCHED_RR threads in priority order and schedules the highest priority thread that is ready to run. However, unlike
SCHED_FIFO, threads that have the same priority are scheduled round-robin style within a certain time slice."
cf. : https://access.redhat.com/documentation/...tions.html
Donc la théorie voudrait que le RR (tourniquet) gère mieux le multi-threating, pour le Core, pas évident pour le Bridge. Maintenant, faut voir à l'écoute et suivant la sensibilité de chacun.
L'idéal serait de faire le tri des process audio, mais comme ils s'appellent quasiment tous de la même manière
J'ai l'impression que ceux qui nous intéresse le plus sont : RoonServer et RAATServer ...