Re: Problème de lecture vidéo (trop rapide)
BERTRAND Joël a écrit :
> Bonjour,
>
> Y a-t-il un problème sur la liste ? J'ai envoyé deux messages qui
> n'apparaissent pas alors que j'en ai reçu plusieurs autres plus récents...
>
Comme celui-ci est passé, je reposte mes message. Désolé si les deux
premiers passeront en double...
Copie du message de ce matin :
Bonjour à tous,
J'avoue que le problème me dépasse et n'est visiblement pas restreint
aux vidéos. Je pense même que les erreurs NFS proviennent de la même cause.
J'ai actuellement deux machines en Debian/testing. Elles sont diskless
toutes les deux et tournent toutes les deux en testing à jour.
hilbert:
- cpu : Intel(R) Core(TM) i9-10900F CPU @ 2.80GHz
- carte graphique : VGA compatible controller: Advanced Micro Devices,
Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef)
- fstab :
192.168.10.128:/srv/hilbert / nfs tcp,nfsvers=3,async 0 0
192.168.10.128:/home /home nfs tcp,nfsvers=3,async,nolock 0 0
192.168.10.128:/opt/video /opt/video nfs tcp,nfsvers=3,async,nolock 0 0
heisenberg:
- cpu : Intel(R) Core(TM) i5-4570 @ 2.90GHz
- GPU intel
- fstab
192.168.10.128:/srv/heisenberg / nfs intr,tcp,nfsvers=3,async 0 0
192.168.10.128:/home /home nfs intr,tcp,nfsvers=3,async 0 0
192.168.10.128:/opt/video /opt/video nfs intr,tcp,nfsvers=3,async 0
0
Hilbert fonctionne normalement (aucune erreur). Je constate qu'il y a
une option intr qui traîne, mais celle-ci est ignorée si j'en crois la
page man (ce qui prouve que l'OS a été installé avant le noyau
2.6.25...). Je vais retirer cette option.
De la même façon, j'ai un nolock sur /home et /opt/video sur hilbert
que je n'ai pas sur heisenberg. Cependant, avec le noyau 4.19, tout se
passait correctement et si je vois bien le rapport entre les options NFS
et les erreurs dans la console, je ne vois pas trop le rapport avec les
timers. Il faut cependant noter qu'avec le noyau 4.19, tout se passait
correctement (aucune erreur NFS, aucun problème pour lire des vidéos).
J'ai bien essayé de redémarrer un 4.19, mais ce <censure> de systemd est
tellement imbriqué avec le noyau qu'il refuse de fonctionner normalement
et le démarrage d'un 4.19 échoue !
Je ne suis toutefois pas convaincu que le fait de retirer l'option
nolock va résoudre le problème puisque /var/log/syslog montre que les
erreurs NFS proviennent de / et non de /home (les erreurs sont tracées
avant que /home ne soit montée).
Je n' ai rien vu de particulier dans le dmesg de heisenberg.
Le serveur NFS est un serveur NetBSD 9.2 (i7-4770, 16 Go,
treize disques en grappes Raid1, Raid5, Raid6 et Ccd pour les swaps),
largement dimensionné et le daemon NFS fonctionne avec 16 threads. J'ai
essayé d'augmenter le nombre de threads, mais cela dégrade les
performances (il vaut mieux qu'un client se prenne une erreur NFS de
temps en temps plutôt que de faire monter la charge du serveur, j'ai
fait des benchmarks sur le sujet). NFS est en V3/TCP (j'avais essayé
UDP, mais ça n'améliore pas les choses et ça peut poser des problèmes
sporadiques).
Typiquement, la charge du serveur est inférieure à 1 et il répond sans
problème.
En retirant l'option intr et en rajoutant nolock sur /home et
/opt/video, j'arrive à ouvrir KDE sans que cela ne plante. Mais il y a
toujours des problèmes de vidéo. De temps en temps, ça fonctionne, puis
ça se met à ne plus fonctionner. J'ai essayé à partir d'un compte avec
un VLC correctement paramétré et le résultat est le même que le décodage
soit fait par VAAPI ou en soft (libplacebo). Au bout d'un certain temps,
la sortie son fini par devenir inactive et il me faut redémarrer la
machine pour qu'elle fonctionne à nouveau.
Je prends toute idée...
Bien cordialement,
JKB
Reply to: