une infrastructure modulaire de simulation pour lévaluation de performances de systèmes...

Une infrastructure modulaire de simulation pour l’évaluation de

performances de systèmes temps-réel

David Decotigny

Projet ACES

Une infrastructure de simulation pour l’évaluation de performances de systèmes temps-réel 2/35

Plan de l’exposé

Contexte et problématique

Critères et méthodes d’évaluation

Infrastructure extensible pour l’évaluation de systèmes

temps-réel

Une extension : famille d’ordonnanceurs personnalisable

Expérimentations : mesure de l’influence de la

perception du temps

Conclusions et perspectives


Introduction (1/3)Systèmes temps-réel

Correction fonctionnelle

Respect des contraintes temporelles

Temps = donnée physique mesurable

Contraintes de temps

• Échéances temporelles, retard au démarrage maximal,

…

Types de systèmes temps-réel

• Temps-réel strict : garanties strictes

• Temps-réel souple : garanties relatives (probabilistes)


Introduction (2/3)Modèle de système

Niveau logiciel Application

Plusieurs tâches Support d’exécution

Gestion de ressources Interaction avec

l’environnement

Niveau matériel Processeur Environnement Réseau


Introduction (3/3)Notions d’ordonnancement temps-réel

Déroulement de l’exécution de l’application

Décisions d’arbitrage du processeurOrdonnancement

Défini hors-ligne Défini en-ligne

À plan dynamiqueÀ priorité statique (RM/DM), dynamique (EDF, LLF)

Repose sur un modèle de tâcheCaractéristiques : loi d’activation, temps d’exécution pire-casContraintes de temps

Nécessité d’évaluer le comportement et les garanties offertes


Plan de l’exposé



Infrastructure extensible pour l’évaluation de systèmes

temps-réel

Une extension : famille d’ordonnanceurs personnalisable


perception du temps



Critères d’évaluation

Verdict d’ordonnançabilité : existence et

détermination d’un ordonnancement faisable

Temps-réel strict

Mesures quantitatives sur le comportement effectif

Temps-réel souple ou strict

Taux de respect des contraintes temporelles

Distribution des retards au démarrage


Méthodes d’évaluation (1/3)

Méthodes analytiques Principe

En entrée : modèle abstrait + formalisme associé Identifier les configuration(s) possible(s)

Objectif Verdict d’ordonnançabilité Caractéristiques stochastiques

Intérêts Tôt dans le processus de développement Sûreté

Limitations Données en entrée

• toutes connues• sûres

Modèles simples : risque de non représentativité



Exécution réelle instrumentée Principe

En entrée : implantation complète Mesures quantitatives à l’aide de sondes

Objectifs Confronter les mesures aux spécifications

Intérêt Représentativité des mesures

Limitations Tard dans le processus de développement Résultats non sûrs Sonde : « Effet sonde » Sonde matérielle : surcoût inutile à la fabrication



Simulation Principe

En entrée : modèle abstrait ou concret du système Mesures quantitatives

Objectifs Confronter les mesures aux spécifications

Intérêts Tôt ou tard dans le preocessus de développement Pas d’effet sonde

Limitation Résultats non sûrs

Précautions à prendre Pertinence de la simulation sur les modèles concrets


Objectifs

Évaluer le comportement temporel de systèmes

complexes

Permettre les évaluations tout au long du processus

de développement

Modèles abstraits

Modèles concrets / réutilisation de code

Choix de la méthode d’évaluation par simulation

Précaution : assurer un haut degré de pertinence


Plan de l’exposé



Infrastructure extensible pour l’évaluation de

systèmes temps-réel

Une extension : famille d’ordonnanceurs

personnalisable


perception du temps



Ce qu’on attend d’un simulateur

Capacités de personnalisation

les tâches de l’application

les services du support d’exécution

l’ordonnanceur et le modèle de tâches associé

Pertinence du comportement temporel simulé

Prise en compte des durées d’exécution des éléments du

système


Limitations des simulateurs existants

Simulateurs à événements discrets généraux Difficulté d’assurer la pertinence du comportement temporel simulé

Simulation adaptée à un domaine différent

Simulateurs d’ordonnancement Capacités de personnalisation limitées

Pertinence du comportement temporel simulé limitée

Simulateurs de systèmes complets Capacités de personnalisation limitées

Priorité aux problèmes de synchronisation

Problèmes d’efficacité


Vue d’ensemble du simulateur réalisé (1/3)

Infrastructure modulaire

Module central : simulation de système temps-réel Capacités de personnalisation à tous niveaux

Fidélité des comportements temporels simulés

Précision temporelle de simulation indépendante de la perception

du temps par le système

Efficacité de simulation

Simulation de systèmes distribués Simulation des pertes et altérations de messages sur le réseau

Reproduction des dérives d’horloges

Artisst is a Real-Time System Simulation

Tool


Vue d’ensemble du simulateur (2/3)

Analyse statistique

Chronogramme

Enregistreur de traces

168.290000000 INTERRUPT_RAISED 0168.290000000 SUSPEND_TASK_EXECUTION 0168.290000000 INTERRUPT_ENTER 0168.291000001 INTERRUPT_LEAVE 0168.291000001 RESUME_TASK_EXECUTION 0168.300000000 INTERRUPT_RAISED 0168.300000000 SUSPEND_TASK_EXECUTION 0168.300000000 INTERRUPT_ENTER 0

Obse

rvati

ons

Système à évaluer

Lecteur de traces

168.250000000 INTERRUPT_RAISED 0168.260000000 INTERRUPT_RAISED 0168.270000000 INTERRUPT_RAISED 0168.280000000 INTERRUPT_RAISED 0168.290000000 INTERRUPT_RAISED 0168.300000000 INTERRUPT_RAISED 0168.300000012 INTERRUPT_RAISED 1168.300000012 INTERRUPT_RAISED 2168.300000012 INTERRUPT_RAISED 3

Générateur d'événements

En

vir

on

nem

ent

Environnement


Support d’exécution

Vue d’ensemble du simulateur (3/3)

Interruptions

Clock ISR

Traitants d’interruptions

Tâche

Tâches

Ordonnanceur


Enregistreur de traces

168.290000000 INTERRUPT_RAISED 0168.290000000 SUSPEND_TASK_EXECUTION 0168.290000000 INTERRUPT_ENTER 0168.291000001 INTERRUPT_LEAVE 0168.291000001 RESUME_TASK_EXECUTION 0168.300000000 INTERRUPT_RAISED 0168.300000000 SUSPEND_TASK_EXECUTION 0168.300000000 INTERRUPT_ENTER 0

Propriétés du simulateur (1/4)Modularité

Environnement

Autres modules possibles

Chronogramme

Circuit personnalisable

Analyse statistique

Générateur d'événements

Système à évaluer

Modules par défaut personnalisables

Messages

Mes

sage

s


Propriétés du simulateur (2/4)Modularité

Possibilité de connecter

les systèmes simulés en

réseau Diffusion totale sans perte ni

délai par un module central

Simulation du routage et des

pertes/délais à chaque nœud


spawn_task cancel_task get_date change_date

OS basique

Propriétés du simulateur (3/4)Personnalisation du système simulé

Interruptions

Take_resource

res->ref++;

API OS Perso

...cur_task = next_task; ...

Ordonnanceur

Modèle de

tâche

Tâches

compute_fft(data1, result1); t = spawn_task(task_entry); compute_fft(data2, result2); ...

Traitants d’interruptions

change_date();

activate_task();

...

Tâche 0 Clock ISR


spawn_task cancel_task get_date change_date

OS basique

Interruptions

Take_resource

res->ref++;

API OS Perso

TâchesTraitants

d’interruptions

Tâche 0 Clock ISR

change_date();

activate_task();

...

...cur_task = next_task;

...

Ordonnanceur

compute_fft(data1, result1); t = spawn_task(task_entry); compute_fft(data2, result2); ...

hold_cpu(sec(3)); hold_cpu(sec(2)); hold_cpu(sec(4));

Propriétés du simulateur (4/4)Fidélité des comportements temporels simulés

hold_cpu(ms(2));

hold_cpu(ms(2));

hold_cpu(ms(30));


Plan de l’exposé






personnalisable


perception du temps



Famille d’ordonnanceurs dynamiques (1/3)Introduction

Contexte Aucune tâche garantie hors-ligne Tâches activées

Indépendantes

Principe général des ordonnanceurs dynamiquesTest d’acceptation

Sélectionner les tâches à intégrer au système, refuser les autresOrdonnancementGarantir le respect des échéances des tâches acceptées

On connaît le temps d’exécution au pire (WCET) de chaque tâche

Chaque tâche possède une contrainte d’échéance

Aucune hypothèse sur les lois d’activation


Famille d’ordonnanceurs dynamiques (2/3)Principe

Principe du test d’acceptation Suppose un ordonnancement à priorité Repose sur le calcul du temps processeur disponible pour chaque tâche

????

Pri

ori

tés

RefuséeRefuséeAcceptée

Observation : 2 propriétés sur les priorités suffisent

Priorités relatives indépendantes du temps Priorités relatives indépendantes de l’insertion et de la

suppression de tâches


Famille d’ordonnanceurs dynamiques (3/3)Propriétés de l’approche

Unifie une grande partie des algorithmes de garantie à priorité classiques (DM, RM, EDF, … et même Fifo)

Généralise une approche systématique pour :

Test d’ordonnancement Ordonnancement avec

repêchage Ordonnancement avec

politiques de rejetFamille d’ordonnanceurs

génériques spécialisable par 1, 2 ou 3 fonctions de comparaison des priorités


Plan de l’exposé






personnalisable


perception du temps



Prise en compte de la granularité d’horloge (1/4)Problématique : perception du temps

Prendre cette approximation en compte dans les décisions liées au temps

Dates « temps-système » internes au système

Approximation locale discontinue du temps-réel

Dans les systèmes réels, deux échelles de temps :

Dates temps-réel Difficilement accessibles par le

système

Temps-réel

Tem

ps m

esur

é

Hypothèses classiques en

ordonnancement Mesures exactes des dates et durées


Prise en compte de la granularité d’horloge (2/4)Règles de prise en compte définies

Objectif Conserver la sûreté des tests d’acceptation

Se placer dans les cas pessimistes

Grandeurs affectées Dates

Date de fin de tâche pessimiste

Date d’échéance dans l’échelle de temps système

Durées

Temps d’exécution pire cas restant à exécuter par une tâche

Temps non utilisé par une tâche


Prise en compte de la granularité d’horloge (3/4)Évaluation de l’impact : dispositif expérimental

Simulation avec Artisst Utilisation des ordonnanceurs dynamiques de la famille présentée

Charge synthétique avec durée d’exécution des tâches variable

Mesure du taux d’acceptation en fonction

de la granularité d’horloge système

des paramètres de la charge

• Charge individuelle moyenne : ratio WCET / échéance relative

• Facteur de recouvrement : ratio échéance relative / délai

d’inter-arrivée moyen

Sans ou avec coûts système : traitant d’interruption,

ordonnanceur, activation de tâche (distribution uniforme sur [0,

0.5ms])


Prise en compte de la granularité d’horloge (4/4)Évaluation de l’impact : résultats

Impact d’autant plus fort que la charge individuelle moyenne est élevée

Influence de la charge individuelle moyenne prépondérante

Impact d’autant plus faible que la charge globale augmente

Coûts OS

négligeables à grosse granularité

prépondérants quand ils sont comparables à la granularité d’horloge

EDF

0.1 0.4

0.7 0.9

charge 0 10

50 100

granularité (ms)

10

50

100

Taux de garantie (%) EDF

0.1 0.4

0.7 0.9

charge 0 10

50 100

granularité (ms)

40

50

Taux de garantie (%)EDF

0.1 0.4

0.7 0.9

charge 0 10

50 100

granularité (ms)

20

30

40

50

Taux de garantie (%)

Recouvrement = 1Sans coûts OS

Recouvrement = 3Sans coûts OS

Recouvrement = 3Avec coûts OS


Plan de l’exposé






personnalisable


perception du temps



Conclusions et perspectives (1/3)

Bilan Infrastructure de simulation

Modulaire, personnalisable et extensible

Fidélité de prise en compte des coûts d’exécution

Décorrélation des échelles de temps-réel et système

Famille d’ordonnanceurs à acceptation dynamique

Unification des affectations de priorités classiques

Algorithmes généraux indépendants des affectations de

priorité

Règles de prise en compte de la granularité d’horloge système

Intégrées dans les ordonnanceurs fournis

Impact évalué sur 3 séries de 18 configurations avec Artisst



Disponibilité d’Artisst : licence LGPL

3 types de modules en entrée, 4 types de modules en sortie

Module de simulation de systèmes temps-réel bien éprouvé

9 types d’ordonnanceurs temps-réel fournis

Validation sur des systèmes centralisés et distribués avec ou

sans partage de ressources (aucun protocole d’accès)

http://david.decotigny.free.fr/rt/artisst/ (temporaire)



Perspectives

Inclure le support des tâches dépendantes en centralisé et distribué

Proposer un mécanisme de composition d’ordonnanceurs

Approche déjà entamée dans Artisst

Évaluer l’influence de l’interface de programmation de différents OS

Services de réveil de tâches, …

Couvrir tout le processus de développement

Récupération automatique du paramètre de hold_cpu()


Introduction (4/4)Problématique

Quand tous les comportements temporels Du système (exécution des tâches, support d’exécution, …)

et

De ses interactions avec l’environnement (lois d’activations, …)

sont totalement caractérisés Il peut exister des conditions de faisabilité associées à un

ordonnancement

Exemples : (EDF, LLF), (RM)

Sinon : Moins de contraintes moins de garanties Nécessité d’

évaluer le comportement et les garanties offertes

1i i

i

PC )12( n

i i

i nPC


Motivations et objectifs (2/2)

Objectifs Proposition d’une infrastructure de simulation

Extensible et personnalisable Accent mis sur la pertinence des comportements de

l’environnement et du système reproduits Validation de sa faculté de personnalisation

Intégration de plusieurs ordonnanceurs / modèles de tâches

Proposition d’une famille générique d’ordonnanceurs Utilisation du simulateur pour l’étude de l’influence de

la précision de perception du temps sur les décisions d’ordonnancement

Établissement de règles analytiques pour sa prise en compte dans les ordonnanceurs réalisés

Mesures sur les comportements résultants


Ce qu’on attend d’un simulateur (1/2)

Pertinence de la simulation de l’environnement Pouvoir faire interagir le système avec une grande variété de

composantes de l’environnement simulé

Pertinence de l’évaluation du système Pertinence du modèle simulé

Abstrait & concret : facilité de personnalisation des éléments du système

• Modèles de tâches, Services du support d’exécution (dont l’ordonnanceur)

Concret : rester le plus proche possible de l’implantation concrète

• Réutilisation du code de l’implantation Pertinence du comportement temporel simulé

Prise en compte des durées d’exécution des éléments du système


Ce qu’on attend d’un simulateur (2/2)

Pertinence de simulation par réutilisation de code

compute_fft(data1, result1);

t = spawn_task(task_entry);

compute_fft(data2, result2);

...

Simulation d’un temps d’occupation du CPU



Tâche T

La simulation d’occupation du temps CPU doit tenir

compte des préemptions Tâche T

Tâche U

Le processeur est une ressource préemptible :


Simulateurs existants (1/2)Grandes classes de simulateurs

À temps continu

Résolution d’équations différentielles

À événements discrets

Temps simulé

Wait(3)

1 2 4 5


Simulateurs existants (2/2)Limitations

Limitation des simulateurs à événements discrets généraux [Csim,ADEVS,OMNET++,Hyperformix workbench,OPNet,QNap]

Difficulté à assurer la pertinence du comportement temporel simulé Simulation adaptée à un domaine différent (files d’attentes, …)

Limitations des simulateurs d’ordonnancement [PERTS,Simulateur

ULB, Retis RTSim/Ghost,Timewiz]

Difficulté à assurer la pertinence du modèle simulé Difficulté à assurer la pertinence du comportement temporel simulé Simulation par quanta de temps

Limitations des simulateurs de systèmes complets [Rialto,TAPS,OSE Softkernel,VxSim,Carbonkernel,CMU Sew]

Difficulté à assurer la pertinence du modèle simulé S’attachent davantage aux problèmes de synchronisation qu’au

comportement temporel Problèmes d’efficacité


Caractéristiques du simulateur proposé (4/7)Comportement du matériel et de l’OS basique

Gestion des interruptions Notion de priorité

Masquage possible :

Temporaire, local à la tâche

Définitif, global au système simulé

Par défaut, le système d’exploitation

simulé & l’ordonnanceur sont totalement

préemptibles


Caractéristiques du simulateur proposé (3/5)Capacités de personnalisation

1

*

RTOS Ordonnanceur

Tâche

Modèle de tâche

Statut d’exécution

Contexte d’exécution

Temps simulé occupéRessources utilisées

Caractéristiques courantes :Loi d’activation de la tâche,

paramètres temporels (WCET)

Personnalisable Extensible





Caractéristiques du simulateur proposé (4/5)Ordonnanceurs fournis par défaut

9 familles d’ordonnanceurs par défaut Ordonnanceurs à priorité

Garantis hors-ligne : ordonnanceurs classiques du domaine

Garantis en-ligne : famille d’ordonnanceurs avec acceptation dynamique, ordonnanceurs par serveurs ou à réquisition de temps

libre

Autres ordonnanceurs à garantie Au dessus d’une politique à partage de temps Avec fonctionnement en mode dégradé

Autres ordonnanceurs sans garantie Ordonnanceurs « au mieux » par prévision des

caractéristiques temporelles (boucle de rétroaction)


Famille d’ordonnanceurs dynamiques (3/4)

Hypothèse forte : priorités conservatives Priorités relatives indépendantes du temps Priorités relatives indépendantes de l’insertion et de la suppression de tâches

Définition d’un algorithme de garantie paramétrableFondé sur le calcul du temps processeur disponible pour chaque tâche :

• temps résiduelParamétrable par une fonction de comparaison de priorité conservative

• Regroupe les affectations de priorités classiques (EDF, RM/DM, …)

Pri

ori

tés


Prise en compte de la granularité d’horlogeRègles de prise en compte définies

Échéance relative D = 4WCET C = 2.5

Exemple

Date d’échéance pessimisteDate de début au plus tôt

D = 4 Temps résiduel pessimisteDate de fin pessimisteDate de début au plus tard

C = 2.5 Ressources récupérées pessimistes

Majorant du temps utiliséceil(1.2) = 2 Évaluation pessimiste du temps résiduel

Minorant du temps utilisé à chaque instant

ObjectifConserver la sûreté des tests

d’acceptationSe placer dans les cas les plus

pessimistes

une infrastructure modulaire de simulation pour lévaluation de performances de systèmes...

Documents