(02-06-2022, 12:20 AM)zaurux a écrit : Jussy est un ancien de chez Nokia et connait les protocoles de communication sur le bout des doigts.
Par contre, lorsque l'on parle latence, il y a plusieurs versions des choses.
La latence de communication, notamment entre un serveur et un client. Classiquement en téléphonie et voip.
Et par ailleurs au sein d'un ordinateur et de sa gestion par un OS, la latence entre process et interruptions qui permet de "fluidifier" le traitement d'information entre matériels, process et E/S.
En gros quand cela bloque, vous avez un flux haché et quand celà est optimisé, vous accéder à une certaine transparence de traitement, indépendamment de la transmission du signal du serveur au client.
Contre exemple, vous installer sur un serveur HQplayer et sur un client, une image NAA.
Tout est transmis de manière efficace mais si vous avez un gros soucis de driver sur le serveur et une latence anormale... C'est inaudible !!
Je sais que tu travailles beaucoup sur la latence du serveur et que l'analyse que je fais des propos de Jussi peut ne pas être en accord avec tes convictions. Ceci étant posé, je n'ai pas exactement la même compréhension que toi.
Il me semble que la communication entre le serveur et le NAA est une communication Ethernet, et donc asynchrone. Et que cette communication asynchrone va réduire à néant les efforts réalisés en amont, car les paquets seront transmis au rythme du routeur et pas au rythme imposé par le serveur.
De ce fait, Jussi met l'accent sur la partie qui lui parait critique qui est la communication entre le NAA et le DAC, qui doit être régie par des processus temps réel.
En l'absence de NAA, il n'y a pas de communication Ethernet, et la communication avec le DAC est assurée par le serveur et il est donc critique que la partie temps réel soit sur le serveur.
Enfin, c'est ma compréhension, et je suis prêt à avoir tort, mais tes explications ne me convainquent pas...