Un bench de port parallèle, selon les différents mode d'accès


Abstract
[Retour au sommaire]

Il s'agit tout simplement de résultats obtenus sur une carte communiquant par le port parallèle d'un PC. Ces résultats peuvent être intéressants pour avoir une idée du débit qu'il est possible d'obtenir, en fonction du mode d'accès utilisé.


Bench

  • Le mode Compatible (BGenio) correspond à l'utilisation d'un driver 'haut-niveau' type DlPortIO, c'est à dire effectuant un appel de driver(DeviceIoControl) lors de chaque E/S.
  • Le mode User Port consiste à effectuer les E/S directement depuis l'appli haut niveau(sans appel de driver donc). Sous NT/2K/XP, il est nécessaire d'autoriser ces accès via un soft externe type UserPort.
  • Le mode Driver(COMDSP) correspond à un driver fait spéciallement pour l'application. Les E/S sont effectuées directement en assembleur depuis le driver. Il n'y a donc qu'un seul appel au driver par envoi/réception de paquet
  • Le transfert d'un octet nécessite en mode standard 4 E/S.
    • 1 lecture pour vérifier qu'il y'a réellement un cycle en attente
    • 1 écriture pour sortir les 8 bits de données
    • 1 écriture pour mettre à 1 le signal de 'strobe'
    • 1 écriture pour mettre à 0 le signal de 'strobe'
  • Le mode EPP (fonctionnement de l'EPP)(utilise le port // en mode EPP), permet d'effectuer un cycle en 2 E/S
    • En EPP, les fonctions des différentes pattes sont changées. En renvoyant l'opposé de DataStrobe (pin 14) sur Wait (pin 11), le cycle se déroule au plus vite possible (on peut également 'bloquer' le signal Wait à 0 ou 1 si il n'y a pas de demande de cycle - ce qui se traduira par un timeout au niveau de l'EPP).
    • On doit donc effectuer 1 écriture (qui sort les données et active le strobe)
    • 1 lecture pour évérifier qu'il n'ya pas eu de timeout (indiquant qu'il n'y avait pas de cycle de deamndé)
  • Le mode Fast permet de retirer une E/S (Le mode Fast ne vérifie pas qu'un cycle est réellement demandé. Une seule vérification est alorsréalisée à la fin du transfert). En EPP le mode Fast vérifie pas qu'il n'y a pas eu de timeout uniquement à la fin du transfert.
  • Le mode 16 bits en EPP permet en théorie de diviser le nombre d'E/S par 2 [une E/S effectue 2 cycles de 16 bits]. En réalité, il y'a une surcharge équivalente au temps d'1/2 E/S
  • Le mode 32 bits permet en théorie de diviser le nombre d'E/S par 4 [une E/S effectue 4 cycles de 16 bits]. En réalité, il y a une surcharge équivalente au temps d'1/2 E/S

Le mode Compatible (BGENIO), standard est celui qui contient le plus de vérifications et permet donc de trouver l'origine d'un problème de transfert.

Les taux indiqués sont les taux réels sur des paquets de 16380 octets (aucune autre occupation de la machine). Machine : PIII 500MHz.

SPP
EPP
8 bits
8 bits
16 bits
32 bits
Standard
Fast
Standard
Fast
Standard
Fast
Standard
Fast
Mode Compatible (BGENIO)
22 Ko/s
30 Ko/s
44 Ko/s
87 Ko/s
86 Ko/s
162 Ko/s
164 Ko/s
287 Ko/s

Mode UserPort
(accès direct)

146 Ko/s
188 Ko/s
272 Ko/s
541 Ko/s
409 Ko/s
810 Ko/s
545 Ko/s
820 Ko/s
Mode Driver
(COMDSP)
148 Ko/s
193 ko/s
N.A.
511 Ko/s
N.A.
630 Ko/s
N.A.
682 Ko/s

En mode compatible, le temps d'appel du driver est le facteur le plus limitant. Limiter le nombre d'appels au driver est le plus rentable.

En mode User Port, il n'y a aucun appel de driver, les vitesses sont d'une part plus élevées et sont à ce moment limitées par le reste des composants du système (chip Super I/O contenant le port //, pont PCI/ISA, vitesse du proc du PC, code 'non utile' pour la transmission - appel de fonction C, tests, etc). A noter que les performence en mode User Port sont boostée lorsque qu'une machine virtuelle 16 bits (ntvdm standard démarré dès qu'on démarre une application 16 bits sous Windows NT/2K/XP) est en chargée en mémoire. (?!?!)
Explication : phénomène due à une boucle d'attente, utilisant sleep(1), affecté par la granularité de l'horloge système. Cette granularité est modifée par la machine virtuelle 16 bits.

En mode driver, les appels au driver, bien que largement moins fréquent (1 seul par paquet) sont toujours TRES couteux en temps d'appel.A noter qu'en interne le temps réellement mis par le driver pour effectuer l'envoi correspond à un taux de transfert de 1.1Mo/s. L'envoi d'un paquet de 16380 octets à 1.1Mo/s prend 14,8 ms environ. Le taux réel de 682 Ko/s correspond à un temps de 24,017 ms, soit 10 ms de perdues dans la nature par envoi. Ces 10ms sont en partie due à l'utilisation de l'équivalent d'un sleep(1) dans le driver

Attention les appels qui sont utilisés sont les plus basiques, il est possible d'effectuer des appels 'Fast', normallement plus rapides [infos sur les performances des appels aux drivers NT - allemand].

-= Email : manu_bat_manu@yahoo.fr =-