MPC Project

ASIM team
LIP6 Laboratory
Paris, France
Préliminaires.

On fournit actuellement un package contenant 3 archives :
  - MPC-OS  : protocoles de communication implémentés en modules noyau
  - MPC-PVM : PVM optimisé pour MPC-OS
  - MPC-JMS : Job Management System pour la gestion des utilisateurs et
              tâches (files de batch) sur une machine MPC.
. Fonctionnement depuis FreeBSD 2.2.5 jusqu'à FreeBSD 3.4.
. Chargement des modules en LKM ou KLD.
. Fonctionnement en Monopro et Multipro.
. Fonctionnement avec Bridge LX et BX.



Tableau comparatif pour configuration du soft pour les contournements :

Les `#define' liés au contournement, utilisés dans put.c et parfois
positionnés dans put.c, sont les suivants:

PCIDDC1stRun, PCIDDC2ndRun, PUT_OPTIMIZE, PUT_DONT_FLUSH_LPE, LPE_SLOW.

Il y a 4 actions à faire ou ne pas faire au moment de la compilation :
a- `--enable-soft-workaround' : option de configure pour indiquer no de Run
                                de PCIDDC.
                                Ca définit PCIDDC1stRun ou PCIDDC2ndRun.
b- positionner PUT_OPTIMIZE :
   optimisation du code en enlevant des vérification de cohérence.
c- positionner PUT_DONT_FLUSH_LPE :
   optimisation du code de put_add_entry() dangereuse
   si on fait du polling sur les données plutôt que
   de la réaction aux interruptions.
d- positionner LPE_SLOW :
   1 page à la fois dans la LPE.

Les 5 variables qui conditionnent l'application de ces actions
sont les suivantes :

1- Utilisation de PCIDDC 1stRun ou 2ndRun.
2- Carte FastHSL Run B ou carte FastHSL Run C.
3- Chipset LX ou BX.
4- Monopro ou multipro
5- Campagne de bench ou debug d'application.

Toutes les combinaisons ne sont pas possibles.

Il y a 7 combinaisons possibles :

(NC signifie : on fait ce qu'on veut et on n'a pas à décider au moment
de la compilation de MPC-OS)
POLL signifie que l'utilisateur de PUT ou SLR fait du polling, ca ne
veut pas dire que PUT n'utilise pas d'IRQ (il en utilise éventuellement
pour corriger des bugs, par ex avec un BX)
-------------------------------------------------------------------------
| Config | PCIDDC |  Pb Cable | Bridge | Processor | Bench?  | Polling? |
-------------------------------------------------------------------------
|   1    | 1stRun | FastHSL-B | LX     | MONOPRO   | NC      | NC(=>IRQ)|
|   2    | 2ndRun | FastHSL-B | LX     | MONOPRO   | OUI/NON | IRQ/POLL |
|   3    | 2ndRun | FastHSL-B | BX     | MONOPRO   | OUI/NON | IRQ/POLL |
|   4    | 2ndRun | FastHSL-B | BX     | BIPRO     | OUI/NON | IRQ/POLL |
|   5    | 2ndRun | FastHSL-C | LX     | MONOPRO   | OUI/NON | IRQ      |
|   6    | 2ndRun | FastHSL-C | BX     | MONOPRO   | OUI/NON | IRQ      |
|   7    | 2ndRun | FastHSL-C | BX     | BIPRO     | OUI/NON | IRQ      |
-------------------------------------------------------------------------

Règles :
* Si on met LPE_SLOW on doit alors mettre PUT_DONT_FLUSH_LPE.
* Dans le cas où l'on ne met pas LPE_SLOW, on doit mettre PUT_DONT_FLUSH_LPE
  si on utilise parfois des IRQs(PUT) ou fct de callback (SLR) pour la
  signalisation plutot que de ne faire que du polling.
* 1stRun implique d'utiliser --enable-soft-workaround. Ca positionne alors
  automatiquement PUT_OPTIMIZE et PUT_DONT_FLUSH_LPE. On est de plus alors
  automatiquement en mode page par page, et il ne faut pas préciser
  LPE_SLOW (LPE_SLOW ne sert qu'avec un PCIDDC 2ndRun).
* 2ndRun implique d'utiliser --disable-soft-workaround.
* Si on veut des modules avec support multipro, il faut faire le configure
  sur une machine dont le kernel (/kernel) est déjà compilé pour multipro,
  sinon il faut faire le configure sur une machine avec kernel monopro.
* Avec FastHSL-C, il faut s'attendre à un MTBF entre 2 min et 40 minutes
  (à moins d'utiliser le flag expérimental AVOID_LINK_ERROR).
* Avec LX, on ne met pas LPE_SLOW et PUT_DONT_FLUSH_LPE dépend
  de la méthode de signalisation (voir la 2ième règle).
* Avec BX, il faut mettre LPE_SLOW ET PUT_DONT_FLUSH_LPE.
* PUT_OPTIMIZE sert à gagner environ 1 microsec de travail
  processeur au niveau PUT. Il faut le mettre uniquement si
  on veut faire des benchs. Si on développe, on ne le met
  pas afin d'activer tous les tests de cohérence.

A partir de ces règles, on déduit :

Config 1 :
Utiliser --enable-soft-workaround.
Faire le configure sur machine avec noyau monopro.
PUT_OPTIMIZE et PUT_DONT_FLUSH_LPE sont automatiquement pris en compte.
Le mode page par page est activé, mais LPE_SLOW n'est pas défini (et ne
doit pas l'être).
Ne pas positionner AVOID_LINK_ERROR.

Config 2 :
Utiliser --disable-soft-workaround.
Faire le configure sur machine avec noyau monopro.
Mettre PUT_OPTIMIZE suivant qu'on fait des benchs ou du developpement/debug.
Mettre PUT_DONT_FLUSH_LPE si on utilise parfois des IRQs ou fct de callback
  pour la signalisation plutot que de ne faire que du polling.
Ne pas positionner LPE_SLOW ni AVOID_LINK_ERROR.

Config 3 :
Utiliser --disable-soft-workaround.
Faire le configure sur machine avec noyau monopro.
Mettre PUT_OPTIMIZE suivant qu'on fait des benchs ou du developpement/debug.
Mettre PUT_DONT_FLUSH_LPE.
Mettre LPE_SLOW.
Ne pas positionner AVOID_LINK_ERROR.

Config 4 :
Utiliser --disable-soft-workaround.
Faire le configure sur machine avec noyau bipro.
Mettre PUT_OPTIMIZE suivant qu'on fait des benchs ou du developpement/debug.
Mettre PUT_DONT_FLUSH_LPE.
Mettre LPE_SLOW.
Ne pas positionner AVOID_LINK_ERROR.

Config 5 :
Utiliser --disable-soft-workaround.
Faire le configure sur machine avec noyau monopro.
Mettre PUT_OPTIMIZE suivant qu'on fait des benchs ou du developpement/debug.
Mettre PUT_DONT_FLUSH_LPE si on utilise parfois des IRQs ou fct de callback
  pour la signalisation plutot que de ne faire que du polling.
Mettre AVOID_LINK_ERROR si on veut essayer d'augmenter le MTBF (uniquement
  si on n'utilise que deux noeuds) - ce flag est expérimental...
Ne pas positionner LPE_SLOW.

Config 6 :
Utiliser --disable-soft-workaround.
Faire le configure sur machine avec noyau monopro.
Mettre PUT_OPTIMIZE suivant qu'on fait des benchs ou du developpement/debug.
Mettre PUT_DONT_FLUSH_LPE.
Mettre AVOID_LINK_ERROR si on veut essayer d'augmenter le MTBF (uniquement
  si on n'utilise que deux noeuds) - ce flag est expérimental...
Mettre LPE_SLOW.

Config 7 :
Utiliser --disable-soft-workaround.
Faire le configure sur machine avec noyau bipro.
Mettre PUT_OPTIMIZE suivant qu'on fait des benchs ou du developpement/debug.
Mettre PUT_DONT_FLUSH_LPE.
Mettre AVOID_LINK_ERROR si on veut essayer d'augmenter le MTBF (uniquement
  si on n'utilise que deux noeuds) - ce flag est expérimental...
Mettre LPE_SLOW.



Conséquences en termes de performances.

Légende :
=     = sans influence
-     = peu efficace
+     = efficace
mieux = amélioration notoire
x%    = variation par rapport à la ligne précédente

+------------------------------------------------------------------------+
|                       |Petits messages (latence)| Gros messages (debit)|
|                       |-------------------------+----------------------|
|                       | SLR      | PUT          |    SLR      | PUT    |
|-----------------------+----------+--------------+-------------+--------|
|1 Ajout de PUT_OPTIMIZE|  =       | mieux        |     =       | =      |
|2 PCIDDC 1stRun        |  -       | -            |     -       | -      |
|3 2ndRun LX Monopro    |  +       | +            |     +       | +      |
|4 2ndRun BX Monopro    |  + (-10%)| -            |     + (-5%) | +      |
|5 2ndRun BX Bipro      |  - (-50%)| -            |     + (-15%)| +      |
|6 2ndRun i820 Monopro??|  +       | +            |     +       | +      |
|7 2ndRun i820 Bipro????|  - (-50%)| -            |     + (-15%)| +      |
+------------------------------------------------------------------------+

Explications :
1:     latence PUT plus efficace car 1 microsec de gagnée sur 4 microsec.
       Sans influence pour le reste, car les latences en jeu sont
       bien plus importantes.
2:     MPL=1 (114 Mo/s max), 1 page par 1 page (équivalent à LPE_SLOW).
2->3:  Peu de patchs soft.
3->4:  Ajout de LPE_SLOW. Pour PUT : délai entre émissions de pages,
       donc ça se voit que si la page prend peu de temps à partir.
4->5:  Surcoûts liés à l'OS.
       Pas d'influence sur SLR et PUT avec gros messages car les delais
       liés à l'OS sont ridicules par rapport à ce qui est lié
       au temps de transfert par PCIDDC.
6:     Peu de patchs soft.
6->7:  Pas d'influence sur SLR et PUT avec gros messages car les delais
       liés à l'OS sont ridicules par rapport à ce qui est lié
       au temps de transfert par PCIDDC.
Server design A. Fenyö
mpc@mpc.lip6.fr - contact people
About this Web Site
$Date: 1998/05/22 15:00:13 $