MétaCan
Menu
Back to cohort
Record W38919347

Traçage de systèmes linux multi-coeurs en temps réel

2013· article· fr· W38919347 on OpenAlex
Raphaël Beamonte

Why this work is in the frame

A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.

fundA Canadian funder is recorded on the work.
no affNo Canadian affiliation: this work is invisible to an affiliation-only frame.
No Canadian affiliation. An affiliation-only frame, the usual design, would never have seen this work. It is one of the works that make the case for inverting the frame.

Bibliographic record

VenuePolyPublie (École Polytechnique de Montréal) · 2013
Typearticle
Languagefr
FieldComputer Science
TopicSoftware System Performance and Reliability
Canadian institutionsnot available
FundersNatural Sciences and Engineering Research Council of CanadaConsortium de Recherche et d’innovation en Aérospatiale au Québec
KeywordsComputer science
DOInot available

Abstract

fetched live from OpenAlex

RESUME Le tracage est une methode d’analyse de plus en plus populaire compte tenu de la precision des donnees qu’il permet de reunir concernant les activites d’un systeme. Nombre de systemes demandent cependant aujourd’hui de fonctionner dans des conditions restreintes : c’est le cas des systemes temps reel. Ces systemes reposent sur le respect d’echeances dans le traitement de donnees. Autrement dit, une donnee exacte n’aura de valeur dans un systeme de ce type qu’a condition qu’elle soit obtenue dans les delais, sans quoi le systeme sera considere defaillant. Ces conditions excluent par consequent tout outil d’analyse impactant de maniere significative la latence et les performances du systeme. Le tracage repose sur l’ajout de points de trace au sein de l’application ou du systeme d’exploitation trace. Ces derniers vont generer des evenements lorsqu’ils sont atteints durant l’execution et ainsi permettre de suivre l’etat d’un systeme au fur et a mesure de son execution. Cependant, la generation de ces donnees implique une modification dans le deroulement normal de l’application ou du systeme trace, et par consequent un impact. Il devient alors important de pouvoir quantifier cet impact de maniere a savoir sous quelles conditions une application temps reel pourra ou ne pourra pas etre tracee, autrement dit, de savoir si l’ajout de ce delai de traitement rendra le systeme defaillant, et par consequent inadequat au tracage. L’objectif de cette recherche est de montrer qu’il est tout a fait possible d’utiliser le tracage pour analyser de telles applications, et ce avec un impact en terme de latence que nous souhaitons quantifier pour le pire cas. Pour ce faire, nous allons definir un environnement de travail temps reel en etudiant les divers systemes et configurations speciales mis a disposition. Ensuite nous verrons quels sont les outils permettant de valider la qualite de notre environnement de travail et quel est leur fonctionnement. Nous comparerons par la suite les differents outils mettant a disposition des traceurs, et lesquels parmi eux nous permettent de correler des traces du noyau et de l’espace utilisateur. Une fois l’environnement defini et verifie et l’outil de tracage choisi, notre methode experimentale reposera sur un etalonnage du systeme temps reel permettant par la suite d’evaluer l’impact du traceur sous differents angles a l’aide de la creation de different scenarios d’analyse. Cette methode experimentale prendra en compte la latence ajoutee sur le systeme par l’instrumentation, le tracage mais aussi la qualite des traces obtenues. Ces elements seront les marqueurs de qualite du tracage dans des conditions temps reel. L’hypothese servant de point de depart de ce travail est qu’en isolant le fonctionnement du traceur de celui de l’application temps reel tracee, l’impact de l’outil de tracage sur l’application pourra etre radicalement reduit. Les resultats de ce travail sont la decouverte et l’integration aux outils existants d’un modele pour supprimer les communications entre l’application tracee et le traceur durant la periode active de tracage, permettant ainsi de n’ajouter qu’une interference minimale sur l’execution normale de l’application, permettant ainsi de rendre le tracage apte a fonctionner dans nombre de conditions temps reel, du moment que le delai maximal qu’il ajoute entre dans l’echeance de celle-ci. De plus, l’outil npt cree comme outil d’etalonnage et d’analyse de l’impact a evolue au fur et a mesure de nos recherches et est maintenant un logiciel disposant de differentes options pour simuler de multiples scenarios d’execution d’une application temps reel. Enfin, la methodologie d’analyse de l’impact du tracage sur le systeme temps reel constitue elle aussi un des resultats de cette etude. Le resultat final est que l’utilisation du tracage pour une application temps reel s’executant dans l’espace utilisateur est viable pour la plupart des systemes temps reel avec une latence ajoutee de seulement quelques microsecondes.----------ABSTRACT Tracing is an analysis method increasingly popular. It provides a lot of information of high precision about a system or application. However, many systems need to operate under restricted conditions. This is the case of real-time systems. These systems are based on meeting deadlines in data processing. In other words, accurate data will only have a value if we can poduce it in a timely fashion, otherwise we will consider the system as defective. These conditions therefore exclude any analysis tool which could impact significantly the system latency or performance. Tracing is based on the addition of tracepoints directly in the application or operating system source code. There tracepoints will generate events when they are reached as part of the execution, and allow to monitor the system or application state during its run. Still, the generation of this data involves a change in the normal course of the traced system, hence an impact. It then becomes important to quantify this impact in order to know the conditions for tracing a real-time application, in other words, to know whether the added latency will invalidate the real-time condition, hence force to consider tracing as inedequate or not. The objective of this research is to prove that it is possible to use tracing to analyze such applications, thus quantifying the maximum impact in terms of latency. In order to do that, we will define a real-time work environment by studying the various systems and special configurations available, then we will see what tools allow to validate the quality of our work environment and how they work. We will then compare the various tracing tools and identify which allow us to correlate the kernel and userspace traces. Once we have setup and verified our real-time environment and selected our tracing tool, our experimental method will be based on real-time system calibration to subsequently assess the impact of the tracer from different use cases, using different analysis scenarios. This experimental method will take into account the latencies added by the instrumentation and the tracing of the system, but also the quality of the generated traces. These elements will be considered as quality markers of real-time tracing. The hypothesis serving as starting point for this work is that, by isolating the work of the tracer from that of the real-time application, the impact of the tracing tool on the application can radically be reduced. The results of this work are the discovery and integration in existing tools of a model to remove the direct connections, between the traced application and the tracer, while the tracing operations are active. This allows to only add a minimal interference to the normal execution of the application, thereby making tracing able to operate multiple real-time cases, as long as the maximum latency added can be supported by the traced application. In addition, the npt tool created as the calibation and impact analysis tool has evolved during our research and now offers options allowing to simulate multiple execution scenarios of real-time applications. Finally, the real-time tracing impact analysis methodology we developed is also one of the results of this study. The final result is that using tracing to analyze real-time applications running in userspace is a valid and good option for most real-time systems, adding latencies in the low microsecond range.

Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.

Full frame distilled prediction

Teacher imitation

Not calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.

metaresearch head score (Codex)0.003
metaresearch head score (Gemma)0.001
Version: codex-gemma-dda1882f352aValidation status: machine_predicted_unvalidated
Candidate categoriesMeta-epidemiology (narrow), Scholarly communication, Research integrity, Insufficient payload (model declined to judge)
Consensus categoriesnone
DomainCandidate signal: none · Consensus signal: none
Study designCandidate signal: Observational · Consensus signal: none
GenreCandidate signal: Methods · Consensus signal: none
Teacher disagreement score0.613
Threshold uncertainty score1.000

Codex and Gemma teacher scores by category

CategoryCodexGemma
Metaresearch0.0030.001
Meta-epidemiology (narrow)0.0010.001
Meta-epidemiology (broad)0.0010.001
Bibliometrics0.0010.001
Science and technology studies0.0010.000
Scholarly communication0.0010.003
Open science0.0030.001
Research integrity0.0010.001
Insufficient payload (model declined to judge)0.0000.001

Machine scores (provisional)

The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.

Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.

Opus teacher head0.014
GPT teacher head0.238
Teacher spread0.224 · how far apart the two teachers sit on this one work
Validation statusscore_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it