T
tankey

  • 18 août 2013
  • Inscrit 18 nov. 2006
  • 0 meilleure réponse
  • Petit nouveau Rédacteur potentiel
  • @tankey
    enchante...

    A la question : est-ce que le noyau de Fedora utilise les patchs pour du TR mou, la reponse est OUI...
    Apres verification, dans la rubrique "Processor type and features", sous-rubrique "Preemption model", c'est l'option "Voluntary Kernel Preemption " qui est validee par defaut dans le noyau Fedora Core.

    Je cite l'aide sous "make gconfig" :
    Voluntary Kernel Preemption (Desktop) PREEMPT_VOLUNTARY
    
    This option reduces the latency of the kernel by adding more "explicit preemption points" to the kernel code. These new
    preemption points have been selected to reduce the maximum latency of rescheduling, providing faster application reactions,
    at the cost of slighly lower throughput.
    This allows reaction to interactive events by allowing a low priority process to voluntarily preempt itself even if it
    is in kernel mode executing a system call. This allows applications to run more 'smoothly' even when the system is
    under load.
    
    Select this if you are building a kernel for a desktop system.
    Il y a aussi l'option "Preempt The Big Kernel Lock" de cochee :
    Preempt The Big Kernel Lock PREEMPT_BKL
    
    This option reduces the latency of the kernel by making the big kernel lock preemptible.
    Say Y here if you are building a kernel for a desktop system.
    Say N if you are unsure.
    Conclusion :
    Le noyau FC est par defaut configure pour faire du Temps Reel mou.

    De toute facon, ce ne coute rien de le valider et ca ameliore la Qualite de Service (pour le multimedia et le son).
    Verifie sur le dernier noyau 2.6.18-1.2849.fc6 sous FC 6...

    <edit>
    @tankey
    Je suis toujours dubitatif et tres resevre par les mesures faites par tous ces programmes logiciels de mesure de temps de latence...Je prefere sortir l'oscillo et l'emulateur pour cela.
    </edit>


    ++
  • @tankey
    Je te cite :
    "qui me donne 1 nanoseconde de temps de réponse ... (sur un duron 900mhz) C' est proprement fabuleux. )"
    Tu t'exprimes mal...

    Ce n'est pas la reponse de ton systeme donc le pire cas par exemple a une interruption (on mesure le temps entre l'occurence de l'interruption et le debut de traitement de l'ISR associee) qui est plutot de l'ordre de qq dizaines de µs...C'est ce temps de latence la qui est important.

    Tu as en fait mesure la plus petite periode du timer hardware TR utilise, qui est de l'ordre de la µs et qui est ici normal et non extraordinaire...
    Mais, bon je vais pas faire un cours....du soir... 😉

    ++

    PS : c'est pas mhz mais MHz...
  • Ah voila le lien que je cherchais! :
    ccrma

    Atrpms fait des modules pour ce kernel, mais fc5 pour l'instant! Le kernel me semble recompilé mais je ne sais pas comment il se situe au niveau du temps réel!
    http://mirror.atrpms.net/ccrma/apt/fedora/5/i386/RPMS.planetccrma/

    tu parles de blog nvidia? - c'est interressant ce que tu dis - mais j'avous ne pas toujours te suivre...

    Comme je suis interressé de "maintenir collectivement" les drivers nvidia sur livna, ce sujet m'interresse...
    (@Sat: mais je n'ai pas encore lu ton tuto sur mock sur ton site, ce qui me semble un préalable! Mais bon les personnes encore sous fc5 semblent patientes!)

    @tankey Si tu as des liens sur ces patches temps réel du pilote nvidia?