Guide d’utilisation de QRUNAP2

Read in English

Sélectionnez un exemple, cliquez sur Exécuter cet exemple, puis modifiez le modèle pour comparer les résultats. La simulation s’exécute localement dans votre navigateur. Le bouton FR donne accès à l’interface française.

1. À quoi cela sert-il ?

Imaginez un guichet recevant des demandes. Elles arrivent, attendent si le guichet est occupé, sont traitées puis repartent. Vous cherchez à connaître leur attente, l'occupation du guichet et l'intérêt d'ajouter un deuxième agent. Le même raisonnement s'applique aux processeurs, disques, ateliers ou flux de transport.

Un client est l'objet traité : requête, tâche, personne ou message. Une station associe un service à sa file d'attente. Un serveur est une unité de capacité de traitement dans cette station. Deux serveurs peuvent partager une file. Un réseau relie les stations par des règles de circulation des clients.

QNAP2 associait ces objets à un langage algorithmique et à des commandes d'exécution. Il permettait aussi des attributs de clients, des synchronisations et des comportements programmés. Les sources historiques, notamment S3 et S8, montrent cette richesse.

2. Relire un petit modèle

Voici un exemple pédagogique original dans le sous-ensemble pris en charge, pas la transcription d'un manuel.

/DECLARE/
QUEUE INPUT, DESK;
/STATION/
NAME=INPUT;
TYPE=SOURCE;
SERVICE=EXP(2);
TRANSIT=DESK;
/STATION/
NAME=DESK;
TYPE=SERVER,SINGLE;
SERVICE=EXP(1);
TRANSIT=OUT;
/CONTROL/
TMAX=10000;
/EXEC/
BEGIN
SIMUL;
END;
/END/

EXP(2) indique une durée moyenne de 2, pas deux arrivées par unité de temps. Le taux correspondant est 1/2. Cette convention est explicitée dans la thèse de Place, page imprimée III-84 (S9) ; sa vérification dans le manuel complet 9.3 reste à faire. CST(2) désigne une durée constante de 2. Choisissez une même unité partout : secondes, minutes ou autre.

Pour une SOURCE, SERVICE décrit l'espacement des arrivées. Pour un SERVER, il décrit le temps de traitement. C'est un repère essentiel pour relire un ancien modèle.

3. Que fait le bouton Exécuter ?

Rust analyse et vérifie le texte, construit le réseau puis avance une horloge virtuelle d'événement en événement. Il n'attend pas 10 000 secondes réelles. Une arrivée ou une fin de service est un événement. Le moteur mesure l'occupation, les files et les visites terminées.

La graine détermine les tirages aléatoires. Une même graine permet de reproduire l'expérience ; une autre donne une nouvelle réalisation. Le générateur est nouveau : il ne reproduit pas les anciens tirages de QNAP2.

4. Lire les résultats

Dans le premier exemple, les valeurs théoriques à long terme sont une occupation de 50 %, L=1 et W=2. Une simulation fluctue autour de ces valeurs. Une station peut avoir une capacité moyenne disponible et néanmoins faire attendre, car arrivées et services sont irréguliers.

Le démarrage est inclus dans les moyennes. Les visites inachevées à l'arrêt ne contribuent pas à W ni Wq. Aucun intervalle de confiance n'est encore calculé. Voir les définitions techniques en anglais.

5. Cinq expériences pour retrouver l'intuition

Le dernier exemple reconstruit la topologie d'une véritable exécution publiée par l'INRIA. La saisie interactive et les réplications parallèles sont remplacées. Les modifications sont documentées : ce n'est pas le programme original inchangé.

6. Le langage historique comporte trois niveaux

Pour ouvrir un ancien fichier QNAP2, distinguez ces niveaux :

Dans le programme historique de l'INRIA, = introduit les propriétés des stations ou du contrôle, tandis que := affecte une valeur dans les instructions exécutables. INTEGER et REAL déclarent des variables numériques ; BEGIN et END délimitent un bloc. GET lit une valeur et PRINT affiche des informations. Ce sont des repères de lecture, mais les variables, affectations et instructions interactives ne sont pas encore prises en charge dans cet atelier. Voir S8.

Un SERVICE historique pouvait contenir un algorithme au lieu d'une durée. Une référence de client désigne un client particulier ; les drapeaux permettent de synchroniser des activités. Le programme de circulation urbaine illustre ce style plus riche (S3). Remplacer ces mécanismes par des durées fixes changerait le modèle.

Une simulation produit des observations à partir d'une succession d'événements. Une méthode analytique calcule des résultats par des équations sous certaines hypothèses. QNAP2 proposait les deux ; cette version de QRUNAP2 implémente uniquement la simulation. Une formule dans le guide est une référence pédagogique, pas un solveur historique implémenté.

7. Comment QNAP2 est-il adapté ?

Les noms historiques restent visibles : QUEUE, STATION, SERVICE, TRANSIT et SIMUL. Le code est réécrit en Rust. Le même moteur fonctionne en ligne de commande ou en WebAssembly dans une tâche de fond du navigateur. GitHub Pages héberge des fichiers statiques ; les visiteurs n'ont besoin ni de serveur de simulation ni de compte.

L'éditeur web, la graine, l'export JSON, les deux langues, les limites de ressources et les diagnostics sont des outils modernes. L'ordre FIFO, le démarrage des sources et l'ordre des événements simultanés sont des règles explicites de QRUNAP2 dont les détails historiques restent à vérifier.

Cette version traite de petits réseaux ouverts et fermés, avec durées constantes ou exponentielles et serveurs simples ou multiples. Variables, boucles, IF, références, drapeaux, classes de clients, routage probabiliste et solveurs analytiques historiques ne sont pas implémentés. Une construction non prise en charge produit une erreur. La matrice de compatibilité en anglais précise les limites.

8. Reprendre concrètement

Commencez par la première file, modifiez uniquement l'espacement des arrivées et observez l'occupation et l'attente. Ajoutez ensuite un deuxième serveur. Explorez enfin le réseau fermé et ralentissez B en augmentant sa durée moyenne de service. Expliquez le résultat avec vos propres mots avant de changer un autre paramètre : les idées centrales reviennent ainsi avant les algorithmes et synchronisations historiques.