FR2778992A1 - Procede de determination de performances d'un systeme de traitement de l'information multiprocesseur - Google Patents

Procede de determination de performances d'un systeme de traitement de l'information multiprocesseur Download PDF

Info

Publication number
FR2778992A1
FR2778992A1 FR9806362A FR9806362A FR2778992A1 FR 2778992 A1 FR2778992 A1 FR 2778992A1 FR 9806362 A FR9806362 A FR 9806362A FR 9806362 A FR9806362 A FR 9806362A FR 2778992 A1 FR2778992 A1 FR 2778992A1
Authority
FR
France
Prior art keywords
resources
processors
multiprocessor system
model
parameters
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR9806362A
Other languages
English (en)
Other versions
FR2778992B1 (fr
Inventor
Sylvain Huyet
Georges Keryvel
Jean Francois Lemerre
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SA
Original Assignee
Bull SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SA filed Critical Bull SA
Priority to FR9806362A priority Critical patent/FR2778992B1/fr
Publication of FR2778992A1 publication Critical patent/FR2778992A1/fr
Application granted granted Critical
Publication of FR2778992B1 publication Critical patent/FR2778992B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3447Performance evaluation by modeling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Computer Hardware Design (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Multi Processors (AREA)
  • Hardware Redundancy (AREA)

Abstract

L'invention concerne un procédé de détermination de performances d'un système multiprocesseur comportant des verrous garantissant des accès exclusifs à des données partagées. On construit un premier modèle partiel constitué d'une station (4) comprenant une file d'attente (40) et un serveur (41) représentant le système multiprocesseur dépourvu de verrous et on résout ce modèle. On construit un jeu de seconds modèles partiels, constitués chacun d'une station (5a -5m ) comprenant une file d'attente (50a -50m ) et un serveur (51 a -51 m ), représentant chacun un des verrous. On construit et résout, à partir de ces deux séries de modèles partiels, un modèle global (7) représentant le système multiprocesseur, de manière à obtenir en sortie (S') les performances du système multiprocesseur incluant les verrous, pour un nombre de processeurs variable.

Description

I 2778992
PROCEDE DE DETERMINATION DE PERFORMANCES D'UN
SYSTEME DE TRAITEMENT DE L'INFORMATION
MULTIPROCESSEUR
La présente invention concerne un procédé de détermination de performances d'un système de traitement de l'information multiprocesseur. Elle concerne plus particulièrement un procédé de détermination de performances d'un système de traitement de l'information multiprocesseur dont l'architecture est d'un type dit "NUMA" (de l'anglo-saxon "Non Uniform Memory
Access"), architecture qui sera définie ci-après de façon plus précise.
Comme il est bien connu dans le domaine informatique, il est possible d'augmenter la puissance d'une machine en augmentant le nombre de processeurs dont elle est composée. Un type de machine connu sous le nom "SMP" (de l'anglo-saxon "Symetrical MultiProcessor" ou multiprocesseur symétrique) permet aux différents processeurs d'une même machine d'accéder de façon symétrique à sa mémoire au moyen d'un bus système. Ce sont des machines avec mémoire à accès uniforme dans la mesure o le temps d'accès
à la mémoire est sensiblement le même pour toutes les données accédées.
Pour cette raison, I'architecture est dite "UMA" (de l'anglo-saxon
"Uniform Memory Access" ou accès uniforme à la mémoire).
La figure 1 annexée à la présente description illustre
schématiquement un exemple d'architecture du type "UMA".
- Le système de traitement de l'information 1, que l'on appellera ci-
après module "SMP", comprend un certain nombre d'unités centrales ou processeurs ou encore "CPU" selon la terminologie anglo-saxonne. On a représenté quatre unités centrales dans l'exemple de la figure 1: 10 à 13. On associe à ces unités centrales 10 à 13, une mémoire centrale 14 accessible
par tous. Le bus système n'a pas été représenté sur la figure 1.
Puisque tous les accès s'effectuent à l'intérieur du module 1, c'est-à-
dire en local, et si l'espace mémoire total disponible présente une homogénéité quant au temps d'accès (ce qui constitue l'hypothèse de départ, puisqu'il s'agit d'une architecture "UMA"), le temps d'accès reste sensiblement le même,
quelle que soit l'unité centrale, 10 à 13, qui effectue une requête.
Bien que, sur la figure 1, il ait été représenté quatre unités centrales à 13, il doit être clair que ce nombre est tout à fait arbitraire. Il peut être augmenté ou diminué. Cependant, la courbe de performances de telles
machines ne croit pas de façon linéaire en fonction du nombre de processeurs.
Un nombre élevé de processeurs implique en réalité que le système consomme plus de temps pour accéder aux ressources. Ceci a pour conséquence d'infléchir la courbe de performances lorsque le nombre de processeurs
augmente. L'état de la technique propose différentes solutions à ce problème.
Une solution connue consiste à regrouper en grappes plusieurs
o10 machines de façon à les faire communiquer entre elles au moyen d'un réseau.
Chaque machine possède son propre système d'exploitation avec un nombre optimal de processeurs, par exemple quatre. Elle établit une communication avec une autre machine toutes les fois qu'elle effectue un traitement sur des données détenues à jour par cette autre machine. Le temps nécessaire à ces communications et la nécessité de travailler sur des données de mémoires cohérentes posent des problèmes de latence pour des applications volumineuses telles que, par exemple, les applications réparties qui demandent de nombreuses communications. La latence est la durée qui sépare l'instant d'émission d'une requête d'accès à la mémoire et l'instant
auquel la réponse à cette requête est reçue.
Une autre solution connue est celle des machines à architecture du type précité "NUMA". Ce sont des machines avec mémoire à accès non uniforme, dans la mesure o le temps d'accès à la mémoire varie selon la localisation des données accédées. Une machine de type "NUMA" est constituée de plusieurs modules, chaque module comprenant un nombre optimal de processeurs et une partie de la mémoire physique totale de la machine. Une telle machine est à accès mémoire non uniforme car un module accède généralement plus facilement et plus rapidement à une partie physique de la mémoire, si celle-ci est une mémoire locale. Bien que chaque module possède un bus système privé reliant ses processeurs et sa mémoire physique, un système d'exploitation commun à tous les modules permet de considérer l'ensemble des bus systèmes privés comme un seul et unique bus système de la machine. Un adressage logique affecte un lieu de résidence à un emplacement de mémoire physique déterminé d'un module. Pour un processeur considéré, on distingue les accès à une partie de mémoire locale,
3 2778992
située physiquement sur le même module que le processeur, et les accès à une partie de mémoire distante, située physiquement sur un ou plusieurs
autres modules que celui o est situé le processeur.
La figure 2 annexée à la présente description illustre
schématiquement un exemple d'architecture de ce type, c'est-à-dire une architecture "NUMA". Pour simplifier le dessin, on a supposé que le système de traitement de l'information 1' comprend seulement deux modules, Ma et Mb, du type "SMP" précité, et que les deux modules étaient identiques. Il doit cependant être bien compris que le système de traitement de l'information 1' l1 peut comporter un plus grand nombre de modules et que les modules Ma et Mb, peuvent être différents (notamment en ce qui concerne le nombre d'unités centrales). Dans l'exemple décrit sur la figure 2, le module Ma comprend quatre unités centrales 10a à 13a, et une mémoire centrale 14a. De même, le module Mb comprend quatre unités centrales 1Ob à 13b, et une mémoire centrale 14b. Les deux mémoires 14a et 14b, (et de façon plus générale les n mémoires centrales) communiquent entre elles à l'aide de ce qui est appelé un "lien" 2. On prévoit généralement des antémémoires ("cache memories", selon la terminologie naglosaxonne), dites éloignées, 15a et 15b, respectivement, qui 2 0 permettent une gestion plus efficace de la cohérence des données de mémoire. Le lien 2 ne se résume pas à de simples liaisons physiques mais comprend des circuits électroniques divers classiques (circuits de commande,
d'interface, etc.), qu'il est inutile de décrire plus avant.
On comprend aisément que, dans une telle architecture, si une application s'exécute dans le module Ma, par exemple, le temps d'accès à la mémoire "proche" 14a (accès en local) est, a priori, inférieur au temps d'accès à la mémoire "éloignée" 14b, située dans le module Mb, ce quelle que soit l'unité centrale 10a à 13a, concernée. Il est notamment nécessaire de passer par le lien 2, lorsque les données sont physiquement stockées dans un autre
3 0 module, ce qui augmente sensiblement le temps de transfert.
Lorsqu'on désire connaître à l'avance les performances d'un système multiprocesseur de traitement de l'information donné, il existe plusieurs procédés. L'un des procédés connus consiste à établir un modèle qui tient compte des composants matériels et de leurs caractéristiques: processeurs, bus, bancs d'antémémoires, etc. De façon plus précise, un des procédés connus fait appel à une modélisation à base de réseaux de files d'attente. Un tel procédé est décrit, par exemple, dans le livre de D. FERRARI et al., intitulé "Measurement and Tuning of Computer Systems", publié par Prentice-Hall, en 1983, plus particulièrement par référence à la section 9.4 du
chapitre 9 ("Queuing Models").
Il est également utile de tenir compte de l'influence des composants logiciels. Cette influence peut être mise en évidence par la mesure d'un
paramètre connu sous l'expression "miss rate", selon la terminologie anglo-
saxonne, c'est-à-dire un taux représentant le nombre de fois o une donnée
accédée n'est pas présente dans une mémoire, notamment une antémémoire.
En effet, lorsqu'un des processeurs du système multiprocesseur recherche une donnée dans une antémémoire et que celle-ci est effectivement présente à l'emplacement accédé, I'opération est réussie. On la qualifie de "hit", selon la terminologie anglo-saxonne. Dans le cas contraire, on parle de "miss". Cela implique que le processeur doive chercher la donnée dans un autre emplacement de mémoire, d'o un temps d'opération supplémentaire. Il s'ensuit une dégradation des performances du système par l'apparition de
temps de latence plus importants.
Pour une machine déterminée ou une machine d'une génération précédente, le taux de "miss" peut être mesuré, dans des contextes matériel et logiciel donnés. Il est donc loisible de constater l'évolution des performances du système en fonction notamment du nombre de processeurs. Il n'est cependant pas possible d'établir des lois permettant de prédire avec suffisamment de précision les performances d'un système multiprocesseur comportant plus de processeurs que ceux pour lesquels les performances sont connues ou mesurées. Il n'est notamment pas possible d'extrapoler avec
suffisamment de précision le taux de "miss" précité.
Comme il a été précédemment suggéré, les performances d'un système multiprocesseur sont liées étroitement au nombre de processeurs. On
obtient naturellement une augmentation corrélative de la puissance de calcul.
Cependant, I'amélioration des performances d'un système, au-delà d'un
nombre optimal de processeurs, devient problématique.
Ceci est dû essentiellement à des instructions de type partagé, dites de verrou ou "lock", selon la terminologie anglo-saxonne. De façon générale, un verrou sert à garantir un accès exclusif à une ou plusieurs données partagées du système dans un environnement multiprocesseur, données dites "globales". En effet, puisque les mémoires doivent être partagées entre plusieurs processeurs, des sécurités doivent être mises en place, afin d'assurer la cohérence, ce qui se traduit par un temps d'accès moyen aux données plus important. En d'autre termes, il existent des temps
supplémentaires variables ou temps perdus dûs aux verrous.
Par ailleurs, on admet généralement que, pour un système
monoprocesseur, I'influence des verrous est négligeable.
L'invention se fixe pour but un procédé de détermination des performances d'un système multiprocesseur, quel que soit le nombre de
processeurs mis en oeuvre.
Pour ce faire, I'invention tire parti des particularités énoncées ci-
dessus. Elle consiste, en premier lieu, à déterminer deux jeux de modèles décrivant le système multiprocesseur. Un premier jeu est constitué par un modèle qui décrit le système multiprocesseur en l'assimilant à un système monoprocesseur, c'est-à-dire à un système multiprocesseur n'exécutant pas 2o d'instructions de verrou. On résout le premier modèle en utilisant des paramètres d'entrée déterminés de la façon qui sera précisée ci-après. Il est clair que le système obtenu n'est plus cohérent avec la réalité. Cependant, il donne des résultats qui sont extrapolables, quel que soit le nombre de processeurs mis en oeuvre. On détermine un deuxième jeu de modèles décrivant les différents verrous individuels existants dans le système multiprocesseur. Ce second jeu de modèles donne également des résultats extrapolables en fonction du nombre de processeurs accédant à chacun des verrous. On construit ensuite un modèle composite à partir de ces deux jeux de modèles. Ce dernier modèle donne aussi des résultats extrapolables. Les deux jeux de modèles sont déterminés en faisant appel à un procédé à base de
réseaux de files d'attente.
De façon plus générale, en lieu et place des verrous, on peut considérer un jeu de ressources prédéterminé que l'on désire exclure du premier jeu de modèles. De façon plus précise, on considère que le système
6 2778992
comporte des premier et second jeux de ressources, seul le premier étant incldu
dans le premier jeu de modèle, que l'on appellera partiel.
L'invention a donc pour objet un procédé de détermination de performances d'un système de traitement de l'information multiprocesseur comprenant un nombre n déterminé de processeurs, ledit système comportant des premier et second jeux de ressources, le second jeu comprenant au moins une ressource déterminée, caractérisé en ce qu'il comprend au moins les étapes suivantes: - a/ acquisition de premiers paramètres caractérisant la configuration dudit système multiprocesseur dépourvu du second jeu de ressources; - b/ construction d'un premier modèle partiel paramétrable, constitué d'un réseau de stations comprenant chacune une file d'attente et un serveur représentant ledit système multiprocesseur dépourvu du second jeu de ressources, ledit premier modèle partiel recevant, sur une entrée de paramétrage, lesdits premiers paramètres acquis; - c/ résolution dudit premier modèle partiel de manière à obtenir une station unique, comprenant une file d'attente et un serveur, équivalente audit système dépourvu du second jeu de ressources; - d/ acquisition de séries de seconds paramètres, chaque série de 2 0 paramètres caractérisant une desdites ressources du second jeu; - e/ construction d'un jeu de seconds modèles partiels paramétrables, constitués chacun d'une station comprenant une file d'attente et un serveur, chacun desdits seconds modèles partiels représentant une desdites ressources du second jeu et recevant, sur une entrée de paramétrage, une desdites séries de seconds paramètres acquis; f/ construction d'un modèle global représentant ledit système multiprocesseur, en reliant ledit serveur dudit premier modèle partiel à toutes les files d'attente desdits second modèles partiels et les serveurs de ces modèles à la file d'attente du premier modèle partiel; et - g/ résolution dudit modèle global ainsi construit, en paramétrant le premier modèle partiel à l'aide d'au moins un paramètre supplémentaire d'entrée acquis caractérisant l'occurrence des accès auxdites ressources du second jeu par lesdits processeurs, de manière à obtenir en sortie du modèle global lesdites performances du système multiprocesseur
comportant ledit second jeu de ressources.
L'invention sera mieux comprise et d'autres caractéristiques et
avantages apparaîtront à la lecture de la description qui suit, en référence aux
figures annexées, parmi lesquelles: - la figure 1 illustre schématiquement une architecture de système de traitement de l'information à architecture du type dit "UMA", constitué par un module du type dit "SMP"; - la figure 2 illustre schématiquement une architecture de système de traitement de l'information à accès de mémoire non uniforme dite "NUMA" comprenant plusieurs modules "SMP" selon la figure 1; - la figure 3 illustre schématiquement un modèle représentant un module
"SMP";
- et la figure 4 illustre schématiquement un modèle complet conforme au
procédé de l'invention, représentant un système multiprocesseur.
On va tout d'abord rappeler brièvement comment on peut construire un modèle décrivant un système multiprocesseur, par exemple un des modules
de type "SMP" de la figure 2, Ma ou Mb.
Selon un des procédés connus en modélisation, décrit dans le livre de D. FERRARI précité et illustré schématiquement par la figure 3, le modèle 3, que l'on appelera "station de travail" ci-après, se présente sous la forme d'une file d'attente 30, en entrée d'un serveur 31. Les différents processeurs du module "SMP", en nombre arbitrairement égal à n, référencés UC1 à UCn, constituent des "clients" accédant au même serveur 31. La file d'attente 30 a donc autant d'entrées, el à en, que de processeurs, UC1 à UCn, désirant accéder au serveur 31. En fonction de la charge de travail instantanée du système, les requêtes s'accumulent dans la file d'attente 30 et sont traitées séquentiellement. Le temps de traitement moyen d'une requête dépend de nombreux paramètres, qui dépendent à leur tour des composants matériels et logiciels du système "SMP". Lorsque le système est monoprocesseur, le temps de
8 2778992
traitement d'une requête ne dépend que des performances de base de celuici: technologie utilisée, capacité d'une antémémoire, type d'instructions, etc. Dans ce cas, et de façon pratique, on peut considérer que la file d'attente 30 du modèle 3 n'existe pas. Les requêtes sont transmises instantanément au serveur 31. Les performances d'un système monoprocesseur constituent donc
une référence, base de comparaison pour les systèmes multiprocesseurs.
Lorsque le système est réellement multiprocesseur, aux temps de traitement de base, s'ajoutent des "temps perdus" dûs aux différents verrous existant dans le
système, comme il a été indiqué.
De façon classique en soi, pour un système multiprocesseur donné, dont on connaît le nombre de processeurs et aussi une série de paramètres que l'on injecte en entrée de paramétrage de stations selon la figure 3, arrangées en réseaux. La topologie exacte du réseau dépend du nombre et de la nature des organes présents dans le multiprocesseur. On peut résoudre ce réseau de stations à l'aide notamment d'un logiciel de calcul spécialisé pour la résolution de files d'attente. Pour fixer les idées, et sans être exhaustif, il est possible d'utiliser le logiciel du commerce "QNAP2" , distribué par la société "SIMULOG". Le logiciel peut être implanté sur tout appareil de traitement de données à programme enregistré, par exemple un micro-ordinateur à usage
2 0 général.
Les paramètres d'entrée d'une station du modèle sont typiqement les suivants: - capacité de la file d'attente; - politique de gestion des files d'attente (en général du type mémoire "FIFO", 2 5 ou "premier entré - premier sorti"); - loi de service (exponentielle, déterministe ou autre); - temps de service moyen de cette loi, c'est-à- dire le temps de service moyen pour que la requête soit traitée par une ressource donnée;
- description du routage de la requête à la sortie de la station.
3 0 Ces paramètres sont obtenus généralement par des mesures effectuées sur un système existant, comportant un nombre donné de processeurs, égal à n, et peuvent être ajustés par le calcul, en tant que de
besoin. Un exemple de procédé de d'acquisition de paramètres sera détaillé ci-
apres. La résolution du modèle par le logiciel précité donne en sortie des données caractéristiques de la file d'attente. De façon plus précise, on obtient typiquement les données de sortie suivantes: - performances du système multiprocesseur pour un contexte de test considéré, notamment tenant compte du nombre n de processeurs; - rapport entre les performances du système en fonctionnement monoprocesseur et en fonctionnement multiprocesseur (n processeurs), encore appelé paramètre de "scalabilité"; - temps de réponse moyen et taux moyen d'occupation de chacune
des stations de façon à déterminer les points de blocage.
A partir du modèle, on peut déterminer d'autres paramètres, en tant que de besoin. Cette détermination supplémentaire peut être effectuée par le logiciel de résolution de files d'attente "QNAP2" précité, en progammation de
façon appropriée.
Comme il a été indiqué, dans un système multiprocesseur, les performances sont dégradées par les différents verrous existants dans ce 2 0 systèmes. L'augmentation du nombre de processeurs, comme il a été également rappelé, a certes des effets positifs, car elle permet des traitements en parallèle. Cependant, il est clair aussi que les performances d'un système multiprocesseur n'augmentent pas de façon linéaire avec le nombre de processeurs. On assiste rapidement à un "tassement" de la courbe "performances - nombre de processeurs". Un nombre élevé de processeurs implique en réalité que le système consomme plus de temps pour des problèmes d'accessibilité à ses ressources qu'il n'en dispose pour exécuter des applications. Ceci est dû essentiellement à la présence de verrous, et de façon plus générale à l'accessibilité aux ressources. Si pour un système déterminé, comportant un nombre de processeurs connu, par exemple n processeurs (n étant un nombre arbitraire), il est possible de déterminer l'influence des verrous précités, il n'est généralement pas possible de déterminer à l'avance, du moins avec précision, les performances d'un système comprenant un plus grand nombre de processeurs, par exemple n+1 processeurs, et ce même si l'on connaît les caractéristiques successives d'une série de systèmes allant du monoprocesseur au multiprocesseur comportant n processeurs. En d'autres termes, un modèle résolu décrivant un multiprocesseur ayant un nombre de processeurs égal ou inférieur à n processeurs, ne permet pas d'extrapoler les performances d'un multiprocesseur ayant un nombre de processeur supérieur à n, à partir des données calculées (données de sortie du modèle résolu). Ceci est dû notamment au fait que les paramètres d'entrée des modèles sont déterminés 1o par l'expérimentation sur des systèmes physiques existants, comportant un
nombre déterminé de processeurs, par exemple n.
Or, il est du plus grand intérêt de connaître avec précision l'influence sur les performances obtenues de modifications effectuées sur des
composants logiciels particuliers, ce quel que soit le nombre de processeurs.
Cela permet de déterminer qu'elles sont les modifications qu'il est intéressant d'introduire, c'est-à-dire notamment celles donnant les meilleurs résultats, pour des surcoûts faibles, voire inexistants, et/ou un accroissement de complexité acceptable. A titre d'exemple, il est primordial de savoir dans quelle mesure, pour un contexte donné, I'ajout d'un processeur a des effets positifs sur les performances du système, et éventuellement quelles sont les modifications des composants logiciels qu'il convient d'effectuer pour obtenir effectivement ces
effets positifs.
Le procédé selon l'invention va maintenant être décrit de façon plus
détaillée par référence à la figure 4.
Selon une première caractéristique importante de l'invention, le
système multiprocesseur est décrit par deux jeux de modèles de base.
On construit tout d'abord un premier jeu, coprenant une pluralité de stations du type de la figure 3 interconnectées en réseau. Ce premier jeu, une fois résolu, se résume à un modèle unique 4, constitué d'une station équivalente au système multiprocesseur. Cependant, dans ce modèle, et selon une des caractéristiques les plus importantes de l'invention, on ne tient pas compte de l'influence des verrous. En d'autres termes, on part de l'hypothèse que le système n'exécute pas d'instructions de verrous. Le modèle obtenu, considéré seul, n'est naturellement pas cohérent avec un système réel. Le il 2778992 modèle 4 se présente sous une forme similaire à celle illustrée par la figure 3. Il
est constitué d'une station 4 comprenant une file d'attente 40 et un serveur 41.
La résolution du modèle s'effectue de façon classique en injectant des paramètres P4 décrivant le système en l'absence de verrous et en faisant appel, par exemple, à un logiciel de résolution de files d'attente, tel le logiciel "QNAP2" précité. Les paramètres d'entrée sont similaires à ceux précédemment énumérés en regard de la figure 3. On obtient donc une file
d'attente équivalente à un système multiprocesseur démuni de verrous.
Le modèle partiel 4, qui représente essentiellement les lo caractéristiques matérielles du système permet, connaissant les caractéristiques individuelles des composants matériels (mémoires, bus système, processeurs, etc.) d'obtenir les performances du système, toujours sans l'impact des verrous à ce stade, pour un nombre quelconque de processeurs n. Il suffit de procéder à la résolution du modèle pour ce nombre n de processeurs. On peut également procéder à des étapes multiples de résolution de modèles pour n, n+1,...., n+x processeurs et enregistrer ces différents résultats intermédiaires pour une utilisation lors des étapes ultérieures du procédé. La borne supérieure de la gamme des variations de n, c'est-à-dire nmax=n+x, n'est en principe pas limité. Cependant, dans la pratique, on choisit ce nombre de manière à couvrir les cas d'implantation de machine prévisibles de façon réaliste. Enfin, la borne inférieure nmin=n peut être rendue égale à 1 (cas d'un monoprocesseur). On peut également ne considérer qu'une partie des valeurs possibles de n de la gamme bornée précitée. Selon une deuxième caractéristique importante du procédé de l'invention, on construit un second jeu de modèles partiels, chaque modèle de ce jeu étant associé à un des verrous du système. Le second jeu de modèles
porte la référence générale 5 sur la figure 4.
On suppose qu'il existe m verrous dans le système, m étant un nombre arbitraire qui dépend de la configuration exacte du système dans un
contexte donné. Les m modèles décrivant les verrous sont référencés 5a à 5m.
Chaque modèle a une structure similaire à celle représentée sur la figure 3: une station, 5a à 5m comprenant une file d'attente, 50a à 50m, et un serveur,
51a à 51m.
Pour définir ces différents modèles, il est nécessaire tout d'abord d'acquérir les paramètres associés à chacun des verrous d'indices a à m. De nouveau, ces paramètres sont similaires à ceux précédemment énoncés, bien
que se présentant sous une forme généralement plus simplifiée.
L'acquisition proprement dite peut s'effectuer à l'aide d'outils de test informatisés spécialisés, comme il le sera montré ci-après. De façon plus générale, les caractéristiques des verrous sont obtenues par l'expérimentation et des mesures effectuées sur le système multiprocesseur dans un contexte
matériel et logiciel donne.
Comme il vient d'être signalé, concernant les paramètres d'entrée, plusieurs simplifications peuvent être opérées: -la capacité de la file d'entrée, 50a à 50m, de chaque station, 5a à m, peut être fixée par défaut à une capacité infinie. - la politique de gestion de la file d'attente est du type "FIFO"; - la loi de service reste de nature exponentielle, aléatoire, constante ou autre; - le routage est constant, en ce sens qu'il consiste en un retour systématique vers l'entrée de la station équivalente 4, comme il va l'être
indiqué ci-après.
Des paramètres supplémentaires doivent être acquis. pour chaque verrou. Il s'agit, à titre d'exemple, du nombre d'occurrences par unité de temps et du pourcentage de blocage. Ces paramètres serviront dans une étapes
ultérieure, comme il sera explicité ci-après.
Les paramètres acquis servent de données d'entrée de configuration, P5a à P5m, des modèles 5a à 5m, respectivement. On obtient donc m files d'attente équivalentes aux verrous du système. Il n'est cependant
pas nécessaire de résoudre individuellemnt les modèles.
Selon une autre caractéristique importante du procédé de l'invention, le modèle complet, équivalent à un système multiprocesseur réel, c'est-àdire comportant des verrous, est construit à partir des deux jeux de modèles, 4 et 5. De façon plus précise, la sortie du serveur 41 est reliée aux entrées des files d'attente équivalentes aux verrous d'indices a à m.Les sorties des serveurs de ces derniers, 51a à 51m, étant rebouclées sur l'entrée de la file d'attente 40 équivalente au système sans verrous. On obtient donc un modèle global 7, représenté symboliquement sur la figure 4 par un simple bloc diagramme, constitué par un réseau de files d'attente interconnectées. La dernière étape du procédé selon l'invention consiste à résoudre le modèle global 7. Les sorties S' de ce modèle composite 7 caractérisent les performances recherchées du système multiprocesseur, pour un contexte donné. Pour ce faire, les paramètres supplémentaires acquis en relation avec les verrous, 5a à 5m, notamment les paramètres d'occurence, sont réinjectés
en entrée de paramétrage du modèle 4.
Le modèle 7 tient bien compte des différents paramètres rappelés et aussi, notamment, du nombre n de processeurs. En particulier, chaque file d'attente, 50a à 50m, des verrous, 5a à 5m, reçoit un flot de requêtes en provenance du serveur 41. Le nombre de requêtes par seconde transmis à chaque file d'attente, 50a à 50m, dépend des valeurs des paramètres "occurrences". En faisant varier le nombre n de processeurs, il est possible de mettre simplement en évidence l'influence de ce nombre n de processeurs sur les performances globales du système. Il suffit de répéter, de façon itérative, les différentes étapes du procédé qui viennent d'être rappelées. La résolution du modèle composite 7 donne en sortie S' les caractéristiques de performance
du système.
Dans une autre variante, qui a été précédemment suggérée, les différentes itérations s'effectuent lors de la résolution du modèle partiel 4, pour un nombre de processeurs compris entre une borne inférieure n > 1 et une borne supérieure n+x arbitraire. Les différents résultats intermédiaires sont mémorisés, avantageusement sous la forme d'un fichier. La résolution du modèle complet, lors de la dernière étape, s'effectue en prenant en compte ces
3 o résultats intermédiaires.
De façon pratique, les données de sorties S' peuvent être visualisées ou acquises sous toutes formes appropriées, par exemple sur l'écran d'un système de traitement d'informations numériques, par affichage de
14 2778992
données numériques, de courbes ou d'histogrammes, ou encore être imprimées sur un support papier. Elles peuvent aussi être enregistrées dans une mémoire, de manière à être utilisées lors de traitements ultérieurs et servir de bases de comparaisons. C'est le cas notamment lorsqu'on fait varier le nombre n de processeurs et que l'on compare les performances du système
obtenues successivement.
Le procédé selon l'invention permet aussi de mettre en évidence l'influence des autres paramètres d'entrée, au niveau du modèle partiel 4, qui représente essentiellement la partie matérielle du système, puisqu'il ne tient 1o pas compte des verrous, et surtout au niveau des modèles individuels, 5a à m, représentant l'influence de chaque verrou. Dans ce dernier cas, en modifiant les paramètres associés à un verrou particulier, 5a à 5m, on peut mettre en évidence sa contribution à la
dégradation des performances du système global.
Cela permet notamment de détecter les verrous les plus "pénalisants" en terme de temps perdu, c'est-à-dire ceux qui contribuent le plus à la dégradation des performances du système. On peut ainsi essayer d'atténuer l'influence indésirable d'un ou plusieurs verrous particuliers. A titre d'exemple, il est possible, dans certaines circonstances de "casser" un verrou 2o en deux, en effectuant des adaptations matérielles et/ou logicielles
appropriées, ce qui permet de diminuer les temps de contention.
De façon duale, on peut éliminer du modèle les verrous sans influence importante sur les performances du système, soit a priori, sur la base des paramètres d'entrée de paramétrage associés à ces verrous, soit après résolution des modèles. Pour fixer les idées, I'expérience montre qu'il est généralement suffisant de tenir compte d'une vingtaine de verrous au maximum pour obtenir un modèle fiable. Parmi ces vingt verrous, le plus souvent, seule
la moitié contribue à une dégradation sensible des performances du système.
Jusqu'à ce point on a considéré que ce qui a été appelés "second
3o jeu de ressources", dans le préambule de la présente description, était
constitués de verrous. On peut étendre le procédé de l'invention à d'autres types de ressources. De façon plus générale, on considère que le système comporte deux jeux de ressources, dont un est exclu du premier jeu de
2778992
modèles, ce pour des raisons analogues à l'exclusion des verrous. Comme précédemment, le ou les ressources du second jeu de ressources sont décrits par un ensemble de modèles partiels, analogues aux modèles référencés 5a à m de la figure 4 (m étant un nombre arbitraire égal au nombre de ressources du second jeu). A titre d'exemple non exhaustif, le second jeu de ressources peut
être constitué par le lien intermodules 2 (figure 2) ou "interconnect".
On va maintenant décrire, de façon plus détaillée, des méthodes de mesures permettant d'acquérir les différents paramètres nécessaires pour o10 I'établissement des deux jeux de modèles partiels. Il doit tout d'abord être clair que le processus de mesure, d'une part, doit se dérouler dans des conditions de fonctionnement du système les plus proches possibles de la réalité, mais, d'autre part, ce processus de mesure ne doit pas interférer sur ce fonctionnement réel, ou de façon non significative. En d'autres termes, dans le cas présent, le processus de mesure ne doit pas consommer de temps machine et/ou de ressources. Dans le cas contraire, les mesures seraient
faussées et les paramètres acquis biaises.
A titre d'exemples non exhaustifs, les paramètres à acquérir sont les suivants: temps de cycle processeur, temps de cycle bus, taux de "miss" des 2 o antémémoires ou "caches", de premier et second niveaux, le nombre d'instructions exécutées, divers paramètres relatifs au matériel, tels que les temps mémoire, etc. Un certain nombre de paramètres est connu d'avance, tel le temps de cycle des processeurs utilisés. Ces données sont fournies, par exemple, par
le constructeur.
Dans un mode de réalisation préféré de l'invention, les autres paramètres utiles à l'élaboration des modèles sont mesurés, directement ou indirectement, à l'aide de compteurs de type "matériel", disséminés en des endroits stratégiques du système. De façon pratique, il s'agit de se circuits 3 o logiques supplémentaires intégrés dans le système. Chaque compteur est
affecté à un événement particulier à comptabiliser.
A chaque instant, I'ensemble des compteurs fournit des résultats bruts qui peuvent être ou non exploités, ce en tant que de besoin. Cette
16 2778992
exploitation est sous la conduite de programmes spécialisés, ou utilitaires de tailles réduites, tournant sur le système à tester. En effet, les mesures doivent être réalisées en temps réel et dans un environnement réel de fonctionnement,
même si l'exploitation effective des mesures est différée.
Cette méthode présente l'avantage de ne pas interférer de façon significative sur la charge de fonctionnement instantanée. En effet, les utilitaires précités ne consomment que très peu de ressources. L'expérience a montré que la consommation de ressources qui leur est imputable est dans un
rapport inférieur à 1 sur 10.000, par rapport aux programmes "utiles".
L'essentiel des mesures est donc effectué par du "matériel", et non par du logiciel, ce qui impliquerait une consommation de ressources parasite plus importante. Comme il a été indiqué, le comptage d'événements particuliers peut fournir directement certains paramètres, du moins après traitement des données brutes acquises par les utilitaires précités. A titre d'exemple, on peut citer le taux de "miss" dans les antémoires de premier niveau. En effet, on peut compter facilement, à l'aide des compteurs précités, le nombre d'adressages d'instructions réussis ("hits") ou non ("miss"). Il en est de même pour
l'adressage des données.
Par contre, pour d'autres paramètres, tels le nombre de "miss" dans les antémémoires ou "caches" de second niveau, ou encore les contentions sur le bus, I'acquisition des paramètres s'effectue habituellement de façon indirecte, plus précisément par l'intermédiaire d'histogrammes. On peut compter par exemple le nombre de requêtes sur le bus, et connaissant le nombre minimum de cycle d'horloge bus nécessaires pour accéder à une mémoire, dont la durée est connue a priori, déterminer les paramètres recherchés à l'aide des histogrammes précités. Pour ce faire, on peut munir le système d'un moniteur de performances qui affiche sur écran ou imprime sur papier l'histogramme. On peut également analyser directement les données de
3 o l'histogramme par un utilitaire spécialisé.
A la lecture de ce qui précède, on constate aisément que l'invention
atteint bien les buts qu'elle s'est fixés.
17 2778992
Elle permet notamment d'obtenir rapidement des mesures fiables caractérisant les performances d'un système multiprocesseur, quel que soit le
nombre des processeurs.
Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec la
figure 4.
En particulier, les valeurs numériques n'ont été précisées que pour
fixer les idées. Elles dépendent essentiellement de l'application précise visée.
Il doit être clair aussi que, bien que particulièrement adaptée à des 1o architectures de type dit "NUMA", on ne saurait cantonner l'invention à ce seul
type d'applications. Elle s'applique à toute architecture multiprocesseur.
18 2778992

Claims (10)

REVENDICATIONS
1. Procédé de détermination de performances d'un système de traitement de l'information multiprocesseur comprenant un nombre n déterminé de processeurs, ledit système comportant des premier et second jeux de ressources, le second jeu comprenant au moins une ressource déterminée, caractérisé en ce qu'il comprend au moins les étapes suivantes: - a/ mesure de premiers paramètres (p4) caractérisant la configuration dudit système multiprocesseur dépourvu du second jeu de ressources, un premier paramètre (p4) étant un taux représentant le nombre de fois o une ressource accédée du premier jeu est ou n'est pas présente; - b/ construction d'un premier modèle partiel paramétrable, constitué d'un réseau de stations comprenant chacune une file d'attente et un serveur représentant ledit système multiprocesseur dépourvu du second jeu de ressources, ledit premier modèle partiel recevant, sur une entrée de paramétrage, lesdits premiers paramètres mesurés (p4); - c/résolution dudit premier modèle partiel de manière à obtenir une station unique (4), comprenant une file d'attente (40) et un serveur (41), équivalente audit système dépourvu du second jeu de ressources; - d/ mesure de séries de seconds paramètres (P5a-P5m), chaque série de 2 0 paramètres caractérisant une desdites ressources du second jeu, un second paramètre (P5a-P5m) étant un taux représentant le nombre de fois o une ressource accédée du second jeu est ou n'est pas présente; - e/ construction d'un jeu de seconds modèles partiels paramétrables, constitués chacun d'une station (5a-5m) comprenant une file d'attente (50a-50m) et un serveur (51a-51m), chacun desdits seconds modèles partiels représentant une desdites ressources du second jeu et recevant, sur une entrée de paramétrage, une desdites séries de seconds paramètres mesurés (P5a-P5m); - f/ construction d'un modèle global (7) représentant ledit système multiprocesseur, en reliant ledit serveur (41) dudit premier modèle partiel à toutes les files d'attente (50a-50m) desdits second modèles partiels
19 2778992
(5a-5m) et les serveurs (51la-51m) de ces modèles (5a-5m) à la file d'attente (40) du premier modèle partiel et - g/ résolution dudit modèle global (7) ainsi construit, en paramètrant le premier modèle partiel à l'aide d'au moins un paramètre supplémentaire d'entrée mesuré caractérisant l'occurrence des accès auxdites ressources du second jeu par lesdits processeurs, de manière à obtenir en sortie (S') du modèle global (7) lesdites performances du système multiprocesseur
comportant ledit second jeu de ressources.
2. Procédé selon la revendication 1, caractérisé en ce que, chaque processeur dudit système de traitement de l'information multiprocesseur pouvant accéder à des ressources de mémoires de données partagées, chacune des ressources dudit second jeu est constituée par un objet logiciel, dit verrou, garantissant des accès exclusifs pour les
processeurs dans lesdites ressources de données partagées.
3. Procédé selon les revendications 1 ou 2, caractérisé en ce
que, ledit nombre n déterminé de processeurs pouvant prendre toutes les valeurs d'une gamme bornée par une valeur minimale nmin > 1 et une valeur maximale nmax déterminée, lesdites étapes a/ à c/ sont réitérées pour des nombres n de processeurs de valeurs prédéterminées couvrant tout ou partie des valeurs de ladite gamme, en ce que, à la suite des étapes c/ de résolution dudit premier modèle partiel (4), il est procédé à une étape supplémentaire de stockage de données décrivant ladite file de données équivalente à un système multiprocesseur dépourvu dudit second jeu de ressources pour chacune des valeurs prises par n, et en ce que lesdites étapes d/ à g/ sont réalisées pour au moins l'une des valeurs de n de la gamme, de manière à obtenir en sortie (S') du modèle global (7) lesdites performances dudit système multiprocesseur comportant le second jeu de
ressources, pour lesdits nombres prédéterminés de processeurs.
4. Procédé selon la revendication 1, caractérisé en ce que, ledit nombre n déterminé de processeurs pouvant prendre toutes les valeurs d'une gamme bornée par une valeur minimale nmin > 1 et une valeur
2778992
maximale nmax déterminée, lesdites étapes a/ à g/ sont réitérées pour des nombres n de processeurs de valeurs prédéterminées couvrant tout ou partie des valeurs de ladite gamme, de manière à obtenir en sortie (S') du modèle global (7) lesdites performances dudit système multiprocesseur comportant ledit second jeu de ressources, pour lesdits nombres
prédéterminés de processeurs.
5. Procédé selon l'une quelconque des revendications 1 à 4,
caractérisé en ce que lesdites étapes de mesures de paramètres sont réalisées par des mesures expérimentales effectuées sur un système multiprocesseur de configurations matérielle et logicielle prédéterminées, et
comprenant un nombre n déterminé de processeurs (UCl1-UCn).
6. Procédé selon l'une quelconque des revendications 1 à 5,
caractérisé en ce que lesdites étapes de résolution de modèles (4, 7) sont réalisées à l'aide d'un logiciel spécialisé de résolution de files d'attente,
paramétré par lesdits paramètres acquis (P4, P5a-P5m).
7. Procédé selon l'une quelconque des revendications 1 à 6,
caractérisé en ce que ledit système multiprocesseur comprenant un nombre déterminé de ressources appartenant audit second jeu, ledit jeu de seconds modèles partiels paramétrables (5a-5m) comprend les modèles associés seulement à une partie desdites ressources du second jeu, les ressources sélectionnés étant celles susceptibles de dégrader le plus fortement lesdites
performances dudit système multiprocesseur.
8. Procédé selon la revendication 7, caractérisé en ce qu'il comprend une étape subséquente à ladite étape d/ de mesure de séries de seconds paramètres (P5a à P5m) consistant en la sélection desdites ressources du second jeu susceptibles de dégrader le plus fortement lesdites performances dudit système multiprocesseur à partir de ces séries
de seconds paramètres (P5a à P5m).
21 2778992
9. Procédé selon l'une quelconque des revendications 1 à 8,
caractérisé en ce que ledit premier modèle partiel (4) représente un système multiprocesseur (Ma, Mb), comprenant un nombre déterminé de processeurs égal à n (10-13), dont l'architecture est du type à accès symétrique desdites ressources de mémoire partagées (14), via un bus système commun auxdits
processeurs (10-13).
10. Procédé selon l'une quelconque des revendications 1 à 9,
caractérisé en ce que ledit modèle global (7) représente un système multiprocesseur (1'), comprenant un nombre déterminé de processeurs égal iO à n (10a-12a, 10b-12b), dont l'architecture est du type à accès temporel non
uniforme desdites ressources de mémoire partagées (14a, 14b).
FR9806362A 1998-05-20 1998-05-20 Procede de determination de performances d'un systeme de traitement de l'information multiprocesseur Expired - Fee Related FR2778992B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR9806362A FR2778992B1 (fr) 1998-05-20 1998-05-20 Procede de determination de performances d'un systeme de traitement de l'information multiprocesseur

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR9806362A FR2778992B1 (fr) 1998-05-20 1998-05-20 Procede de determination de performances d'un systeme de traitement de l'information multiprocesseur

Publications (2)

Publication Number Publication Date
FR2778992A1 true FR2778992A1 (fr) 1999-11-26
FR2778992B1 FR2778992B1 (fr) 2000-06-30

Family

ID=9526546

Family Applications (1)

Application Number Title Priority Date Filing Date
FR9806362A Expired - Fee Related FR2778992B1 (fr) 1998-05-20 1998-05-20 Procede de determination de performances d'un systeme de traitement de l'information multiprocesseur

Country Status (1)

Country Link
FR (1) FR2778992B1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0372682A2 (fr) * 1988-12-05 1990-06-13 Digital Equipment Corporation Méthode de caractérisation de système

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0372682A2 (fr) * 1988-12-05 1990-06-13 Digital Equipment Corporation Méthode de caractérisation de système

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
A. HAC: "An Approximation of Delays Due to Locking of Files in a Distributed System", PROCEEDINGS OF THE 8TH INTERNATIONAL COMPUTER SOFTWARE & APPLICATIONS CONFERENCE, COMPSAC84, 7 November 1984 (1984-11-07) - 9 November 1984 (1984-11-09), Chicago, US, pages 58 - 67, XP002092190 *
CHU W W ET AL: "TASK RESPONSE TIME FOR REAL-TIME DISTRIBUTED SYSTEMS WITH RESOURCE CONTENTIONS", IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, vol. 17, no. 10, 1 October 1991 (1991-10-01), pages 1076 - 1092, XP000271883 *
D. POTIER ET AL.: "QNAP: Un outil d'aide à l'évolution d'architectures de systèmes", CHOISIR SON INFORMATIQUE, CONVENTION INFORMATIQUE, 1979, Paris, France, pages 287 - 294, XP002092189 *

Also Published As

Publication number Publication date
FR2778992B1 (fr) 2000-06-30

Similar Documents

Publication Publication Date Title
EP1043658B1 (fr) Procédé d'amélioration des performances d'un système multiprocesseur comprenant une file d'attente de travaux et architecture de système pour la mise en oeuvre du procédé
US10901764B2 (en) Layered machine images
FR2767939A1 (fr) Procede d'allocation de memoire dans un systeme de traitement de l'information multiprocesseur
US10169108B2 (en) Speculative execution management in a coherent accelerator architecture
EP2438528A1 (fr) Procédé et dispositif de chargement et d'exécution d'instructions à cycles déterministes dans un système avionique multi-coeurs ayant un bus dont le temps d'accès est non prédictible
FR2843213A1 (fr) Procede et systeme d'etablissement automatique d'un modele global de simulation d'une architecture
FR2927438A1 (fr) Methode de prechargement dans une hierarchie de memoires des configurations d'un systeme heterogene reconfigurable de traitement de l'information
US10785087B2 (en) Modifying computer configuration to improve performance
EP0881574B1 (fr) Dispositif d'instrumentation pour machine avec mémoire à accès non uniforme.
FR3045183A1 (fr) Procede de prediction d'une donnee a precharger dans une memoire cache
CN110825589B (zh) 用于微服务系统的异常检测方法及其装置和电子设备
CN107844542A (zh) 一种分布式文件存储方法及装置
EP0166062B1 (fr) Dispositif d'arbitrage d'accès à une ressource partagée
FR3089322A1 (fr) Gestion des restrictions d’accès au sein d’un système sur puce
FR2778992A1 (fr) Procede de determination de performances d'un systeme de traitement de l'information multiprocesseur
EP2802992B1 (fr) Systeme et procede de gestion de correspondance entre une memoire cache et une memoire principale
US10706195B1 (en) System, method, and computer program product for over-constraint/deadcode detection in a formal verification
FR2914525A1 (fr) Procede de simulation transactionnelle d'un modele generique de noeud de communication, produit programme d'ordinateur et moyen de stockage correspondants
FR2629230A1 (fr) Dispositif de controle et d'acquisition de donnees a grande vitesse
Nguyen et al. Gateway-based access interface management in big data platform
FR2919401A1 (fr) Procede de test des chemins de donnees dans un circuit electronique
CN114238004B (zh) 互联电路的数据传输正确性检查方法及装置、电子设备
EP4060503A1 (fr) Procédé de mitigation de contentions pour une application opérationnelle et système de mitigation de contentions associé
US20220100474A1 (en) Detection of unintended dependencies in hardware designs with pseudo-random number generators
Parlan et al. Highly Distributed In-Browser Computing

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 18

ST Notification of lapse

Effective date: 20170131