Les Systèmes de Gestion de Bases de Données...

Les Systèmes de Gestion de Bases de DonnéesTemps Réel et Multimédia

—Année 2005-2006

Claude Duvallet , Bruno Sadeg, Laurent Amanton

Université du HavreUFR Sciences et Techniques

25 rue Philippe Lebon - BP 54076058 LE HAVRE CEDEX

[email protected]://www-lih.univ-lehavre.fr/�duvallet/

Novembre 2005

Claude Duvallet , Bruno Sadeg, Laurent Amanton Les Systèmes de Gestion de Bases de Données Temps Réel et Multimédia — Année 2005-2006

Présentation

Qui je suis ?Claude DuvalletMaître de conférences en Informatique

D’où je viens ?Université du Havre en France

Mon domaine d’activité :Enseignements : programmation (Java, C/C++,...), systèmesd’exploitation, systèmes distribués (CORBA, RMI, RPC, etc.),architecture et protocoles réseaux, administration des systèmeslinux.Recherche : SGBD temps réel, systèmes multimédia, gestion dela qualité de service, etc.


Objectifs du cours

Les Systèmes de Gestion de Bases de Données Temps Réeldans une perspective multimédia.

Les concepts étudiésLes SGBD et les bases de données classiques (fait par FaiezGargouri)Les systèmes temps réelLes SGBD temps réel : notion de transactions temps réel, dedonnées temps réel, d’ordonnancement, de contrôle deconcurrence, de gestion de la qualité de service...

La gestion de la qualité de service pour la conception desystèmes multimédia.


Introduction et contexte

Des applications informatiques :qui sont de plus en plus sophistiquées en termes de traitement etde données.qui utilisent des données avec une période de validité limitée dansle temps.qui doivent fournir des résultats avant une échéance donnée.

Exemple : les systèmes de surveillance de sites industriels àhauts risques :

ils font appels à de nombreux domaines (chimie, météo, sécuritécivile) =) utilisation de nombreuses données.ils utilisent des données acquises à partir de capteurs(température, pression, ...) qui changent souvent de valeurs.ils doivent prévenir les utilisateurs (décideurs) suffisamment tôtpour éviter de potentielles catastrophes.


Un autre exemple d’application : les systèmes de vidéo à lademande

Principe :Un serveur qui met à disposition des contenus vidéo (des films).Des clients qui effectuent des demandes et visualisent cescontenus en temps réel sans les téléchargé mais au moyen d’unclient (lecteur) supportant le streaming vidéo.

Problématique temps réel :Des contenus multimédia qui représentent des quantités dedonnées très importantes.Des contraintes temps réel : les morceaux de films qui sonttransmis par le biais du réseau doivent être joués dans des délaisimpartis pour aboutir à une certaine fluidité et éviter les problèmesde synchronisation entre le son et la vidéo.

Les protocoles utilisés : RTSP/RTCPLes paquets vidéo sont transmis au format RTP (Real-TimePacket) : chaque paquet doit arrivé avant la fin de la lecture duprécédent pour pouvoir être joué.


Les Systèmes Temps Réel


Introduction et définitionsLes applications temps réel

Les architectures des systèmes temps réelL’ordonnancement des tâches temps réel

Les systèmes temps réel

Introduction et contexte : quelques définitions.

Les applications temps réel.

Les architectures des systèmes temps réel.

L’ordonnancement des tâches temps réel.

Les systèmes temps réel distribué.

L’ordonnancement des tâches et les messages temps réel.




Introduction (1/2)

Le temps : rôle de + en + important dans les services et lesapplications (informatique industrielle, télécommunications,...).

Informatique industrielle : prémisses de l’informatique temps réel.

En télécommunication :(1) débits élevés : la durée du trafic est bornée,(2) plusieurs flux d’information : synchronisation nécessaire

(multimédia).

Les services : à chaque service est liée une qualité de service(QoS) : temps d’établissement d’une connexion, temps deréponse d’une requête, etc.




Introduction (2/2)

Maîtrise du temps : d’abord, plus de puissance de calcul, puisapparition de mécanismes “légers” (moins de temps gaspillé pourdes parties non liées à l’application), enfin méthodes pour prédireles comportements temporels.

Plusieurs mécanismes à mettre en œuvre dans un OS poursupporter les applications temps réel, notammentl’ordonnancement des tâches.




Définition d’un système temps réel

Un système temps réel est un système dont le comportementdépend non seulement de l’exactitude des traitements effectués, maiségalement du temps où les résultats de ces traitements sont fournis.C’est-à-dire qu’un retard dans la production d’un résultat est considérécomme une erreur (pouvant entraîner de graves conséquences).




Schéma d’une application temps réel

événements

commandes

affichage

Système informatiquede contrôle

− automate

− mono−processeur

− multi−processeur

− réseau local

Procédé

− équipement élémentaire

− procédé complexe

− ensemble d’équipement

Actions

mesures

Observations




Illustrations/Exemples

Système temps réel : calcul de la position d’un bateau enmouvement. Même si le résultat fourni est exact, il est considérécomme erroné s’il est fourni en retard (le bateau a changé deposition)

Système non temps réel : gestion de notes des élèves. Si lesmoyennes calculées sont exactes alors le système est correct(aux arrondis près)




Types de temps réel

échéance dure (hard) : l’obtention d’un résultat en retardprovoque une exception dans le système.

échéance molle, lâche (soft) : le retard ne provoque pasd’exception

STR durs : les échéances ne doivent en aucun cas êtredépassées (sinon catastrophes humaines, technologiques, ...)

STR mous : les échéances peuvent être dépasséesoccasionnellement (usines automatisées)




Caractéristiques des systèmes temps réel (1/2)

La prévisibilité : un STR doit être conçu tel que sesperformances soient définies dans le pire cas.

Dans les systèmes classiques : les performances sont définies entermes de moyenne.La prévisibilité permet de savoir à l’avance si un système varespecter ses contraintes temporelles (connaître avec précisionles paramètres : temps global de calcul de chaque activité, lapériodicité, etc.).

L’ordonnancement : choix d’une politique d’ordonnancementdes activités de façon à ce que le système soit prévisible.




Caractéristiques des systèmes temps réel (2/2)

Le déterminisme : ce doit être un but à atteindre pour assurer laprévisibilité : il faut enlever toute incertitude sur le comportementdes activités (individuelles et mises ensemble).

Dans les STR "dur", on cherche à ce que toutes les échéancessoient respectées.

Dans les STR "mou", on cherche à minimiser le retard moyen desactivités par exemple.




Non-déterminisme et déterminisme dans les STR

Les sources du non-déterminisme :Charge de calcul (durées d’exécution variées).Entrées/sorties sur disque.Interruption : temps de réaction du système.Fautes et exceptions matérielles et logicielles.

Remarques :Le déterminisme absolu est difficile à atteindre.Mais, on améliore par des méthodes d’ordonnancement quianalysent a priori le comportement temporel du système.




La fiabilité (reliability)

Un autre aspect important des STR.

Il est difficile de prédire le comportement d’un système dont lescomposants ne sont pas fiables.

Il est donc nécessaire de concevoir des systèmes tolérants auxfautes.

Par exemple : les systèmes temps réel embarqués (real-timeembedded systems).




Les systèmes embarqués

Pas d’intervention humaine directe.

Ils doivent être prévisibles (et fiables).

Exemple : les rames de métro automatique, le pilotageautomatique d’avion, le contrôle de navette spatiale,...

Ce sont des systèmes dédiés : ”taillés spécialement” pour unetâche précise notamment en termes de ressources etéventuellement de redondance des ressources.




Exemples d’application

1. Le robot : doit prendre des objets qui défilent sur un tapisLe robot dispose d’une “fenêtre temporelle” pour agir.S’il agit trop tard, il manquera l’objet.S’il agit trop tôt, il va bloquer l’objet (et les objets suivants).

2. Système de vidéo-conférence : sur un réseau local.Le système numérise l’image, puis la séquence. Il faut que soienttraitées 30 images/sec pour une image acceptable.Plusieurs opérations vont s’enchaîner dans le temps :numérisation, compression, transmission. La durée de cesopérations = temps de latence du système.La voix doit également être numérisée, compressée et transmise.Il faut qu’il y ait synchronisation son/image. Un retard léger estacceptable. S’il est trop long, la scène devient incompréhensible(temps réel mou, ou échéances molles, relatives).




Limites des STR classiques pour le temps réel

Reposent sur un OS qui offre des mécanismes mal adaptés autemps réel

politiques d’ordonnancement visent le partage équitable du tempsd’exécution. Pas adaptées à des tâches plus critiques qued’autres.les mécanismes d’accès aux ressources partagées sont à adapterpour éliminer les incertitudes temporellesla gestion des E/S engendrent de longues attentes (parfois nonbornées)la gestion des interruptions n’est pas optimiséeles mécanismes de gestion de la mémoire virtuelle sont à revoir(swapping, ...)les temporisateurs qui organisent le temps n’ont pas unerésolution assez fine (pour beaucoup d’applications temps réel)




Sources d’incertitude

On ne dispose pas de moyens pour indiquer à au systèmed’exploitation le degré d’urgence d’une tâche.

Le temps de réponse des événements externes n’est pasprévisible :le système n’indique rien sur la durée de prise en compte d’uneinterruption.




Terminologie

Le noyau : il rend l’ensemble des services de base nécessaires àl’exécution d’une application (gestion mémoire, processeur,adressage, interruptions,...).

L’exécutif : il rend les services du noyau plus d’autres sanstoucher à l’interface utilisateur (surtout pour les systèmesembarqués).

le système d’exploitation : noyau + exécutif + interaction avecl’utilisateur.




Terminologie pour l’ordonnancement des tâches temps réel

Tâche = unité de base de l’ordonnancement temps réel.Les tâches peuvent être soit périodiques soit apériodiques.Les tâches peuvent être à contraintes temporelles strictes ourelatives.

Modèle : paramètres chronologiques (délais) et chronométriques(dates). Les paramètres de base d’une tâche sont :

r : sa date de réveil, moment de déclenchement de la 1ere requêted’exécution.C : sa durée maximale d’exécution (si elle dispose du processeurà elle seule).D : son délai critique (délai maximal acceptable pour sonexécution).P : sa période (si tâche périodique).S’il s’agit d’une tâche à contraintes strictes, l’échéance d = r + Dest la date dont le dépassement entraîne une faute temporelle.




Illustration : diagramme temporel d’exécution

D

C

P P

r0 d0 r1 d1 r2

temps

FIG.: Modèle des tâches




Commentaires

T (r0, C, D, P) avec 0 � C � D � P

r0 : date de réveil, C : durée max d’exécution,D : délai critique, P : période

rk : date de réveil de la keme requête de la tâche.rk = r0 + k P, représentée par "

dk : échéance de la keme requête de la tâche.dk = rk + D, représentée par #

Remarque : On appelle tâche à échéance sur requête unetâche pour laquelle D = P, représentée par l




Remarques

Tâche à contraintes relatives : D parfois omis

Tâche apériodique : pas de paramètre P

Plus les paramètres précédents sont exactes, plus la qualité del’ordonnancement est meilleure




Autres paramètres déduits

u = CP (doit être � 1) : facteur d’utilisation du processeur par la

tâche

ch = CD doit être (� 1) : facteur de charge du processeur

paramètres dynamiques (pour suivre l’exécution d’une tâche) :s : date de début de l’exécution d’une tâchee : date de fin d’exécution d’une tâcheD(t) = d� t : délai critique résiduel à la date t (0 � D(t) � D)C(t) = durée d’exécution résiduelle à la date t (0 � C(t) � C)L = D�C laxité nominale de la tâche, retard maximum pour sondébut d’exécution s quand la tâche s’exécute seule.L(t) = D(t)�C(t) laxité nominale résiduelle, retard maximumpour reprendre l’exécution d’une tâche si elle s’exécute seule(L(t) égal aussi D+ r � t�C(t)).TR = e� r : temps de réponse de la tâche

CH(t)= C(t)D(t) : charge résiduelle au temps t




Les états d’une tâche (1/2)

Une tâche peut être dans plusieurs états :

élue : un processeur est alloué à la tâche.

bloquée : la tâche attend une ressource, un message ou unsignal de synchronisation.

prête (éligible) : la tâche attend d’être élue.

passive : la tâche n’a pas de requête en cours.

inexistante : la tâche n’est pas créée.




Les états d’une tâche (2/2)

ELUE

PRETEBLOQUEE

PASSIVEINEXISTANTE

faute temporelle

faute

temporelle




Les autres caractéristiques d’une tâche (1/2)préemptible : tâche élue qui peut être arrêtée et remise à l’étatprêt, pour allouer le processeur à une autre tâche.non préemptible : une fois élue, la tâche ne doit plus êtreinterrompue jusqu’à la fin de la requête (tâches atomiques, àexécution immédiate).tâches indépendantes : lorsqu’elles n’ont pas de relations deprécédence et ne partagent pas de ressources critiques.tâches dépendantes :

par une relation de précédence statique : si elles agissent selonun ordre prédéterminé, ou induit par la communication parmessages ou par une relation explicite de synchronisation. Elleest statique car connue a priori. On peut construire le graphe dedépendances.par une relation de précédence dynamique : si elles partagent desressources critiques (accès en exclusion mutuelle). La relation estdynamique car l’utilisation de la ressource dépend de l’ordred’exécution des tâches.




Les autres caractéristiques d’une tâche (2/2)

priorité externe (fixe) : forme primitive d’ordonnancement tempsréel. Tout est déterminé par un ordonnancement hors ligne ou pardes règles qui imposent un ordre a priori (ex : tâche de gestionde l’horloge, tâche de sauvegarde en cas de chute de tension)

urgence : tâches de même urgence ! même échéance.

importance :tâches pouvant être supprimées en premier dans certains caspour permettre aux autres (plus importantes) de respecter leurscontraintes.2 tâches de même urgence peuvent avoir des importancesdifférentes.




Ordonnancement des tâches temps réel (1/2)

Son but est de permettre le respect des contraintes temporellesdes tâches d’une application quand elle s’exécute en modecourant.

Il doit être certifiable, c-à-d prouver a priori le respect des C.T.des tâches d’une application (en régime courant).

En régime de surcharge (tâches supplémentaires suite à desanomalies : alarmes, variations des temps d’exécution, ! fautestemporelles...) : l’ordonnancement doit offrir une tolérance auxsurcharges (permettre une exécution dégradée mais sécuritairedu système).

Configuration de tâches : mise en jeu d’un ensemble de n tâchesqui s’exécutent

Départ simultané : même date de réveil (sinon départ échelonné).




Ordonnancement des tâches temps réel (2/2)

Facteur d’utilisation du processeur pour n tâches périodiques :

U =i=n

∑i=1

Ci

Pi.

Facteur de charge du processeur pour n tâches périodiques :

CH =n

∑i=1

Ci

Di.

Laxité du processeur à l’instant t , LP(t) = intervalle de temps àpartir de t pendant lequel le processeur peut rester inactif sansremettre en cause le respect des échéances (LP(t) � 0, 8 t).LP(t) est égale au minimum des laxités conditionnelles LCi(t)des tâches i .LCi(t) = Di - ∑j Cj(t). Les tâches j sont celles qui sontdéclenchées à l’instant t et qui devancent i dans la séquence deplanification.




Définition du problème d’ordonnancement

Le système de conduite d’une application temps réel doit piloterle procédé en ordonnançant les tâches avec 2 objectifs :

assurer le respect des C.T. en fonctionnement nominalatténuer les effets des surcharges et maintenir le procédé dans unétat cohérent et sûr en fonctionnement anormal (pannesmatérielles ou logicielles)! respecter au moins les CT desrequêtes vitales pour le procédé

L’algorithme d’ordonnancement fournit une description de laséquence de planification de tâches à effectuer de manière àrespecter les CT.




Typologie des algorithmes d’ordonnancement (1/5)

Algorithme hors ligne :L’algorithme construit la séquence complète de planification destâches sur la base de tous les paramètres temporels des tâches.La séquence est connue avant l’exécution.Très efficace, mais cette approche statique est rigide car ellesuppose que tous les paramètres, y compris les dates de réveil,sont figées! ne s’adapte pas aux changements del’environnement.





Algorithme en ligne :Il est capable à tout instant de l’exécution d’une application dechoisir la prochaine tâche à ordonnancer, en utilisant lesinformations des tâches déclenchées à cet instant.Ce choix peut être remis en cause par l’occurrence d’un nouvelévénement.Cette approche dynamique offre des solutions moins bonnes (carelle utilise moins d’informations) et entraîne des surcoûts de miseen œuvre.Les avantages :

permet l’arrivée imprévisible des tâches,autorise la construction progressive de la séquenced’ordonnancement.

Pour pouvoir traiter les tâches apériodiques (et les surchargesanormales), l’ordonnancement se fait souvent en ligne.





Algorithme préemptif :Il permet à l’ordonnanceur de déposséder la tâche élue duprocesseur au profit d’une autre tâche jugée plus prioritaire.Il n’est utilisable que si toutes les tâches sont préemptibles.La tâche ayant perdu le processeur passe à l’état prêt pour êtreélue ultérieurement sur le même processeur ou sur un autre.

Algorithme non préemptif :Il n’arrête pas l’exécution d’une tâche élue.Des fautes temporelles peuvent se produire alors qu’unalgorithme préemptif les aurait évitées.





Meilleur effort (best effort) :Il est utilisable pour une application à contraintes relatives.La stratégie d’ordonnancement est celle du meilleur effort : elleessaie de faire au mieux avec les processeurs disponibles.

Pour une application à contraintes strictes :L’ordonnanceur doit garantir le respect des CT.Il y a obligation de réussite et non tolérance aux fautestemporelles.





Centralisé :Si l’algorithme d’ordonnancement s’exécute sur une architecturecentralisée (ou sur un site privilégié d’une architecture distribuée,qui contient tous les paramètres des tâches).

Distribué :Lorsque les décisions d’ordonnancement sont prises sur chaquesite par un ordonnanceur local après une éventuelle coopérationpour effectuer un ordonnancement global.Pour l’ordonnancement global, le placement des tâches sur unsite peut intervenir et la migration des tâches d’un site à un autre.




Propriétés des algorithmes d’ordonnancement (1/3)

Séquence valide : un algorithme d’ordonnancement délivre uneséquence d’ordonnancement valide pour une configuration detâches donnée si toutes les tâches respectent leur CT.

Une configuration est ordonnançable dès qu’il existe au moinsun algorithme capable de fournir une séquence valide pour cetteconfiguration.

Algorithme optimal : un algorithme est optimal s’il est capablede produire une séquence valide pour toute configuration detâches ordonnançables.

Test d’ordonnançabilité : il vérifie qu’une configuration detâches périodiques donnée soumise à un algorithmed’ordonnancement peut être ordonnancée selon une séquencevalide.





Test d’acceptabilité :Un algorithme en ligne modifie dynamiquement la séquenced’ordonnancement à l’arrivée de nouvelles tâches (ou à la suitede dépassement d’échéances).Une tâche nouvelle peut être ajoutée à la configuration s’il existeau moins une séquence valide avec la nouvelle configuration(tâches existantes + celle ajoutée).L’ensemble des conditions à satisfaire est le test d’acceptabilité(routine de garantie).Dans un ordonnancement réparti, le rejet d’une requête par cetest peut être résolu en essayant de migrer la tâche sur un autresite.





Période d’étude : pour valider une configuration de tâchespériodiques et apériodiques, on effectue une analyse temporellede l’exécution de la configuration.

Pour les tâches périodiques : il suffit d’effectuer l’analyse sur unepériode (car la configuration est périodique, et se répèteindéfiniment).

Début de la période d’étude : t = Min{ri0}, c-à-d date de réveil dela première requête de la première tâche de la configuration.

Fin de la période d’étude : Max{ri , 0, rj , Dj } + 2*PPCM(Pi ), i :tâches périodiques, j : tâches apériodiques (PPCM(Pi )seulement, si périodiques).




Mise en œuvre d’un ordonnanceur

Table d’élection : lorsque la séquence est connue a priori(ordonnancement hors ligne), cette séquence est inscrite dansune table consultée par l’ordonnanceur pour élire les tâches.

Liste d’attente avec priorités : l’ordonnancement en ligne )création dynamique d’une séquence de planification.Le premier élément indique la tâche élue (si monoprocesseur),les n premiers, si n processeurs.La liste est ordonnée selon les clés (priorités).

Priorité fixe : dans la liste d’attente, la clé (priorité) est fixe si onprend un paramètre fixe comme clé (durée d’exécution, délaicritique, période).

Priorité variable : si on prend comme clé un paramètre variable(date de réveil, échéance,...).




Ordonnancements classiques

Objectifs :maximiser le taux d’utilisation du processeur,minimiser le temps de réponse des tâches (durée séparantl’instant de soumission au système de l’instant de fin d’exécution).

Autres critères :temps d’attente des tâches (état prêt),débit du processeur (nombre de tâches traitées par unité detemps),moyenne du temps de réponse d’un ensemble de tâches), ...




Principales politiques d’ordonnancement (1/4)

) déterminer quelle tâche prête doit être élue

Premier arrivé, premier servi (les tâches de faible tempsd’exécution sont pénalisées si elles sont précédées dans la filepar une tâches de longue durée).

Plus court d’abord : remédie à l’inconvénient précédent. Minimisele temps de réponse moyen. Pénalise les travaux longs. Elleimpose d’estimer les durées d’exécution des tâches (connuesdifficilement).

Temps restant le plus court d’abord : la tâche en exécutionrestitue le processeur lorsqu’une nouvelle tâche ayant un tempsd’exécution inférieur à son temps d’exécution restant devientprête.




Principales politiques d’ordonnancement (2/4)Tourniquet (Round Robin) :

On définit un quantum de temps (10ms à 100ms).Chaque tâche de la file acquiert le processeur pendant aumaximum un quantum de temps, puis le cède à sa suivante dansla file, etc.

! utilisée souvent dans les système à temps partagé.Ses performances dépendent du quantum de temps : s’il est tropgrand, on augmente les temps de réponse, s’il est trop petit, onmultiplie les commutations de contextes.

Priorités constantes :Des priorités sont affectées aux tâches et à un instant donné, latâche élue est celle qui a la plus forte priorité.Les tâches de faible priorité peuvent ne pas disposer duprocesseur (famine).Solution : faire “vieillir” la priorité des tâches en attente(augmenter en fonction du temps d’attente). La priorité devientainsi variable (et donc non constante !)





Files de priorités constantes multi-niveaux :On définit plusieurs files de tâches prêtes.Chaque file correspond à un niveau de priorité (n files de prioritésvariant de 0 à n-1 : file i , tâches de même priorité).Elles sont gérées soit par ancienneté soit par tourniquet.Le quantum peut être différent selon la file.L’ordonnanceur sert d’abord les tâches de la file 0, puis celles dela file 1 (dès que la 0 se vide), etc.





Deux variantes des files de priorités constantes multi-niveaux :les priorités des tâches sont constantes tout au long de leurexécution : une tâche en fin de quantum est réinsérée dans lamême file.les priorités des tâches évoluent dynamiquement en fonction desservices dont elles ont déjà bénéficié. Une tâche de la file x , quin’a pas terminé son exécution à la fin de son quantum estréinsérée dans la file x +1 (moins prioritaire), etc.

) On minimise ainsi les risques de famine des tâches de faiblepriorité en diminuant petit à petit les priorités des tâches ayant defortes priorités initiales.

Remarque :Aucune des politiques présentées ne permet de remplir les 2objectifs d’un ordonnancement temps réel.Notament : pas de prise en compte de l’urgence des tâches (délaicritique)




Ordonnancement Rate Monotonic (1/3)

Algorithme d’ordonnancement en ligne, à priorité constante pourtâches indépendantes.

Priorité d’une tâche = fonction(sa période). La tâche de pluspetite période est la plus prioritaire.L’algorithme est optimal dans la classe des algorithmes à prioritéconstante pour une configuration de tâches à échéances surrequête.

Dans ce cas, on connaît une condition suffisante d’existenced’une borne minimale pour l’acceptation d’une configuration de ntâches :

n

∑i=1

Ci

Pi� n(2

1n �1)

Cette borne représente le pire cas et tend vers ln 2 quand n trèsgrand (c-à-d 69%). Elle peut être dépassée (en moyenne elle estde 88%)





Exemple : la figure du transparent suivant montre un exempled’ordonnancement “Rate Monotonic” pour 3 tâches périodiques àéchéance sur requête (échéance=période) :

T1(r0 = 0;C = 3;P = 20), T2(r0 = 0;C = 2;P = 5),T3(r0 = 0;C = 2;P = 10). Tâche de plus haute priorité : T2,tâche de plus basse priorité : T1.

La séquence d’étude est l’intervalle [0, 20]1.

Les 3 tâches respectent leur CT car la condition suffisante estvérifiée : on a bien 3

20 + 25 + 2

10 � 0.77.

Remarque : l’utilisation de la période comme critèred’ordonnancement limite l’application de “Rate Monotonic” auxseules tâches où l’échéance est égale à la période (échéancessur requête).

1Configuration à départ simultané, période d’étude [0, PPCM(Pi )]Claude Duvallet , Bruno Sadeg, Laurent Amanton Les Systèmes de Gestion de Bases de Données Temps Réel et Multimédia — Année 2005-2006




0

20

0

0

4 5

2 5 7 10 12 15 17

20

20

207 9

2 4 10

temps

temps

temps

12 14

T1 (r0=0, C=3, P=20)

T2 (r0=0, C=2, P=5)

T3 (r0=0, C=2, P=10)




Ordonnancement Inverse Deadline ou DeadlineMonotonic (1/3)

Algorithme d’ordonnancement en ligne, à priorité constante pourtâches indépendantes.

Priorité d’une tâche = fonction(son délai critique).

La tâche la plus prioritaire est celle de plus petit délai critique.

Cet algorithme est égal en performances à “Rate Monotonic”pour les tâches à échéances sur requête, et meilleur pour lesautres types de configurations de tâches.

Condition suffisante d’acceptabilité :n

∑i=1

Ci

Di� n(2

1n �1)





Exemple : la figure sur le transparent suivant montre l’exemple d’unordonnancement “Deadline Monotonic” pour 3 tâches périodiques :

T1(r0 = 0;C = 3;D = 7;P = 20), T2(r0 = 0;C = 2;D = 4;P = 5),T3(r0 = 0;C = 2;D = 9;P = 10).

Tâche de plus haute priorité : T2, tâche de plus basse priorité :T3.

La condition suffisante n’est pas vérifiée :37 + 2

4 + 29 = 1.14 > 0.77.

Cependant, le chronogramme construit sur la période d’étudemontre qu’elles sont ordonnançables sans faute temporelle.





0

0

temps

temps

temps

0

2 5 7 20

20

2019

19171514121097542

4 5 7 9 10 12 14

T2 (r0=0, C=2, D=4, P=5)

T3 (r0=0, C=2, D=9, P=10)

T1 (r0=0, C=3, D=7, P=20)




Ordonnancement Earliest Deadline (1/3)

Algorithmes en ligne à priorité variable : la priorité varie dans letemps.

La plus haute priorité à l’instant t est accordée à la tâche dontl’échéance est la plus proche.

Pour les tâches à échéances sur requête, une condition non

suffisante d’ordonnancement est :n

∑i=1

Ci

Pi� 1

Pour des tâches périodiques quelconques, une condition

suffisante est :n

∑i=1

Ci

Di� 1 et une condition nécessaire est :

n

∑i=1

Ci

Pi� 1.





Exemple : la figure du transparent suivant montre l’exemple d’unordonnancement “Earliest Deadline” pour 3 tâches périodiques.T1(r0 = 0;C = 3;D = 7;P = 20), T2(r0 = 0;C = 2;D = 4;P = 5),T3(r0 = 0;C = 1;D = 8;P = 10).

À t=0, les 3 tâches se réveillent, T2 est prioritaire, elle s’exécutependant 2 unités.

À t=2, T2 termine. C’est T1 la plus prioritaire. Elle s’exécutependant 3 unités de temps.

À t=5, T1 se termine et T2 se réveille de nouveau (car période 5),mais c’est T3 qui est cette fois la plus prioritaire car son échéanceest 8, elle s’exécute pendant une unité.

Ici, on voit que les priorités des tâches varient dans le temps : parexemple, à t=0, c’est T2 la plus prioritaire (que T1 et T3), mais àt=5, c’est T3 la plus prioritaire.





T(r0=0, C=3, D=7, P=20 )

T(r0=0, C=2, D=4, P=5 )

T(r0=0, C=1, D=8, P=10 )

0 2 5 7 20

20

20

5

5

5

0

0

6 8

6 8

4 9 10 12 14 15 17 192

12 13 1810




Ordonnancement Least Laxity ( LL) : (1/4)

Algorithmes en ligne à priorité variable : la priorité varie dans letemps.

La tâche de plus haute priorité à l’instant t est celle qui a la pluspetite laxité dynamique Li(t).

Cet algorithme est optimal et les conditions d’ordonnançabilitédes tâches sont les mêmes que pour Earliest Deadline.

Les séquences produites par LL sont équivalentes à cellesproduites par ED lorsque les valeurs des laxités sont calculéesaux dates de réveil.

Par contre, si on calcule la laxité à chaque instant alors laséquence produite par LL entraîne plus de changements decontextes que par ED.




Ordonnancement Least Laxity ( LL) : (2/4)

Les figures, qui se trouvent sur les transparents suivants,montrent l’ordonnancement avec LL pour les 3 tâches del’exemple sur ED, avec un calcul de laxité effectué aux seulesdates de réveil.

À t=0, les 3 tâches sont réveillées. Laxité dynamique deT1=7-3=4. Laxité de T2=4-2=2. Laxité de T3=8-1=7. C’est doncT2 (la + prioritaire) qui s’exécute à t=0 (pour 2 unités).

À t=2, c’est T1 qui s’exécute (sa laxité [7-2-3] est plus petite quecelle de T3 [8-2-1] ).

À t=5, T2 se réveille de nouveau. Sa laxité dynamique (9-5-2 =2ème échéance - temps courant - durée exécution) est égale à 2,celle de T3 (8-5-1) est de 2 également (retard ’toléré’ t.q.l’échéance est toujours respectée). On peut choisir T3 (cas a) ouT2 (cas b) pour être ordonnancée et s’exécuter.




Ordonnancement Least Laxity ( LL) : (3/4)T 1 (r0=0, C=3, D=7, P=20)

T 1 (r0=0, C=2, D=4, P=5)

T 1 (r0=0, C=1, D=8, P=10)

0 2 5 7 20

0 2 4 5 6 8 9 10 12 14 15 17 19 20

0 5 6 8 10 13 18 2012

tempstemps

temps

temps

FIG.: Ordonnancement “Least Laxity”. Cas (a) : c’est T3 qui est élue à t=5Claude Duvallet , Bruno Sadeg, Laurent Amanton Les Systèmes de Gestion de Bases de Données Temps Réel et Multimédia — Année 2005-2006



Ordonnancement Least Laxity ( LL) : (4/4)T 1 (r0=0, C=3, D=7, P=20)

T 1 (r0=0, C=2, D=4, P=5)

T 1 (r0=0, C=1, D=8, P=10)

0 2 5 7 20

0 2 4 5 9 10 12 14 15 17 19 20

0 8 10 13 18 2012

tempstemps

temps

temps

7

7

FIG.: Ordonnancement “Least Laxity”. Cas (b) : c’est T2 qui est élue à t=5Claude Duvallet , Bruno Sadeg, Laurent Amanton Les Systèmes de Gestion de Bases de Données Temps Réel et Multimédia — Année 2005-2006



Algorithmes pour les tâches apériodiques

But : les contraintes temporelles des tâches périodiques doivent êtrerespectées et :

(1) soit minimiser le temps de réponse des tâches apériodiques àcontraintes relatives Best Effort),

(2) soit maximiser le nombre de tâches apériodiques à contraintesstrictes qui respectent leurs CT .




Traitement en arrière-plan (Background Processing) (1/3)

Tâches apériodiques à contraintes relatives arrière-plan,serveurs de tâches, ...

Les tâches apériodiques sont ordonnancées lorsque leprocesseur est oisif (pas de tâche périodique prête). Si 9plusieurs tâches apériodiques, traitement par date de réveil(FIFO).

La figure du transparent suivant montre un tel ordonnancementsur un intervalle égale à 2 fois la période d’étude d’uneconfiguration de 2 tâches périodiques à échéances sur requêteT1(r0 = 0;C = 2;P = 5), T2(r0 = 0;C = 2;P = 10).

L’application de ’Rate Monotonic’ à cette configuration laisse leprocesseur oisif sur les intervalles [4,5], [7,10], [14,15] et [17,20].




Traitement en arrière-plan (Background Processing) (2/3)

La tâche apériodique Ta3(r = 4;C = 2) survenant à t = 4 peutimmédiatement commencer son exécution qu’elle finit sur letemps creux suivant c-à-d entre les temps t = 7 et t = 8.

La tâche apériodique Ta4 (r=10, C=1) qui survient à t=10 doitattendre le temps creux [14,15] pour s’exécuter.

La tâche apériodique Ta5 (r=11, C=2) doit attendre le tempscreux [17,20] pour s’exécuter.




Traitement en arrière-plan (3/3)T1 (r0=0, C=2, P=5)

T1 (r0=0, C=2, P=10)

Temps creux

Taches apériodiques

Tap (r=4, C=2)Tap (r=10, C=1)

Tap (r=11, C=2)

0

0

0

0

2 5 7 10 12 15 17 20

20

20

20

2 4 10 12 14

4 5 7 10 14 15 17

4 5 7 8 14 15 17 1910 11

temps

temps

temps

temps




Tâches apériodiques à contraintes relativesarrière-plan, serveurs de tâches,...

Remarque :La méthode d’ordonnancement en arrière-plan est simple, peucoûteuse et applicable 8 l’algorithme d’ordonnancement des tâchespériodiques.Mais les temps de réponse des tâches apériodiques peuvent êtremauvais surtout si la charge des tâches périodiques est importante.




Les serveurs de tâches

Un serveur est une tâche périodique créée spécialement pourveiller à l’ordonnancement des tâches apériodiques.

Elle est caractérisée par une période et un temps d’exécution (lacapacité du serveur).

Elle est souvent ordonnancée avec le même algorithme que lesautres tâches périodiques.

Une fois active, la tâche serveur sert les tâches apériodiquesdans la limite de sa capacité.

L’ordre de service des tâches apériodiques ne dépend pas del’algorithme d’ordonnancement des tâches périodiques (il peutêtre FIFO, fonction(échéances), fonction(temps d’exécution), ...).

9 plusieurs types de serveurs : le plus simple est le serveur parscrutation. Les autres (serveur ajournable, à échange de priorité,sporadique) en sont des améliorations.




Ord. “avec un serveur par scrutation” (1/4)À chaque activation, le serveur traite les tâches apériodiques enattente depuis son activation précédente, jusqu’à épuisement desa capacité (ou plus de tâches en attente).Si, lors d’une nouvelle activation, il n’y a aucune tâcheapériodique en attente, le serveur se suspend jusqu’à laprochaine occurrence : sa capacité (temps d’exécution) estrécupérée par les tâches périodiques.Transparent suivant : exemple de serveur par scrutation.Configuration :

2 tâches périodiques à échéances sur requête T1(r0=0, C=3,P=20) et T2(r0=0, C=2, P=20).La tâche serveur est Ts(r0=0, C=2, P=5) est de plus grandepriorité (car plus petite période) avec “Rate Monotonic” appliquépour ordonnancer les 3 tâches.On vérifie que la condition d’acceptabilité est remplie :3

20 + 210 + 2

5 = 0.75 � 0.77




Ord. “avec un serveur par scrutation” (2/4)

0

0

0

0

20

20

20

20

2 10 12 14

temps

temps

temps

temps

T1 (r0=0, C=3, P=20)

T2 (r0=0, C=2, P=10)

Tps (r0=0, C=2, P=5)

taches apériodiques

2 5

4 5 107

capacité du serveur

Tap1(r=4, c=2)Tap1(r=10, c=1) Tap1(r=11, c=2)

5 7 10 12 15 16

11 12 15 16

12





Commentaires :

À t=0, aucune tâche apériodique, donc le serveur se suspendimmédiatement. C’est T2 de priorité élevée suivante quis’exécute, puis c’est T1.

À t=4, la tâche apériodique Ta3 survient. Elle doit attendrel’occurrence suivante du serveur (t=5) pour s’exécuter. Elleépuise alors toute la capacité (C=2) du serveur.

À t=10, le serveur se réveille de nouveau, il sert la tâcheapériodique Ta4 qui vient d’être activée. Puis, il sert Ta5. La tâcheTa5 ne peut s’exécuter entièrement car elle épuise la capacitérestante du serveur.

Elle doit attendre l’occurrence suivante du serveur à t=15 pourfinir son exécution. Il reste encore une unité au serveur, il la perdcar il n’y a aucune tâche apériodique à servir.





Remarques :

Faiblesses : lorsque le serveur est prêt, si pas de tâches à traiter,sa capacité est perdue. Si des tâches apériodiques surviennent,elles doivent attendre l’occurrence suivante.

Amélioration : serveur “ajournable” : si pas de tâche apériodiqueà servir, le serveur prêt conserve sa capacité. Il est donc prêt àservir d’éventuelles tâches apériodiques qui surviennent. MAIS, ilviole le principe de “Rate Monotonic” (tâche prête de plus hautepriorité doit s’exécuter). Il diminue le taux d’utilisation duprocesseur par les tâches périodiques.




Ordonnancement “avec un serveur sporadique” (1/3)

Il améliore le temps de réponse des tâches apériodiques sansdiminuer le taux d’utilisation du processeur des tâchespériodiques.

Ce serveur est également une tâche périodique de plus hautepriorité, qui conserve sa capacité de traitement si, à son réveil, iln’y a pas de tâche apériodique à servir.

Mais ici, le serveur sporadique ne retrouve pas sa capacitéinitiale à chaque occurrence.

La figure sur le transparent suivant montre le fonctionnement d’unserveur sporadique sur le même ensemble de tâches queprécédemment : T1(r0=0, C=3, P=20) et T2(r0=0, C=2, P=20). Latâche serveur est Ts(r0=0, C=2, P=5).

À t=0, le serveur se réveille, mais se suspend car pas de tâchesapériodique à traiter (mais il conserve sa capacité, 2).




Ordonnancement “avec un serveur sporadique” (2/3)À t=4, la tâche apériodique Ta3 survient. Elle est servieimmédiatement entre t=4 et t=6 et consomme toute sa capacité.Comme le serveur s’est exécuté, une date de réinitialisation desa capacité est calculée : ce sera t=4+5. La valeur deréinitialisation est 2.À t=9, le serveur retrouve toute sa capacité, mais il se suspendcar il n’y a pas de tâche apériodiques en attente.À t=10, la tâche Ta4 arrive et s’exécute tout de suite pendant uneunité (C=1). Puis Ta5 arrive et commence à s’exécuter pendantune unité et elle est suspendue jusqu’à nouvelle occurrence duserveur (car sa capacité est épuisée).Une nouvelle date de réinitialisation de la capacité est calculée :t=10+5. La tâche Ta5 poursuivra son exécution pour une unitéquand le serveur aura récupéré sa capacité à t=15.Il reste au serveur 1 unité qu’il récupérera à t=20.




Ordonnancement “avec un serveur sporadique” (3/3)

0

0

0

0

20

20

20

20

2 10 12 14

temps

temps

temps

temps

T1 (r0=0, C=3, P=20)

T2 (r0=0, C=2, P=10)

Tps (r0=0, C=2, P=5)

taches apériodiques

2

4 10

capacité du serveur

Tap1(r=4, c=2)Tap1(r=10, c=1) Tap1(r=11, c=2)

11 12 15 16

4 6 7

6

1210012

96 15




Tâches apériodiques à contraintes strictes (1/2)Une méthode consiste à doter les tâches apériodiques avec despseudo-périodes :

C’est l’intervalle minimal entre deux occurrences successivesd’une tâche apériodique.On utilise “RM” pour ordonnancer les 2 types de tâches.Difficulté : l’évaluation de la pseudo-période et la sous-utilisationdu processeur.

Une autre méthode :Les tâches apériodiques sont traitées sans hypothèse sur leurrythme d’arrivée.Elles sont ordonnancées selon “Earliest Deadline”.À chaque arrivée d’une tâche apériodique, une “routine” degarantie teste dynamiquement si la nouvelle tâche peut s’exécuteren respectant ses CT, celles des tâches périodiques et celles desautres tâches apériodiques précédemment acceptées mais nonterminées.Si le test est positif, la tâche est acceptée.




Tâches apériodiques à contraintes strictes (2/2)

9 2 politiques d’acceptation dynamique de tâches apériodiques quifavorisent toutes les 2 les tâches périodiques, car les tâchesapériodiques génératrices de surcharge sont rejetées.Ces politiques sont applicables notamment sur un système réparti oùun mécanisme de partage de charge permet de faire exécuter unetâche rejetée sur un site par un autre site moins chargé.Ces 2 politiques sont :

Ordonnancement “ dans les temps creux”.

Ordonnancement “conjoint”.




Ordonnancement “dans les temps creux” (1/4)Acceptation dans les temps creux d’une séquence rigide detâches.Elle consiste à ordonnancer les tâches apériodiques dans lestemps creux de la séquence d’ordonnancement “ED” des tâchespériodiques.Proche de la politique en ’arrière-plan’ vue précédemment, maisici les tâches apériodiques ont des CT à respecter et sontelles-mêmes ordonnancées selon “ED”.À chaque réveil d’une tâche apériodique, la routine de garantie :

1. teste l’existence d’un temps creux suffisant pour l’exécution de latâche apériodique entre sa date de réveil et son échéance.

2. si ce temps creux existe, elle vérifie que l’acceptation de lanouvelle tâche ne remet pas en cause le respect des CT detâches apériodiques précédemment acceptées, non encoreachevées. Cette vérification ne concerne que les tâchesapériodiques dont les échéances sont � à celle de la nouvelle.




Ordonnancement “dans les temps creux” (2/4)

Si au moins une des conditions 1 ou 2 n’est pas satisfaite, alors latâche est rejetée, sinon elle est ajoutée à l’ensemble des tâchesapériodiques acceptées, pour être exécutée selon son échéance.

Exemple : La figure du transparent suivant montre que laconfiguration périodique “ED” présente durant la période d’étude3 intervalles de creux : [8,10], [13,15] et [17,20].

Les 3 tâches apériodiques Ta4, Ta5 et Ta6 peuvent être acceptéesdans ces temps creux : à t=4, Ta4 se réveille.Le temps creux existant entre sa date de réveil et son échéanceest l’intervalle [8,10] = 2 unités juste suffisantes pour exécuter latâche.Ta4 dispose donc d’assez de temps pour s’exécuter dans lerespect de ses CT, et comme il n’a pas d’autre tâchesapériodiques précédemment acceptées mais non terminée, elleest acceptée.




Ordonnancement “dans les temps creux” (3/4)À t=10, Ta5 se réveille. Le temps creux existant entre sa date deréveil 10 et son échéance 18, est de 3 unités (tout l’intervalle[13,15] + 1 unité de l’intervalle [17,20]).Il y a donc d’assez de temps pour exécuter Ta5 qui a un tempsd’exécution égal à 1. Et comme il n’a pas de tâches apériodiquesacceptées et non terminées (Ta4 s’était exécutée entre 8 et 10),alors Ta5 peut être acceptée.À t=11, Ta6 se réveille. Le temps creux existant entre sa date deréveil 11 et sont échéance 16 est de 2 unités ([13,15]), donc justesuffisant pour l’exécuter dans le respect de son échéance.Mais, il faut vérifier que son acceptation ne remet pas en causeles CT des autres tâches apériodiques acceptées non terminées(et d’échéances plus éloignées que la sienne).Ici Ta5 qui n’a pas encore commencé son exécution et dontl’échéance est 18.L’ordre d’exécution devient Ta6 puis Ta5 et on constate quechacune peut s’exécuter dans le respect de ses CT (car C=2 pourTa6 et C=1 pour Ta5).




Ordonnancement “dans les temps creux” (4/4)

0

0

20

202

temps

temps

2 5

8

T1 (r0=0, C=3, D=7, P=20)

T1 (r0=0, C=2, D=4, P=5)

temps

0

7

4 5 6 9 10 12 14 1715 19

65 10 1812 13 208

T1 (r0=0, C=1, D=8, P=10)

8 10 13 15 17 20

temps creux

4 8 10 13 18 20

Tap1(r=4, c=2, d=10)

11 15 1716

taches aperiodiques

Tap2(r=10, c=1, d=18) Tap3(r=11, c=2, d=16)




Ordonnancement “conjoint” (1/4)Acceptation des tâches apériodiques et ordonnancement conjointaux tâches périodiques.

À chaque arrivée d’une nouvelle tâche apériodique, il y aconstruction d’une nouvelle séquence “ED” comprenant à la foisles tâches périodiques, les tâches apériodiques précédemmentacceptées mais non terminées et la nouvelle tâche.

Si la séquence peut être construite, alors la tâche est acceptée.

Les figures sur les transparents suivants montrent un exemple defonctionnement et on voit que les 3 tâches apériodiques Ta4, Ta5

et Ta6 peuvent être ordonnancées conjointement aux tâchespériodiques.

À t=4, Ta4 se réveille. La séquence “ED” construite à t=4comprend les tâches périodiques actives T1(C(4)=1, d=7) et T3,les requêtes à venir des tâches périodiques ainsi que la tâche quiarrive Ta4.




Ordonnancement “conjoint” (2/4)L’exécution de celle-ci sera planifiée entre t=8 et t=10. Laséquence respecte les CT de toutes les requêtes qui lacomposent.

À t=10, Ta5 se réveille. La séquence “ED” construite à t=10comprend les requêtes à venir des tâches périodiques T2 et T3 etcelle de Ta5. Ici aussi, la séquence “ED” permet le respect desCT de toutes les requêtes qui la composent. L’exécution de Ta5

acceptée est planifiée entre 13 et 14.

À t=11, Ta6 se réveille (figure suivante 2.12). La séquence “ED”construite à t=11 comprend les tâches périodiques activesT2(C(11)=1, d=14) et T3, les requêtes à venir de la tâchepériodique T2 ainsi que les tâches apériodiques Ta5 et Ta6. Latâche Ta6 peut être ordonnancée sans remettre en cause ni leséchéances des tâches périodiques, ni celle de la tâcheapériodique Ta5. Ta6 est donc acceptée.




Ordonnancement “conjoint” (3/4)

0

0

20

202

temps

temps

2 5

8

T1 (r0=0, C=3, D=7, P=20)

T1 (r0=0, C=2, D=4, P=5)

temps

0

7

4 5 6 9 10 12 14 1715 19

65 10 1812 13 208

T1 (r0=0, C=1, D=8, P=10)

8 10 13 20

Tap4(r=4, c=2, d=10) Tap5(r=10, c=1, d=18)

taches aperiodiques

4

temps

14 18




Ordonnancement “conjoint” (4/4)

��

0

0

20

202

temps

temps

2 5

8

T1 (r0=0, C=3, D=7, P=20)

T1 (r0=0, C=2, D=4, P=5)

temps

0

7

4 5 6 9 10 12 14 15 19

65 10 188

T1 (r0=0, C=1, D=8, P=10)

8 10

Tap4(r=4, c=2, d=10) Tap5(r=10, c=1, d=18)

taches aperiodiques

4

temps

14 18

1816

14 15

12 15 1611

Tap6(r=11, c=2, d=16)

20

20




Ordonnancement de tâches dépendantes (1/2)

Contraintes de précédence : Ti ! Tj si Tj doit attendre la fin del’exécution de Ti pour commencer son exécution.

Si A précède B alors {(1) rB � rA, (2) si A périodique alors B l’estégalement et (3) priorité(A) > priorité (B)}

Contraintes de précédence et ’Rate Monotonic’ : dans le cas del’ordonnancement selon “RM”, on transforme hors lignel’ensemble des tâches liées par une contrainte de précédence enun ens. de tâches indépendantes pour lesquelles le testd’acceptabilité de “RM” est valide, en faisant :

Le calcul des dates de réveil : r�i = max{ri , r�pred } avec r�pred datede réveil de la tâche précédant la tache i .Si A et B ont la même période avec A qui précède B alors priorité(A) > priorité (B)




Ordonnancement de tâches dépendantes (2/2)Contraintes de précédence et ’Earliest Deadline’ : la prise encompte de la précédence est réalisée en modifiant ri , di ,r�i , d�i ,selon les formules :

r�i = max{ri , max(r�pred + Cpred ) }, c-à-d la date de début d’unetâche doit être supérieure à toutes les dates de début de sesprédécesseurs immédiats augmentées de leurs duréesd’exécution.d�

i = min{di , min(d�succ- Csucc) }, c-à-d pour une instance donnée,

l’échéance d’une tâche doit être inférieure à toutes les échéancesde ses successeurs immédiats diminuées de leurs tempsd’exécution.

Tâches partageant des ressources critiques : problèmes.Évaluer le temps de réponse d’une tâche.Inversion de priorité : apparaît quand une tâche A est retardéepar une tâche moins prioritaire B (car A a demandé uneressource déjà détenue par C, moins prioritaire que A et B).Interblocage.




Protocoles prenant en compte les ressources partagées

Héritage de priorité (PIP, Priority Inheritance Protocole) : résout leproblème d’inversion de priorité : la tâche en section critiquehérite de la plus haute priorité parmi celles des tâches en attente(bloquées). La durée de l’attente des tâches peut être très grande(car l’interblocage n’est pas résolu).

Priorité plafond (PCP, Priority Ceiling Protocol) : Limite la duréemaximale de blocage des tâches à la durée d’une section critiqueet prévient les interblocages (deadlock). L’idée est que chaqueressource se voit affectée une priorité égale à celle de la tâchede plus haute priorité qui va y accéder.




Ordonnancement conjoint : tâches et messages (1/3)

Systèmes temps réel et répartis :Communication intra et inter sites.Envoi de messages.Problème : respecter les temps de transfert des messages enbornant les délais.

Un message peut être caractérisé par :sa criticité (criticality ) : ce sont les contraintes de temps associéesau messagesa longueur : nombre d’octets composant le message. Lesmessages sont transmis trame par trame sur le réseau. Lalongueur d’une trame = f(type de réseau)son type : synchrone, asynchroneson adresse de destination




Ordonnancement conjoint : tâches et messages (2/3)Plusieurs protocoles sont définis, en fonction du type de réseau :

Réseau à commutation de paquets :Chaque station est reliée au réseau et ne connaît pas lesprotocoles utilisés pour communiquer à l’intérieur du réseau.La station établit une connexion selon un contrat lui garantissantune certaine QoS (taux de perte, délai max, ...).La station (considérée comme un abonné) s’adresse au nœud(commutateur ATM par exemple) auquel elle est raccordée, et lenœud se charge du transfert.Les stations ne rentrent pas en conflit.

Réseau à accès multiple :Les stations connectées au réseau contrôlent l’accès au réseauvia une technique MAC (Medium Access Control) implantée surchaque station.L’accès au médium est soit par compétition, soit par consultation(jeton).Les mécanismes d’ordonnancement des messages sontimplantées dans les stations (pour respecter les CT).




Ordonnancement conjoint : tâches et messages (3/3)

Ordonnancement des messages : les techniquesd’ordonnancement sont adaptées de celles des tâches (ED, RMnotamment).

Pour ordonnancer les tâches, on doit connaître leurs tempsd’exécution.

Pour ordonnancer les messages, il faut connaître leurs temps detransmission. La durée de transmission est fonction de la taille dumessage, du débit et de la longueur du réseau, du format destrames réseau utilisées et du protocole.

Exemple : pour le bus à jeton, la durée de transmission d’unmessage de n octets est 96+8xn µ s (on considère que lesadresses sont codées sur 2 octets, un seul octet est utilisécomme information pour la trame, on néglige le délaiinter-trames. Le délai de transmission du jeton est 96 µ s)




Exemple : Bus à jeton

Ensemble des stations = anneau logique.

Le droit d’émettre est réservé à une seule station : celle qui a lejeton.

Quand une station a le jeton, elle émet des trames pendant unedurée fixée, puis transmet le jeton.

Le bus à jeton peut fonctionner avec ou sans priorités.

Des paramètres sont utilisés : temps de possession du jeton, 3compteurs de rotation du jeton, notamment.

Avec tous ces éléments, des protocoles spécifiques sont définispour ordonnancer les tâches et les messages dans un systèmedistribué.




Les SGBD Temps Réel

Systèmes de gestion de bases de données permettant derespecter :

Les contraintes logiques de la base de données (respecter lescontraintes d’intégrité), etSes contraintes temporelles (Chaque transaction doit respecterson échéance)




Les Systèmes de Gestion deBases de Données Temps

Réel




La gestion de la qualité deservice dans les SGBD temps

réel


IntroductionProblématique et définitions

Qualité de serviceUne approche basée sur QdS

Plan de la présentation

Introduction et contexte.

Quelques définitions.Qualité de Service (QdS, QoS),Qualité des Données (QdD, QoD),Qualité des Transactions (QdT, QoT).

Problématique.

Spécification de la qualité de service dans les SGBDTR.

Le contrôle de la qualité de service.

Conclusion et problèmes de recherche.




Introduction et contexte

Les applications informatiques rendent des services auxutilisateurs.

Sophistication des applications (production, serveurs Web,commerce électronique, etc.) en terme des données requises.

Répondre aux requêtes des utilisateurs avant échéance et enutilisant des données récentes.

) accroissement des demandes de services de données tempsréel, utilisation de SGBD temps réel.

La charge des bases de données est imprévisible et peut devenirtrès vite importante (surcharge du SGBDTR).

) Dépassement des échéances et utilisation de données nonrécentes durant ces phases de surcharge.




Objectifs

Utiliser une approche basée sur la qualité de service pourgarantir des exigences sur le comportement des BD même encas de surcharge.

Important pour les applications reposant sur une exécution destransactions en temps réel et où il n’est pas possible d’avoir uneanalyse précise des arrivées et des temps d’exécution.

Une première approche :utilisation de techniques du calculs imprécis : faire un compromissur les ressources nécessaires pour obtenir la qualité de servicerequise.imprécision sur les données (QdD) et sur les transactions (QdT)afin de fournir la qualité de service demandée.

) utilisation d’algorithmes d’équilibrage de charge dynamiques.




Les algorithmes d’équilibrage de chargesExemples : FCS-IC-1, FCS-IC-2.

Objectif : contrôler le comportement d’un SGBDTR même enprésence de variation de la charge et d’estimations imprécisesdes temps de calculs.Dans Amirijoo et al. :

ensemble d’expérimentations pour évaluer les performances deces algorithmes.simulations avec un grand nombre de cas de surcharge et detemps d’exécution estimé pour modéliser les imprévisibilitéspotentielles.

) comportement robuste et contrôlé des SGBDTR en termes dequalité des transactions et des données même en phase desurcharges et lorsque les temps d’exécution estimés sontimprécis.méthodes utilisées pour prouver l’amélioration : comparaison avecdes algorithmes de base.




Quelques définitions (1)

Données non temporelles :Ce sont les données classiques des applications informatiques.

Données temporelles :Ce sont des données qui possèdent une durée de vie limitée audelà de laquelle elles deviennent obsolètes (non fraîches). Leurdurée de vie correspond le plus souvent à la périodicité aveclaquelle elles sont mises à jour.

Transactions de mise-à-jour :Ce sont des transactions (en générale périodiques) qui mettent àjour des données de la base à partir de valeurs recueillies depuisdes capteurs.




Quelques définitions (2)

Transactions utilisateurs :Elles correspondent aux transactions effectuées par lesutilisateurs, c’est-à-dire des demandes d’information oud’opérations sur les données. Elles se caractérisent à la fois pardes opérations de lecture mais aussi d’écriture dans la base dedonnées.

Qualité des données :Elle correspond à la précision ou l’erreur constatée sur la valeurstockée par rapport à la valeur réelle.

Qualité des transactions :Elle correspond à la précision du résultat fourni par la transactionpar rapport à une précision optimale obtenue lors d’un calculcomplet.




Qualité de service : définition

Mesure collective du niveau de service fourni au client. La QdS peutêtre caractérisée par différents critères de performances de base quiincluent la disponibilité, le taux d’erreurs, le temps de réponse, le tauxde transactions réussies avant échéances, etc.




Les paramètres de la qualité de serviceParamètres temporels :

temps de transfert, temps de réponse, temps d’établissementd’une connexion.

Paramètres volumiques :quantité de données qu’une application souhaite transmettre parunité de temps.

Paramètres d’erreurs :pertes de paquets, livraisons tardives ou désordonnées despaquets, erreur d’établissement ou de fermeture de connexion.

Paramètres de fiabilité :la disponibilité et la tolérance aux fautes.

Paramètres de sécurité :degré de protection, de contrôle d’accès, authentification etconfidentialité.

Paramètres de coûts :le prix que l’utilisateur est prêt à supporter pour obtenir la qualitéde service demandée.




Spécification de la qualité de service

Effectuée par le DBA à l’aide de paramètres.

Trois manières possibles d’exprimer ces paramètres :Approche déterministe : les paramètres sont exprimés au moyende valeurs ou d’intervalles de valeurs précis.Approche probabiliste : la qualité de service doit être respectéeselon une certaine probabilité) une plus grande flexibilité.Approche stochastique : l’utilisateur spécifie un ensembled’événements qui sont liés à la satisfaction de la qualité deservice de façon à ce qu’elle soit conforme à une certainedistribution stochastique.

Les valeurs de la qualité de service varient d’un domained’application à un autre.




Point de départ

Des données temporelles mises à jour par des transactions demise à jour.

Des transactions utilisateurs effectuant des opérations complexesde lecture/écriture.

Imprécision sur les données et sur les transactions utilisateurs.

La qualité des données augmente au fur et à mesure quel’imprécision sur les données décroît.

La qualité des transactions augmente au fur et à mesure quel’imprécision des résultats produits par les transactions décroît.

La qualité des transactions utilisateur est liée à la qualité desdonnées (si la qualité des données décroît alors la qualité desrésultats fournis par les transactions décroît).




Problématique

Hypothèse : indépendance entre la qualité des transactionsutilisateurs et la qualité des données.

Spécification du niveau de qualité désiré en termes d’état stableet d’état de surcharge du comportement des données et destransactions utilisateurs.

Objectif : adapter le comportement du SGBDTR afin de satisfaireune qualité de service spécifiée.

Fixer les paramètres de la qualité de service.

Comment respecter ou adapter ces paramètres pour obtenir unestabilité du comportement du SGBDTR même lorsque la chargedevient très importante.




Solution envisagée (1)

L’approche utilisée :Répartir la charge entre les transactions de mise à jour et lestransactions utilisateurs.

) Diminuer la charge des transactions utilisateurs amène àaugmenter les ressources disponibles pour les transactions demise à jour.

) Diminuer la charge des transactions de mise à jour provoque uneaugmentation de la qualité des transactions "utilisateur".

Imprécision des données :admettre un certain écart entre la donnée stockée dans la base etsa valeur dans le monde réel,si un tel écart peut-être toléré alors on peut ignorer certainestransactions de mise à jour,la mesure de la qualité s’effectue au moyen de la notion d’erreursur la donnée (DE = Data Error).




Solution envisagée (2)

Imprécision des données (suite) :soit di un objet et Tj une transaction mettant à jour di .l’erreur sur la donnée di est nommée DEi . C’est une fonction de lavaleur courante de la donnée (CurrentValuei ) de di et de la valeurmise à jour (UpdateValuej ) par la dernière transaction de mise àjour Tj .DEi = Φ(CurrentValuei ;UpdateValuej).l’erreur sur la donnée d’un objet donne une indication sur ladéviation de la valeur stockée par rapport à sa valeurcorrespondante dans le monde réel et qui a été mise à jour par ladernière transaction arrivée.ajustement de la charge de la mise à jour en fonction de l’erreursur la donnée manipulée (prise en compte de la marge supérieurede la déviation).marge supérieure donnée par MDE (Maximum Data Error).




Problématique du rejet des transactions de mise à jour

Rejet ou pas rejet ?Tj rejetée si l’erreur sur la donnée (di ) qui doit être mise à jour parTj est � à MDE (DEi �MDE).Tj exécutée et commitée si DEi > MDE .

Conséquences des changements de valeur de MDE :MDE%) plus de transactions rejetées (erreur sur la donnéeplus grande et donc une qualité de donnée moins bonne).MDE&) moins de transactions rejetées (erreur sur la donnéeplus faible et donc une qualité de donnée accrue).

Objectif : concevoir des algorithmes pour ajuster l’erreur sur ladonnée de telle façon que la qualité des données et destransactions utilisateurs satisfasse la qualité de service spécifiée.




Modèles utilisés (données, bases de données)

Modèle de bases de données :SGBDTR avec contraintes strictes non critiques (firm),SGBD en mémoire principale.

Modèle de données et gestion des données :données temporelles et non temporelles,données temporelles : données de base représentant le monderéel et acquises par des capteurs,une donnée de base di est considérée comme temporellementinconsistante ou obsolète si on a dépassé l’estampille de diaugmentée de l’intervalle validité absolue de di (AVIi ) :

CurrentTime > Timestampi + AVIi

DEi = 100�jCurrentValuei �UpdateValuej j

jCurrentValuei j




Modèle de transaction (1)

Transactions de mise à jour (MAJ) et transactions utilisateur :MAJ : transactions périodiques écrivant des données temporelles,Utilisateurs : transactions apériodiques lisant des objets temporelset lisant/écrivant des objets non temporels.

Une transaction Ti est composée :d’une sous-transaction obligatoire Mi ,de #Oi sous-transactions optionnelles, notée Oi;j où 1 � j � #Oi

ti 2 {Mi , Oi;j , ... ,Oi;#Oi }

Décomposition des transactions effectuée selon l’approche deMilestone

les transactions peuvent fournir des résultats imprécis dont laprécision augmentera en fonction du nombre de sous-transactionsoptionnelles exécutées.





Une sous-transaction obligatoire est dite complète si elle l’estdans le sens traditionnel (terminée avant son échéance).

Les sous-transactions optionnelles dépendent de lasous-transaction obligatoire et sont exécutées uniquement s’ilreste du temps.

Mi � Oi;1 � Oi;2 ... � Oi;#Oi

Toutes les sous-transactions possèdent l’échéance de latransaction principale :

Une sous-transaction est terminée si elle est complète ou amanqué son échéance.Une transaction (Ti ) est complète si sa sous-transactionobligatoire est terminée.Une transaction (Ti ) est terminée lorsque sa dernièresous-transaction optionnelle est terminée.





Une transaction de màj n’a pas de sous-transactions optionnelles.

Une transaction de màj est composée uniquement d’unesous-transaction obligatoire car elle n’effectue pas d’opérationcomplexe et possède un temps d’exécution plus faible que lestransactions utilisateur.

L’estimation du temps moyen d’exécution des transactions estconnue mais pas le temps courant, car on se situe dans unmodèle où l’utilisation du processeur est imprévisible et inconnuede l’ordonnanceur.




L’approche utilisée (1)

Objectifs et méthodes :Gérer les performances du SGBDTR en termes de qualité destransactions et des données.Définir la qualité de service et la manière de la spécifier.Les algorithmes FCS-IC-1 et FCS-IC-2.

Règles de mesure des performances et spécification de QdS :Pourcentage de sous-transactions obligatoires ratant leuréchéance.

MM = 100 �#DeadlineMissM

#TerminatedM (%)

Pourcentage de sous-transactions optionnelles ratant leuréchéance.

MO = 100 �#DeadlineMissO

#TerminatedO (%)

MDE : l’erreur maximum tolérée sur les données.Mp est le pire cas de performance d’exécution dans un étattemporaire.




L’approche utilisée (2)

Ts est le temps passé dans l’état précédent avant de revenir à unétat stable.U : la borne inférieure pour l’utilisation du système.

La qualité de donnée (QdD) est définie en termes de MDE : uneaugmentation de la qualité de données correspond à unediminution de MDE et vice versa.

On mesure la qualité des transactions en termes de pourcentagede sous-transactions qui ont raté leur échéance.




La spécification de la QdS

Elle se fait par des valeurs références par rapport à MM , MO ,MDE, etc.

Exemple :Mr

M = 1% (i.e. référence MM )Mr

O = 10% (i.e. référence MO)MDEr = 2% (i.e. référence MDE)U � 80%, Ts � 60s et Mp � 10%)MM �Mr

M � (Mp + 100) = 1.3%, MO � 13% et MDE � 2:6%




Qualité des transactions et imprécision des résultatsObjectifs :

augmenter la disponibilité des ressources,favoriser le respect des échéances au détriment de la qualité desrésultats,permettre au plus grand nombre de transactions de pouvoirs’exécuter.

Méthode employée :concevoir des transactions qui sont en mesure de fournir desrésultats intermédiaires exploitables,avoir recours à des algorithmes qui calcule des résultats imprécismais plus rapidement,augmenter la précision d’un résultat au fur et à mesure du temps.

Remarques :la qualité des résultats est une fonction qui prend en entrée leparamètre temps,plus une transaction dispose de temps, meilleure sera la qualitéde ses résultats.




Une architecture d’ordonnancement avec retourd’expérience

Moniteur

UUnouveau

....Source1

Sourcem

....Flux

Fluxm

1

Contrôleur d’utilisation et d’échéance ratées

Contrôleurde précision

Gestionnairede QdD

FM CC BSDéclencheur de transactions

Contrôleurd’admission

MDE

PourcentageMDETransactions Utilisateur

Transactions de MàJ

d’échéances ratées

Envoyées

Taux d’utilisation du CPU

Pourcentage d’échéances ratées

Fraîcheur

Abandon/Redémarre/Suspend

Bloquée

File des prêtes




Le gestionnaire de transactions (1)

Le déclencheur de transaction est constitué :d’un gestionnaire de fraîcheur (FM) qui vérifie la fraîcheur desdonnées avant d’y accéder en utilisant l’estampille et l’intervallede validité absolue : il bloque les transactions qui désirent accéderà des données non fraîches,d’un gestionnaire de contrôle de concurrence (CC) qui est2PL-HP,d’un ordonnanceur de base (BS) qui est souvent EDF.

Deux files pour les transactions :les transactions de mise à jour et les sous-transactions(utilisateurs) obligatoires sont mises dans la file de priorité plusforte,les sous-transactions (utilisateurs) optionnelles sont mises dans lafile de priorité plus faible,la prise en compte des transactions de ces deux files est décidéeau niveau du déclencheur de transactions.





Le contrôle d’admission des transactions (AC) :il contrôle le flux des transactions entrantes,il décide si une transaction peut-être admise ou non dans lesystème,il utilise des paramètres tels que l’importance des transactions(priorité), la charge du système (utilisation des ressources), etc.

Le gestionnaire de précision :il écarte les transactions de mise à jour lorsqu’elles tententd’écrire une donnée (di ) possédant une erreur DEi �MDE ,sinon la nouvelle valeur de di est mise à jour,dans tous les cas l’estampille de di est mise à jour,son objectif est de faire diminuer la charge du système en termesd’exécution des transactions de màj,il augmente ou diminue la valeur de MDE en fonction du ∆Urenvoyé par le contrôleur d’utilisation.





Le moniteur :il mesure le nombre de transactions qui s’exécutent, qui seterminent avant leur échéance ou qui ratent leur échéance,il prend ces mesures auprès du déclencheur de transactions,il transmet les mesures qu’il a effectuées au contrôleurd’utilisation.

Le contrôleur d’utilisation :il dispose des renseignements qui lui sont fournis par le moniteur,il effectue un calcul d’utilisation du système qui lui permet dedétecter des phases de surcharge (trop grand nombre detransactions qui ratent leur échéance, par exemple),il regarde aussi la charge CPU du système,il effectue un calcul final lui permettant de déterminer ∆U(Différence entre l’utilisation réelle et la valeur de référence) quipourra influer sur le gestionnaire de qualité des données.





Le gestionnaire de qualité des données :il va augmenter ou diminuer la qualité des données en fonction del’utilisation du système (en phase surcharge, il diminuera la qualitédes données),il influe sur les transactions admises dans le système par lecontrôleur d’admission mais aussi sur l’exécution ou non destransactions de màj,il recalcule MDE afin de diminuer ou d’augmenter le nombre detransactions de màj qui s’exécutent,il calcule un nouveau ∆U à partir de celui fourni par le contrôleurd’utilisation et de ses propres changements internes,la nouvelle valeur de ∆U est transmise au contrôleur d’admission.




FCS et QdS : conclusion

Prendre en entrée les paramètres de qualité de service spécifiéspar le DBA.

Recalculer les paramètres de la qualité de service en fonction del’exécution et du fonctionnement du système et en fonction desparamètres de référence.

) Constitution d’une boucle de rétroaction dans les SGBD tempsréel pour contrôler le comportement des SGBDTR lors desphases de surcharge du système.

) Il n’est pas nécessaire d’avoir un modèle précis de la charge dusystème.

) On aboutit à une stabilisation dynamique du système en fonctionde la charge et des ressources disponibles.




Une gestion multi-versions des données temps réel

ConcurrenceContrôleurContrôleur

d’échéanceFraîcheur

des données

File d’attente des transactionsprêtes à être exécutées

Ordonnanceur

MDE

V1

V2

V3

V1

V2

V3

V1

V2

V3

.........

Gestionnaire de données temps réel

Donnée Donnée Donnée

.....

.....

.....

Déclencheurde transactions

Accès aux données temps réel

Abandon/ Redémarrage/

Terminaison

ExécutionEnvoi

File des transactionsbloquées

Suspension

Abandon




Les systèmes multimédia et letemps réel


IntroductionQuelques éléments généraux

Description du problème et analyse

Introduction et contexte (1/2)

Les avancées de l’informatique et des réseaux informatiquespermettent de rendre plus populaires les systèmes multimédia etles applications Internet.

Il est désormais possible pour un grand nombre d’utilisateurs deregarder des vidéos en mode streaming ou de lire en temps réeldes données multimédia sur Internet.

L’acroissement de la demande pour ces applications destreaming vidéo sur Internet va prochainement amener lesréseaux à subir des périodes de saturation.

Le format de vidéos MPEG est devenu l’un des plus populairespour les applications multimédia telles que les visiophones, lessystèmes de visio-conférence, les systèmes interactifs tels que lavidéo à la demande.




Introduction et contexte (2/2)

Certains systèmes de vidéos à la demande existant fonctionnentsur des réseaux avec une bande passante dédiée.

Il serait intéressant d’avoir des systèmes qui fonctionnent sur desréseaux non contrôlés tels que l’Internet.

C’est pourquoi un grand nombre de travaux de recherche ont étéeffectués sur des systèmes distribués pour le streaming vidéo surdes réseaux non contrôlés et ouverts.

Les lecteurs de vidéo MPEG sont des systèmes strictes noncritiques. Chaque séquence vidéo doit être affiché correctementet à temps.




Problématique

Comment faire en sorte que les périodes de surchargen’entraînent une défaillance des applications et des pertes deperformance trop importante ?

Comment mettre à profit les périodes pendant lesquels lesapplications informatiques et les réseau ne sont plus sollicités defaçon intense ?

Comment concevoir des systèmes multimédia qui tiennentcompte de la dynamicité des demandes ?

Le nombre de clients n’est pas connu à l’avance.




Solution

Diminuer la qualité de service offerte lors des période desurcharge ou de forte de demande de la part des utilisateurs.

Mettre à profit les périodes de sous-utilisation.

) L’approche à utiliser est donc une approche basée sur la gestionde la qualité de service.

) Objectif : garantir une certaine qualité de service à à l’ensembledes clients seulement si c’est possible.

Technique employée :utiliser un contrôleur d’admission pour ajuster le nombre de clientsadmis dans le système selon les capacités du réseau et desserveurs vidéo.utiliser les avantages fournis par le calcul imprécis et lesmécanismes d’ordonnancement par rétroaction.




La compression vidéo au format MPEGLes applications multimédiaLes résultats/solutions imprécisesL’ordonnancement avec rétroaction

Quelques éléments généraux

La compression vidéo au format MPEG.

Les applications multimédia.

Les résultats/solutions imprécises.

L’ordonnancement avec rétroaction.

L’architecture QMPEGv2.





La compression vidéo au format MPEG (1/3)

Une vidéo est une simple succession d’image fixe qui sont aussiappelé frame.

Chaque image peut être compressée au format JPEG.

Dans une séquence vidéo, succession d’image, il existe de laredondance notamment s’il y a peu de mouvement.

Le format MPEG tient compte de cette redondance inter-framespour construire ses séquences vidéos.

MPEG prends en entrée une séquence de frames et lacompresse en trois type de frames :

Frame I (Intra-Frame),Frame P (Predictive Frame),Frame B (Bidirectionnal Frame).






Frame I (Intra-Frame) :Indépendante des autres frames.Une image JPEG.Elles sont indispensable pour la décompression.

Frame P (Predictive Frame) :Dépendance vis-à-vis des autres frames.Spécifications des différences avec la frame I précédente.

Frame B (Bidirectionnal Frame) :Dépendance vis-à-vis des autres frames.Spécifications une interpolation entre une frame précédente etune frame suivante de type I et P.






CompressionMPEG

Frame 1 Frame 2 Frame 3 Frame 4 Frame 5 Frame 6 Frame 7Fluxd’entrée

Fluxcompressé Frame I Frame B Frame B Frame P Frame B Frame B Frame I

Prédiction en arrière

Prédiction bidirectionnelle





Les applications multimédia

Le terme multimédia désigne un ensemble d’applications,produits ou technologies.

Deux classes d’applications :celles de type conférence,celles de type streaming.

Les applications de type streaming délivrent des flux audio etvidéos depuis un serveur vers un client (comme par exempleRealPlayer).

Elles ne peuvent utiliser un support fiable tel que TCP car il nepeu garantir l’arrivée des données dans les temps.

Un autre composant clé des systèmes multimédia distribués estles systèmes de bases de données





Les résultats/solutions imprécises

Dans un système temps réel stricte non critique, les échéancesdoivent être respectées sinon les tâches deviennent inutiles pourle système.

Les techniques de calcul imprécis peuvent aider au respect descontraintes temporelles.

Elles fournissent des résultats à l’utilisateur de qualité dégradéemais acceptable dans les temps.

On peut donc appliquer ces techniques aux systèmes multimédiaafin de dégrader la qualité des séquences vidéos par le biais dela suppression de frames de type P ou B.





L’ordonnancement avec rétroaction

On cherche à contrôler les performances du système temps réelen ajustant la configuration de telle façon à ce que lesperformances du systèmes convergent vers une qualité deservice spécifiée.

Un système basé sur l’ordonnancement par rétroaction consisteen un système contrôleur et un système contrôlé.

L’objectif étant de contrôler le système de façon à ce qu’ilconverge vers ses paramètres de référence.

L’ajustement d’un niveau de qualité de service se fait par exempleen modifiant le nombre de frame dans un GoP.

Les performances du système peuvent aussi être contrôlé aumoyen d’un contrôleur d’admission qui limite le nombre de clientsacceptés en fonction de la charge du système.





L’architecture QMPEGv2 (1/2)Il s’agit d’un système vidéo distribué qui est basé sur unearchitecture multi-serveurs.QMPEGv2 est composé de trois parties :

Le serveur maître reçoit les demandes des clients, leur alloue unserveur vidéo et régule les flux de données vidéo de façon à cequ’une certaine QdS soit maintenue.Les serveurs vidéo transmettre aux client les données vidéos etagissent sous le contrôle du serveur maître.Les clients reçoivent les frames vidéos depuis le serveur vidéo etdoivent jouer à temps celles-ci. Pour cela, chaque client disposed’un buffer de réception et lorsqu’un changement se produit ennotifie le serveur.

Exemple de scénario d’utilisation :1 Le client initie la demande d’une vidéo et l’envoi au serveur.2 À la réception de la demande, le serveur maître sélectionne le

serveur vidéo le moins chargé pour répondre à la demande.3 Une connexion est établie entre le client et le serveur vidéo.





L’architecture QMPEGv2 (2/2)

Le serveur maître agit comme un ordonnanceur qui régule le fluxet la qualité de service des données en fonction des conditionsréseaux.Trois facteurs ont été considéré comme important pour laconception de ce système :

une bonne transmission du coté serveur,une gestion efficace du buffer coté client,un mécanisme de contrôle entre le client et le serveur afin de tenircompte des délais du réseau.

La transmission des frames se fait sous le contrôle de la qualitéde service. Ceci signifie que le module de contrôle de la qualitéde service est le seul à pouvoir décider de la suppression deframe.

La mesure de la qualité de la vidéo est basé sur le point de vuehumain. On parle de QoS-human.




Problématique

Il existe une forte demande pour des systèmes de streamingvidéo fournissant une bonne qualité de service.

Les systèmes commerciaux existant nécessitent un réseau avecune bande passante fiable et un buffer de grande taille.

Ils ne fournissent pas de garanties de qualité de qualité deservice.

Lorsqu’il n’existe pas suffisamment de bande passante disponiblela suppression de frames se fait de façon aléatoire et incontrôlée.

Très peu de systèmes permettent aujourd’hui de faire dustreaming vidéo sur Internet.




Le calcul imprécis appliqué aux flux MPEG

Afin de garantir le comportement des serveurs vidéos dans unenvironnement imprévisible, on utilise une approche basée sur laqualité de service.

Il est nécessaire d’avoir des serveurs qui sont flexibles, quipeuvent s’adapter aux conditions existantes du réseau et quipeuvent effectuer une dégradation de la qualité de service d’unemanière contrôlée.

Il est possible d’appliquer la notion d’imprécision sur des GoP.




Spécification de la qualité de serviceQoS level : c’est le nombre de frames transmis dans chaqueGoP.

ClientQoS : c’est la moyenne du niveau de QoS coté client.

ServerQoS : c’est la moyenne du niveau de QoS coté serveur.

minQoS : c’est la qualité de service minimum admise cotéserveur.

maxQoS : c’est la qualité de service maximum admise cotéserveur.

Une augmentation de ServerQoS et et suffisamment de bandepassante entre le serveur vidéo et le client conduisent à uneaugmentation de ClientQoS .Deux cas peuvent conduire à la diminution de ClientQoS :

Une augmentation de ServerQoS et une congestion du réseau.Une dégradation de ServerQoS afin d’éviter une congestion duréseau.




Conclusion

Il est possible dans l’avenir de concevoir des systèmes pour lestreaming vidéo basé en garantissant une certaine qualité deservice.Pour cela, il faut :

spécifier les paramètres de qualité de service,construire des algorithmes d’équilibrage de charge basééventuellement sur le retour d’expérience,utiliser des méthodes de calcul imprécis pour faire varier la qualitédes résultats obtenus.

Dans les systèmes vidéo, on peut faire varier la qualité de serviceà la fois du coté client mais aussi du coté serveur.

Ces techniques peuvent se baser sur l’utilisation de SGBDTR quioffriraient des outils pour la gestion de la qualité de service.

Certaines de ces techniques peuvent être utiliséesindépendamment des autres.




Problèmes/Inconvénients de ces méthodes

Il n’existe pas encore de tels outils commerciaux et seul quelquesprototypes universitaires existent (Exemple : Beehive).

Il faut donc éventuellement tout programmer soi-même ou alorsprogrammer des extensions des SGBD actuels pour prendre encompte ces concepts.

Dans l’avenir certains prototypes universitaires deviendront sansdoute des outils commerciaux (à la manière d’O2).

Certains SGBD commerciaux intégrerons les aspects temps réelet la gestion de qualité de service.




Dernier transparent

Mise en ligne des transparents sur la page :http ://www-lih.univ-lehavre.fr/�duvallet/enseignements-fr.php

Rappel de mon adresse (courriel) : [email protected]


Les Systèmes de Gestion de Bases de Données...

Documents

Transcript of Les Systèmes de Gestion de Bases de Données...