> Ca ne veut absolument rien dire au niveau du temps reel dur ca.
Ça tombe bien, je ne répond pas à un commentaire qui parle de temps réel dur.
Il y a des Linux temps réel dur qui sont de hautes volées et très utilisés.
> des _garanties_ au niveau du temps de reponse de ses APIs.
T'es sûr de ça ?
Garantir un temps de réponse pour un read() ou write() sur un disque dur je n'y crois pas 2 millième de seconde. Et pour le réseau tu peux carrément oublier ça. De même pour malloc() (sauf si tu ne passe pas par la vm classique). Pour la communication avec les périphériques, ça dépend du périphérique. Il n'y a que ce qui est relatif aux intéruptions où tu as une "garantie" (et il y a des "conditions").
Notes que les ordonnanceurs fifo et Round Robin (disponible dans un linux vanilla) sont des ordonnanceurs temps réel. Avec ça et Linux 2.6 il y a déjà de bonnes performances. Par contre il faut faire attention périphériques utilisés. Certains ons tendance a tout monopoliser un peu trop longtemps.
Un Linux 2.6 vanilla est déjà bon pour beaucoup mission : http://www.ueidaq.com/press/pressitem.aspx?c=38(...) Until now, the only way to get reasonable Linux responsiveness to interrupts or other critical events as required in data-acquisition, test and automation tasks has been to add a realtime patch available from third-party suppliers. In Linux 2.6, though, several improvements give it inherent performance that approaches that of a realtime system; among these are preemption points in the kernel, an improved scheduler and better synchronization. Now, unless a user's requirements are absolutely hard real time, it might not be necessary to go with a special configuration or patch.
Pour information, HP-UX n'a pas de temps réel dur. Pour SGI je ne sais pas s'il y a du temps réel dur. Idem pour Windows.
[^] # Re: T'as oublié Irix
Posté par itstimetogo . En réponse au journal Unix vs Linux. Évalué à 2.
Ça tombe bien, je ne répond pas à un commentaire qui parle de temps réel dur.
Il y a des Linux temps réel dur qui sont de hautes volées et très utilisés.
> des _garanties_ au niveau du temps de reponse de ses APIs.
T'es sûr de ça ?
Garantir un temps de réponse pour un read() ou write() sur un disque dur je n'y crois pas 2 millième de seconde. Et pour le réseau tu peux carrément oublier ça. De même pour malloc() (sauf si tu ne passe pas par la vm classique). Pour la communication avec les périphériques, ça dépend du périphérique. Il n'y a que ce qui est relatif aux intéruptions où tu as une "garantie" (et il y a des "conditions").
Notes que les ordonnanceurs fifo et Round Robin (disponible dans un linux vanilla) sont des ordonnanceurs temps réel. Avec ça et Linux 2.6 il y a déjà de bonnes performances. Par contre il faut faire attention périphériques utilisés. Certains ons tendance a tout monopoliser un peu trop longtemps.
Un Linux 2.6 vanilla est déjà bon pour beaucoup mission :
http://www.ueidaq.com/press/pressitem.aspx?c=38(...)
Until now, the only way to get reasonable Linux responsiveness to interrupts or other critical events as required in data-acquisition, test and automation tasks has been to add a realtime patch available from third-party suppliers. In Linux 2.6, though, several improvements give it inherent performance that approaches that of a realtime system; among these are preemption points in the kernel, an improved scheduler and better synchronization. Now, unless a user's requirements are absolutely hard real time, it might not be necessary to go with a special configuration or patch.
Pour information, HP-UX n'a pas de temps réel dur. Pour SGI je ne sais pas s'il y a du temps réel dur. Idem pour Windows.