Grosses ecritures disque sous debian : ralentissements
12 réponses
Francois-Philippe Il Grande
Bonjour,
je ne suis pas sur d'etre sur le bon newsgroup pour cette question, mais je la
pose quand meme.
J'ai ecrit un programme qui doit effectuer de grosses ecritures sur le disque
dur, hors sous debian, les ecritures sont bufferisees pendant un certain temps
puis pratiquement tout s'arrete le temps d'ecrire sur le disque et, une fois
l'ecriture terminee, ca recommence a bufferiser.
Le probleme c'est que je dois ecrire en temps reel sur le disque, j'ai essaye
d'utiliser l'appel systeme fsync (force l'ecriture) dans mon programme a
intervalle regulier, cela ameliore sensiblement le probleme mais ce n'est pas
parfait.
La raison pour laquelle je poste cette question ici est que je n'ai pas ce
probleme sous Redhat, donc il doit y avoir quelque chose a configurer pour ca.
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait d'un
grand secour.
On Mon, 14 Jul 2003 14:44:29 +0200, Francois-Philippe Il Grande wrote:
On Mon, 14 Jul 2003 00:54:35 +0200 "J. Mayer" wrote:
Les seuls cas ou la bufferisation pose des problemes sont: - la gestion des devices amovibles - la gestion de bases de donnees qui necessitent des ecritures synchronisees pour pouvoir gerer les logs/rollback... de facon ultra-fiable. Sinon, la bufferisation est toujours un bienfait, et un sync doit etre quelque chose de rarissime dans la vie d'une machine.
Dans mon cas, je fais de la capture sur un peripherique video, donc quand le systeme arrete tout pour ecrire, mon programme ne peut plus capturer et perd des images, et quand je fais des fdatasync, je perd les images qui correspondent au moment ou l'appel systeme est effectue.
Si les fichiers que tu cree sont destines a etre relus par une
application specifique, tu peux aussi utiliser une partition en raw. Dans ce cas, tu n'as pas de filesystem, pas de bufferisation. Tu dois tout gerer a la main, mais tu controles tout. C'est exactement ce que font les bases de donnees pro. Mais, en ce qui concerne la capture, tu n'as pas a la faire a la main, en principe. v4l a une interface qui permet de dire a la carte d'acquisition d'aller directement ecrire dans un buffer en mode bus-master. Je pense que tu peux faire en sorte d'avoir plusieurs images bufferisees de cette facon. Dans ce cas, si tu ecris les images raw sur le disque, il n'y a meme pas de recopie a faire: le controleur disque lira en DMA a l'endroit ou la carte d'acquisition a depose les donnees. Je crois que c'est l'ioctl VIDIOCCAPTURE qui permet cela. Apres, tu n'as rien a faire: la capture se fait toute seule, meme si ton programme n'a pas la main... Je ne connais pas bien v4l, mais tu devrais trouver des infos facilement.
Cordialement.
J. Mayer
On Mon, 14 Jul 2003 14:44:29 +0200, Francois-Philippe Il Grande wrote:
Les seuls cas ou la bufferisation pose des problemes sont:
- la gestion des devices amovibles
- la gestion de bases de donnees qui necessitent des ecritures
synchronisees pour pouvoir gerer les logs/rollback... de facon
ultra-fiable.
Sinon, la bufferisation est toujours un bienfait,
et un sync doit etre quelque chose de rarissime dans la vie
d'une machine.
Dans mon cas, je fais de la capture sur un peripherique video,
donc quand le systeme arrete tout pour ecrire, mon programme ne peut plus
capturer et perd des images, et quand je fais des fdatasync, je perd les images
qui correspondent au moment ou l'appel systeme est effectue.
Si les fichiers que tu cree sont destines a etre relus par une
application specifique, tu peux aussi utiliser une partition
en raw. Dans ce cas, tu n'as pas de filesystem, pas de bufferisation.
Tu dois tout gerer a la main, mais tu controles tout.
C'est exactement ce que font les bases de donnees pro.
Mais, en ce qui concerne la capture, tu n'as pas a la faire a la
main, en principe. v4l a une interface qui permet de dire
a la carte d'acquisition d'aller directement ecrire dans un buffer
en mode bus-master. Je pense que tu peux faire en sorte d'avoir
plusieurs images bufferisees de cette facon. Dans ce cas, si tu
ecris les images raw sur le disque, il n'y a meme pas de recopie
a faire: le controleur disque lira en DMA a l'endroit ou la carte
d'acquisition a depose les donnees.
Je crois que c'est l'ioctl VIDIOCCAPTURE qui permet cela.
Apres, tu n'as rien a faire: la capture se fait toute seule,
meme si ton programme n'a pas la main...
Je ne connais pas bien v4l, mais tu devrais trouver des infos
facilement.
On Mon, 14 Jul 2003 14:44:29 +0200, Francois-Philippe Il Grande wrote:
On Mon, 14 Jul 2003 00:54:35 +0200 "J. Mayer" wrote:
Les seuls cas ou la bufferisation pose des problemes sont: - la gestion des devices amovibles - la gestion de bases de donnees qui necessitent des ecritures synchronisees pour pouvoir gerer les logs/rollback... de facon ultra-fiable. Sinon, la bufferisation est toujours un bienfait, et un sync doit etre quelque chose de rarissime dans la vie d'une machine.
Dans mon cas, je fais de la capture sur un peripherique video, donc quand le systeme arrete tout pour ecrire, mon programme ne peut plus capturer et perd des images, et quand je fais des fdatasync, je perd les images qui correspondent au moment ou l'appel systeme est effectue.
Si les fichiers que tu cree sont destines a etre relus par une
application specifique, tu peux aussi utiliser une partition en raw. Dans ce cas, tu n'as pas de filesystem, pas de bufferisation. Tu dois tout gerer a la main, mais tu controles tout. C'est exactement ce que font les bases de donnees pro. Mais, en ce qui concerne la capture, tu n'as pas a la faire a la main, en principe. v4l a une interface qui permet de dire a la carte d'acquisition d'aller directement ecrire dans un buffer en mode bus-master. Je pense que tu peux faire en sorte d'avoir plusieurs images bufferisees de cette facon. Dans ce cas, si tu ecris les images raw sur le disque, il n'y a meme pas de recopie a faire: le controleur disque lira en DMA a l'endroit ou la carte d'acquisition a depose les donnees. Je crois que c'est l'ioctl VIDIOCCAPTURE qui permet cela. Apres, tu n'as rien a faire: la capture se fait toute seule, meme si ton programme n'a pas la main... Je ne connais pas bien v4l, mais tu devrais trouver des infos facilement.
Cordialement.
J. Mayer
J. Mayer
On Mon, 14 Jul 2003 14:49:54 +0200, Francois-Philippe Il Grande wrote:
On Mon, 14 Jul 2003 10:40:58 +0200 nicolas wrote:
Le dernier Linux Mag a un article parlant de GNU/Linux en temps réeel. Peut-être qu'il va t'aider ?
L'article dit qu'il faut récupérer des patchs avant de compiler le noyau exprès pour le temps réel.
Interessant, merci pour l'info, je vais m'empresser de l'acheter.
A noter que Linux temps reel est un patch instable et non-officiel. L'architecture de Linux n'est pas du tout celle d'un noyau temps reel et sa conception ne le destine pas a cette usage. Pour ce genre de choses, il faut plus regarder du cote des micros noyaux genre QNX (peut etre Hurd ?).
Mais, pour capturer de la video a 25, voire 50 fps, un noyau temps reel n'est pas d'une grande utilite. Le besoin d'un noyau temps reel est plus de garantir des synchronisations a la milli voire micro-seconde pres, ou de garantir la synchronisation de sous systemes du style pilotage d'une machine a commande numerique. C'est tres loin des contraintes, finalement faibles, de la capture video. Ca pourrait etre le cas sur des processeurs tres lent -> quelque Mhz, mais sur un PC moderne... Tu as des millions de cycle processeur pour traiter une frame ! Pas de grosses contraintes, donc.
Cordialement.
J. Mayer
On Mon, 14 Jul 2003 14:49:54 +0200, Francois-Philippe Il Grande wrote:
On Mon, 14 Jul 2003 10:40:58 +0200
nicolas <nicolas.patrois@online.fr> wrote:
Le dernier Linux Mag a un article parlant de GNU/Linux en temps réeel.
Peut-être qu'il va t'aider ?
L'article dit qu'il faut récupérer des patchs avant de compiler le noyau
exprès pour le temps réel.
Interessant, merci pour l'info, je vais m'empresser de l'acheter.
A noter que Linux temps reel est un patch instable et non-officiel.
L'architecture de Linux n'est pas du tout celle d'un noyau temps reel
et sa conception ne le destine pas a cette usage.
Pour ce genre de choses, il faut plus regarder du cote des micros
noyaux genre QNX (peut etre Hurd ?).
Mais, pour capturer de la video a 25, voire 50 fps, un noyau
temps reel n'est pas d'une grande utilite. Le besoin d'un noyau temps
reel est plus de garantir des synchronisations a la milli voire
micro-seconde pres, ou de garantir la synchronisation de sous systemes
du style pilotage d'une machine a commande numerique.
C'est tres loin des contraintes, finalement faibles, de la capture
video. Ca pourrait etre le cas sur des processeurs tres lent ->
quelque Mhz, mais sur un PC moderne... Tu as des millions de cycle
processeur pour traiter une frame ! Pas de grosses contraintes,
donc.
On Mon, 14 Jul 2003 14:49:54 +0200, Francois-Philippe Il Grande wrote:
On Mon, 14 Jul 2003 10:40:58 +0200 nicolas wrote:
Le dernier Linux Mag a un article parlant de GNU/Linux en temps réeel. Peut-être qu'il va t'aider ?
L'article dit qu'il faut récupérer des patchs avant de compiler le noyau exprès pour le temps réel.
Interessant, merci pour l'info, je vais m'empresser de l'acheter.
A noter que Linux temps reel est un patch instable et non-officiel. L'architecture de Linux n'est pas du tout celle d'un noyau temps reel et sa conception ne le destine pas a cette usage. Pour ce genre de choses, il faut plus regarder du cote des micros noyaux genre QNX (peut etre Hurd ?).
Mais, pour capturer de la video a 25, voire 50 fps, un noyau temps reel n'est pas d'une grande utilite. Le besoin d'un noyau temps reel est plus de garantir des synchronisations a la milli voire micro-seconde pres, ou de garantir la synchronisation de sous systemes du style pilotage d'une machine a commande numerique. C'est tres loin des contraintes, finalement faibles, de la capture video. Ca pourrait etre le cas sur des processeurs tres lent -> quelque Mhz, mais sur un PC moderne... Tu as des millions de cycle processeur pour traiter une frame ! Pas de grosses contraintes, donc.
