Capacité mémoire tampon D4s : bien inférieure à ce qui est écrit dans le manuel

Démarré par CCD1024, Mai 22, 2014, 12:31:38

« précédent - suivant »
Imprimer
En bas Pages 1 2 3 4 5 6 7 8
Actions de l'utilisateur

Bernard2

#100
Mai 24, 2014, 12:46:15
Citation de: Verso92 le Mai 24, 2014, 12:22:35
Non seulement ce n'est pas très plausible, mais il n'y a aucune raison technique qui pourrait valider cette hypothèse*.
Absolument

restoc

#101
Mai 24, 2014, 12:59:52
Citation de: Verso92 le Mai 24, 2014, 12:22:35
Non seulement ce n'est pas très plausible, mais il n'y a aucune raison technique qui pourrait valider cette hypothèse*.


De toute façon, c'est très simple à vérifier pour tout possesseur du boitier : il suffit de valider/dévalider un MR et de voir si le chiffre de capacité de la mémoire tampon, indiqué par le boitier, change ou pas...
*et même, en partant du principe que l'asservissement en cas de MR soit pénalisant en temps de calcul pour l'AF, cela influera (peut-être...) la cadence max de l'appareil en rafale. Ce qui donnera plus de temps au buffer pour se vider...

Et non , le buffer ne se vide pas tout seul par gravité, c'est le processeur qui contrôle tout le processus donc s'il est pris par du calcul et le temps de réponse des iterrations de l'AF il est scotché. Il ne doit pouvoir  vider le buffer que quand toutes ces taches sont terminées.

Le pb c'est qu'on n'a pas les ordres de grandeur. De plus en rajoutant même une tache de calcul simple de qqs micro secondes pour prendre en charge le MR,  il n'est pas impossible que toute une séquence de code soit différée pour des raisons  de logique de séquence.

Il est donc inutile de spéculer puisque personne ne connait les stratégies du processeur.

Par contre si qqn a un D4S il suffit de tester.
Mais  il faudrait vérifier avec différentes classes d'objectifs mous et rapides car  il peut y avoir des stratégies très variables du logiciel processeur selon qu'il peut aller au bar du coin entre deux réponses de l'objectif.

Bref ce qui ne semble pas plausible ... reste tout à fait possible ;)

Verso92

#102
Mai 24, 2014, 13:05:20 Dernière édition: Mai 24, 2014, 13:11:05 par Verso92
Citation de: restoc le Mai 24, 2014, 12:59:52
Et non , le buffer ne se vide pas tout seul par gravité, c'est le processeur qui contrôle tout le processus [...]

Ça m'étonnerait fort... le vidage du buffer est une tâche complètement décorrélée de l'acquisition de l'image.
Citation de: restoc le Mai 24, 2014, 12:59:52
Il ne doit pouvoir  vider le buffer que quand toutes ces taches sont terminées.

Je vois mal ce qui te permet de dire ça...
(dans les modules électroniques que j'ai développé ces dernières années, le processeur central ne s'occupe pas de ce genre de tâches...)

frazap

#103
Mai 24, 2014, 13:10:32
Citation de: restoc le Mai 24, 2014, 12:59:52
Et non , le buffer ne se vide pas tout seul par gravité, c'est le processeur qui contrôle tout le processus donc s'il est pris par du calcul et le temps de réponse des iterrations de l'AF il est scotché. Il ne doit pouvoir  vider le buffer que quand toutes ces taches sont terminées.
Il y a peut être plusieurs proc ou co-proc dans l'Expeed 4.

Verso92

#104
Mai 24, 2014, 13:12:05
Citation de: frazap le Mai 24, 2014, 13:10:32
Il y a peut être plusieurs proc ou co-proc dans l'Expeed 4.

La gestion du buffer est vraisemblablement une tâche dévolue à l'Expeed, effectivement...

restoc

#105
Mai 24, 2014, 16:22:17
Citation de: Verso92 le Mai 24, 2014, 13:05:20
Ça m'étonnerait fort... le vidage du buffer est une tâche complètement décorrélée de l'acquisition de l'image.
Je vois mal ce qui te permet de dire ça...
(dans les modules électroniques que j'ai développé ces dernières années, le processeur central ne s'occupe pas de ce genre de tâches...)

C'est pluôt l'inverse qui me paraitrait anormal : que le processeur se débarrasse des données vers le buffer ou des coprocs et passe à autre chose sans vérification . En gros ne fasse que du push  en aveugle sans se préoccuper de ce qui se passe derrière.

Si on admet que le cahier des charges minimal du boitier est qu'il hors de question qu'une seule image soit perdue entre le moment où le processeur envoie une image dans le buffer et le moment où il est sûr qu'il peut en envoyer une autre sans risque d'écraser les précédentes,  le processeur central est obligé d'attendre les Acks remontant du buffer ou de la CM , notamment quand le buffer approche du remplissage. Qu'il  gère ou pas directement le bus de données, ok, comme dans les transferts de disque ou de ram dans un PC soustraites à des chips spécialisés , mais forcémment le processeur surveille l'ensemble de l'éxécution et que toute la tripaille a bien mis les images en sécurité. Or ces Acks sont asynchrones ( sur le fonctionnement global de l'APN) car ils dépendent de la vitesse de la CM, des tailles de fichier, de taux d'occupation des bus par les process ... et en amont de la mécanique des moteurs et de l'obtu .

En fait il ne faut pas parler du "processeur" on devrait plutôt parler d'UC du boitier. Et celle ci gère bien l'acquisition , le processing et le stockage et doit bien synchroniser tout le monde y compris les éléments mécaniques.

Si M Nikon voulait bien publier la charte worklogic de ses UC ...  .


Botticelli

#106
Mai 24, 2014, 16:31:27
Citation de: restoc le Mai 24, 2014, 16:22:17
Si M Nikon voulait bien publier la charte worklogic de ses UC ...  .

Norsorex l'a, mais il ne peut pas la montrer  ;D ;D

Bon, qui fait le test proposé par Verso ? Et pourquoi pas sur un autre boîtier qu'un D4s d'ailleurs ? Verso, D700 ou D800 et 24-70 ? ;D
Arrogant, sans limite

Dub

#107
Mai 24, 2014, 16:40:11
J'espère pour ceux qui ont un MR à + ou - 20 que le ralentissement
n'est pas proportionnel à la valeur de ce réglage !!!

;D

Verso92

#108
Mai 24, 2014, 16:46:30 Dernière édition: Mai 24, 2014, 16:52:27 par Verso92
Citation de: restoc le Mai 24, 2014, 16:22:17
C'est pluôt l'inverse qui me paraitrait anormal : que le processeur se débarrasse des données vers le buffer ou des coprocs et passe à autre chose sans vérification . En gros ne fasse que du push  en aveugle sans se préoccuper de ce qui se passe derrière.

Si on admet que le cahier des charges minimal du boitier est qu'il hors de question qu'une seule image soit perdue entre le moment où le processeur envoie une image dans le buffer et le moment où il est sûr qu'il peut en envoyer une autre sans risque d'écraser les précédentes,  le processeur central est obligé d'attendre les Acks remontant du buffer ou de la CM , notamment quand le buffer approche du remplissage. Qu'il  gère ou pas directement le bus de données, ok, comme dans les transferts de disque ou de ram dans un PC soustraites à des chips spécialisés , mais forcémment le processeur surveille l'ensemble de l'éxécution et que toute la tripaille a bien mis les images en sécurité. Or ces Acks sont asynchrones ( sur le fonctionnement global de l'APN) car ils dépendent de la vitesse de la CM, des tailles de fichier, de taux d'occupation des bus par les process ... et en amont de la mécanique des moteurs et de l'obtu .

En fait il ne faut pas parler du "processeur" on devrait plutôt parler d'UC du boitier. Et celle ci gère bien l'acquisition , le processing et le stockage et doit bien synchroniser tout le monde y compris les éléments mécaniques.

Si M Nikon voulait bien publier la charte worklogic de ses UC ...  .

Le processeur central ne fait, en principe, que vérifier le bon séquencement des opérations (respect des cycles). Le seul "discret" dont il a besoin pour surveiller le taux de remplissage de la mémoire tampon, c'est un signal "buffer full". Dans ce cas, il suspendra le séquencement lié à la PdV jusqu'à ce que ce flag repasse à "faux".
L'Expeed et le contrôleur de la carte mémoire n'ont pas besoin qu'on s'occupe de leurs petites affaires. Et puis, les composants mémoires embarquent tout ce qu'il faut pour gérer les écritures/lectures sans conflit.

NORSOREX

#109
Mai 24, 2014, 16:48:33
Citation de: restoc le Mai 24, 2014, 12:59:52
Et non , le buffer ne se vide pas tout seul par gravité, c'est le processeur qui contrôle tout le processus donc s'il est pris par du calcul et le temps de réponse des iterrations de l'AF il est scotché. Il ne doit pouvoir  vider le buffer que quand toutes ces taches sont terminées.

Le pb c'est qu'on n'a pas les ordres de grandeur. De plus en rajoutant même une tache de calcul simple de qqs micro secondes pour prendre en charge le MR,  il n'est pas impossible que toute une séquence de code soit différée pour des raisons  de logique de séquence.

Il est donc inutile de spéculer puisque personne ne connait les stratégies du processeur.

Par contre si qqn a un D4S il suffit de tester.
Mais  il faudrait vérifier avec différentes classes d'objectifs mous et rapides car  il peut y avoir des stratégies très variables du logiciel processeur selon qu'il peut aller au bar du coin entre deux réponses de l'objectif.

Bref ce qui ne semble pas plausible ... reste tout à fait possible ;)
Il y a nombre d'objectifs dont les processeurs internes  ont une "discussion" (micro programme)  différente avec le processeur du boitier.
Un certain nombre d'instructions sont envoyés en fonction notamment de l'ouverture mais aussi de la position des lentilles.
Enfin pour faire simple (pas pour toi car tu as compris) on peut comparer l'ensemble des événements informatiques à un rubik's cube.
L'enregistrement d'un cliché est fait uniquement quand toutes les faces du cube ont la bonne couleur chacune contrairement à ce que pensent certains donc y compris quand le MR est actif.
Le MR n'est pas un offset pur mais une matrice de correction et à ce titre fait partie d'une des faces du cube.
Il est évident qu'il ne s'agit pas d'un cube à 6 faces....
Quand aux fonctions de transfert et aux asservissements, ils sont omni présent dans un D4s il y en a plus d'une centaine, c'est d'ailleurs leurs optimisations qui contribuent largement à la qualité de l'AF et par conséquent à la chasse d'eau du buffer.
;)

Verso92

#110
Mai 24, 2014, 16:54:31
Citation de: Botticelli le Mai 24, 2014, 16:31:27
Bon, qui fait le test proposé par Verso ? Et pourquoi pas sur un autre boîtier qu'un D4s d'ailleurs ? Verso, D700 ou D800 et 24-70 ? ;D

Sur le D700, aucune incidence des MR sur la capacité du buffer.
Citation de: NORSOREX le Mai 24, 2014, 16:48:33
Il y a nombre d'objectifs dont les processeurs internes  ont une "discussion" (micro programme)  différente avec le processeur du boitier.
Un certain nombre d'instructions sont envoyés en fonction notamment de l'ouverture mais aussi de la position des lentilles.
Enfin pour faire simple (pas pour toi car tu as compris) on peut comparer l'ensemble des événements informatiques à un rubik's cube.
L'enregistrement d'un cliché est fait uniquement quand toutes les faces du cube ont la bonne couleur chacune contrairement à ce que pensent certains donc y compris quand le MR est actif.
Le MR n'est pas un offset pur mais une matrice de correction et à ce titre fait partie d'une des faces du cube.
Il est évident qu'il ne s'agit pas d'un cube à 6 faces....
Quand aux fonctions de transfert et aux asservissements, ils sont omni présent dans un D4s il y en a plus d'une centaine, c'est d'ailleurs leurs optimisations qui contribuent largement à la qualité de l'AF et par conséquent à la chasse d'eau du buffer.
;)

Dans ce cas, cela ne fera que ralentir l'acquisition (et la cadence max, éventuellement). La longueur de la rafale ne pourra qu'augmenter, le buffer se vidant à la même vitesse pour des fichiers et type de carte donnés...
(à moins que la matrice de correction des MR, si elle existe bien, soit localisée dans la mémoire du buffer et y occupe plusieurs Mo, ce qui me semble très, très improbable...)

NORSOREX

#111
Mai 24, 2014, 17:50:29
Citation de: Verso92 le Mai 24, 2014, 16:54:31
Sur le D700, aucune incidence des MR sur la capacité du buffer.
Dans ce cas, cela ne fera que ralentir l'acquisition (et la cadence max, éventuellement). La longueur de la rafale ne pourra qu'augmenter, le buffer se vidant à la même vitesse pour des fichiers et type de carte donnés...
(à moins que la matrice de correction des MR, si elle existe bien, soit localisée dans la mémoire du buffer et y occupe plusieurs Mo, ce qui me semble très, très improbable...)
La longueur ??? tu veux dire durée, temps, ? explique STP.

Si on refaisait tout au propre...
Le D4s fait 11 images secondes (des Q quantité de données /  t temps)
Il doit pouvoir envoyer 11xQ vers le buffer en 1 seconde
Le buffer à une capacité totale de Qt = Q x N (Q et N sont variables)
A Qt = full il y a suspension de la PDV
On voit que  tant que Qt < full on tient le 11 img/s
Si on ne peut remplir la carte directement c'est que le facteur temps intervient.
Ou ?
Hypothèses :
Le / les processeurs mettent trop de temps à faire le travail
Le bus qui transmet au buffer n'est pas assez large
le buffer par lui même à un temps de remplissage / vidage trop important
Le bus  qui transmet à la carte mémoire n'est pas assez large
La carte mémoire à un temps d'écriture trop long
La chaine de traitement est asservi (pas de pertes de données) et l'asservissement est trop long
Une ou des unités de traitement ou de calcul font attendre les autres
(Il est évident qu'il s'agit de la somme de plusieurs facteurs qui provoque la saturation)

Si tout le monde est d'accord on continue ?
;)

Verso92

#112
Mai 24, 2014, 17:57:01 Dernière édition: Mai 24, 2014, 18:04:38 par Verso92
Citation de: NORSOREX le Mai 24, 2014, 17:50:29
La longueur ??? tu veux dire durée, temps, ? explique STP.

La longueur de la rafale en nombre d'images (soit la capacité du buffer augmentée de l'espace libéré éventuellement par une carte rapide).
Citation de: NORSOREX le Mai 24, 2014, 17:50:29
Si on refaisait tout au propre...

Pourquoi pas ?
Citation de: NORSOREX le Mai 24, 2014, 17:50:29
Si on ne peut remplir la carte directement c'est que le facteur temps intervient.

Déjà, cette phrase est alambiquée : si on ne peut pas écrire dans la carte directement, c'est que le débit en écriture de la carte est inférieur à celui généré par le boitier. Ni plus, ni moins (d'où la présence de la mémoire tampon, qui, elle présente le débit suffisant en écriture)...

NORSOREX

#113
Mai 24, 2014, 18:06:46
Citation de: Verso92 le Mai 24, 2014, 17:57:01
La longueur de la rafale en nombre d'images (soit la capacité du buffer augmentée de l'espace libéré éventuellement par une carte rapide).

Pourquoi pas ?
Je ne comprend rien ; le mot longueur est inapproprié.
Il n'y a que du temps et de la capacité Mémoire
Le Nb img = 11/s
capacité du Buffer = Qt or Qt n'est pas relatif mais absolu et est indépendant de vt(caM) [vitesse de transmission du bus vers la carte mémoire)
Une carte  rapide n'intervient que pour le facteur temps d'écriture (si on approxime sa traille = à l'infini pour simplifier sinon on peut aussi saturée la carte Mémoire)
;)

Verso92

#114
Mai 24, 2014, 18:08:45
Citation de: NORSOREX le Mai 24, 2014, 18:06:46
Je ne comprend rien ; le mot longueur est inapproprié.
Il n'y a que du temps et de la capacité Mémoire
Le Nb img = 11/s
capacité du Buffer = Qt or Qt n'est pas relatif mais absolu et est indépendant de vt(caM) [vitesse de transmission du bus vers la carte mémoire)
;)

La capacité du buffer, c'est très exactement : "Taille mémoire buffer disponible* / somme des tailles des fichiers".
*cette taille sera éventuellement amputée si une correction de la distorsion ou du bruit est activée : une partie de la mémoire servira de tampon aux calculs de correction.

NORSOREX

#115
Mai 24, 2014, 18:10:17
Citation de: Verso92 le Mai 24, 2014, 18:08:45
La capacité du buffer, c'est très exactement : "Taille mémoire buffer / somme des tailles des fichiers".
Oui et alors ?
;)

Verso92

#116
Mai 24, 2014, 18:12:03
Citation de: NORSOREX le Mai 24, 2014, 18:10:17
Oui et alors ?
;)

Alors rien... juste que ce que tu a écris au-dessus est alambiqué et incompréhensible, comme d'hab.
Impossible de s'en servir comme base de discussion en l'état...

NORSOREX

#117
Mai 24, 2014, 18:19:21
Pourquoi tu refuse la discussion.
Je te met des noms de variable pour commencer à approcher la fonction de transfert.
C'est que l'on fait pour tout système de traitement.
Si tu n'a pas le niveau, dis le simplement au lieu de me parler de termes alambiqués.
Ce qui se passe dans le D4s n'est pas caractérisé par "rafale" ou longueur" mais par du temps et des quantités.
Les rafales et longueur sont pour les commerciaux et les unités de temps et de quantité pour les techniciens et autres ingénieurs.
C'est comme cela sur toute la planète depuis pas mal de siècles.
C'est le B A BA.
Désolé.
;)

Verso92

#118
Mai 24, 2014, 18:23:12
Déjà, pour commencer de façon sérieuse ce genre de discussion, il faudrait connaitre la capacité du buffer (soit le chiffre "rXX" affiché par le boitier tout correction dévalidée).
Ensuite, en prenant par exemple une taille moyenne de 20 Mo pour un RAW 14 bits, cela fait un débit boitier de 11 x 20 = 220 Mo/s à sa cadence max, que la mémoire tampon accepte sans problème en écriture, par principe.

Selon le tableau de BR mis en lien en début de fil, la carte Sony approche le 100 Mo/s en écriture.
Voilà les bases pour le calcul...

jpb10

#119
Mai 24, 2014, 19:31:59
Bien, je vous apporte mon expérience : je possède un D4S et une carte Sony série S (donnée pour 180 M0/s en lecture/écriture), je fais de la photo de sport (foot en ligue 2) j'utilise parfois la rafale, je suis en nef 14 bits et avec très peu de corrections, le 400 2,8 ne m'a pas obligé à faire de micro-réglage et le 24-70 2,8 non plus et franchement je ne me préoccupe pas de qui fait quoi dans le boîtier et comment ! Avec une rafale toutes les photos sont nettes (sur environ 8 images à la suite), et je ne fait pas de rafales pendant plus de 1-2 secondes mais j'apprécie pouvoir faire plusieurs rafales à la suite sans attendre que tout soit écrit sur la carte. Maintenant je ne l'ai jamais poussé au-delà de mes besoins. Mais ce que je peux dire que je suis très satisfait de ce boîtier et de ses performances. Je ne suis pas doudoumaniaque, j'utilise un boîtier qui me convient dans le sport ou l'animalier. Pour la photo studio, j'apprécie la balance des blancs. Ce n'est que le résultat de mon expérience et d'autres utilisateurs peuvent avoir des avis différents. Autre chose en vidéo 1080P à 60 images/secondes : génial !
En espérant que cet avis puisse servir, je vous souhaite une bonne journée à tous.
JP Blanchard (jpb10)

bitere

#120
Mai 24, 2014, 21:49:50
Citation de: jpb10 le Mai 24, 2014, 19:31:59
En espérant que cet avis puisse servir, je vous souhaite une bonne journée à tous.
Non , ça sert à rien.
Ca sert à rien.
A rien.

Vade retro satanas.

;D ;D ;D

suliaçais

#121
Mai 24, 2014, 22:34:19

  à quoi ça sert de résister.....se faire du mal........qu'il est bon ce 4s !!!!!!!    ;) ;) ;)

Kadobonux

#122
Mai 24, 2014, 22:39:21
Citation de: suliaçais le Mai 24, 2014, 22:34:19
  à quoi ça sert de résister.....se faire du mal........qu'il est bon ce 4s !!!!!!!    ;) ;) ;)

je pense que notre ami va resister encore 8 semaines  ;D ;D

CCD1024

#123
Mai 24, 2014, 23:32:23
Eh beh, un fil qui fait couler de l'encre.

je suis curieux de lire la suite des explications de NORSOREX.
je ne m'attendais pas à ce que les MR influent sur la rafale. Par contre les corrections D-light., auto-ISO, vignettage, réduction de bruit,... sont bien sur des sources de latence sans compter la taille des images.

Bon, c'est vrai que les rafales c'est plutot quelques images. Disons 5 à 10 mais c'est bien d'être prêt aussitot.

ici des essais sur une bicquette qui faisait de la lévitation  :D





bitere

#124
Mai 24, 2014, 23:32:35
J'avais presque craqué  ;)
Et notre ami de LBPN m'a dit de ne pas hésiter trop longtemps, sinon je devrais prendre un D5.  ;D
Mais non, ce sera le D5s, l'expérience montre que le "s" est tellement mieux  ;D
En attendant j'essaie de me familiariser avec le 10-24 de Fuji  :-\ ???
Imprimer
En haut Pages 1 2 3 4 5 6 7 8
Actions de l'utilisateur