Effectivement, il a probablement atteint les limites d'une écriture bufferisée, donc la solution serait effectivement de passer à un noyau temps-réel ou de repenser les I/O.
Même si un noyau patché PREEMPT-RT n'est pas un noyau temps-réel à strictement parler (on parle plutôt de qualité de service), même fortement stressé, on arrive à des latences max de moins de 10 ms. L'avantage par rapport à un vrai noyau temps-réel comme Xenomai, c'est que c'est assez simple à mettre en oeuvre, et ça demande peu de modifications pour un bon programme. http://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-appli(...)
Pour optimiser les I/O, quelques pistes :
* écriture vectorisé (writev) : ça permet au noyau d'optimiser les I/O, les opérations sont atomiques, en général ça pulse bien. C'est une technique souvent utilisée dans la vision industrielle.
* écriture asynchrone (man aio.h) : ça revient plus ou moins à l'idée de Christophe d'une gestion concurrente des écritures sans l'overhead lié à la gestion des threads. Un excellent article sur la question : http://www.ibm.com/developerworks/linux/library/l-async/?ca=(...)
[^] # Re: Faut faire du Realtime!
Posté par GeneralZod . En réponse au message Délai pendant l'exécution d'un fwrite. Évalué à 4.
Même si un noyau patché PREEMPT-RT n'est pas un noyau temps-réel à strictement parler (on parle plutôt de qualité de service), même fortement stressé, on arrive à des latences max de moins de 10 ms. L'avantage par rapport à un vrai noyau temps-réel comme Xenomai, c'est que c'est assez simple à mettre en oeuvre, et ça demande peu de modifications pour un bon programme.
http://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-appli(...)
Pour optimiser les I/O, quelques pistes :
* écriture vectorisé (writev) : ça permet au noyau d'optimiser les I/O, les opérations sont atomiques, en général ça pulse bien. C'est une technique souvent utilisée dans la vision industrielle.
* écriture asynchrone (man aio.h) : ça revient plus ou moins à l'idée de Christophe d'une gestion concurrente des écritures sans l'overhead lié à la gestion des threads. Un excellent article sur la question :
http://www.ibm.com/developerworks/linux/library/l-async/?ca=(...)