Quelques questions techniques concernant le SATA, PCI et AHCI

Salut les Clémentines

Je viens tout juste de m’inscrire sur le forum et je tiens tout d’abord à remercier la communauté pour le travail monstrueux que vous ne cessez d’accomplir. Un grand merci pour votre altruisme ! Bravo également au staff pour avoir surmonté les nombreuses épreuves qui ce sont dressées sur votre chemin.
En toute sincérité, j’aimerais beaucoup me joindre à vous et faire profiter de mes connaissances mais mon statut d’étudiant en classe préparatoire et mon rôle de modérateur sur un autre forum ne me le permettent malheureusement pas.
J’ai d’ailleurs déjà rédigé quelques tutoriels sur le forum du Crabeinfo.net. Si vous pensez qu’ils peuvent intéresser je peux éventuellement les poster ici (en les modifiant suffisamment pour être en accord avec la ligne éditoriale de Zds)

Bref, je suis actuellement en train de rédiger un tutoriel qui vise à expliquer les notions de bus, d’interface, de port et de protocole. Une seconde partie est consacrée aux interfaces et protocoles en lien avec les disques durs. Pour être le plus précis et juste possible je me suis beaucoup renseigné, tant sur les sites anglais (la langue de Shakespeare ne me fait pas peur !) que français. Le soucis c’est qu’à vouloir trop creuser l’affaire, je me suis retrouvé à me poser des questions sans pouvoir trouver de réponse(s)qui me convenai(en)t…

Bon, voici les questions car j’ai l’impression que je parle trop :

1) Le bus PCIe et le bus SATA utilisant tous les deux une liaison en série qu’est ce qui fait que concrètement le PCIe est plus rapide que le SATA ? Un port PCIe x4, par exemple, utilise 4 lignes de transmission en série. Comment le bus SATA gère t-il ses lignes de transmission ?

2) J’ai lu sur un forum anglais ceci mais j’ai du mal à comprendre le sens de la deuxième partie de la phrase :

A bus is a specific kind of interface and it uses an implementation of some protocol to manage communication going through itself, so the CPU knows what to say at what time to access memory and the memory knows how to reply with data when it is requested

3) C’est la question qui me préoccupe le plus :/
L’AHCI c’est quoi ? D’après son nom on pourrait penser qu’il s’agit d’une interface physique mais en même temps j’ai lu à droite à gauche qu’il s’agissait d’un protocole. Pour moi c’est un protocole car je n’ai jamais vu de port AHCI ou quoi que ce soit. Si un disque dur est connecté sur un port SATA, j’ai le choix (depuis le BIOS) entre 3 modes d’opération : AHCI, IDE (il ne s’agit que d’une émulation à vrai dire) et RAID. Déjà c’est quoi qu’il entendent par mode d’opération ?

Sur le wiki français ils parlent de mécanisme matériel. What !?

D’autre part j’ai toujours pensé que l’AHCI pour le SATA était ce qu’est le NVME pour le PCIe (des protocoles donc), aurais-je tort ?

Tout élément de réponse (même s’il ne s’agit que d’un zeste) est le bienvenue

Salut @Stranger et merci pour ta réponse.

D’accord. Donc en fait le bus SATA est limité "techniquement" en fréquence. La flexibilité et la longueur plus importante de la connectique rend impossible l’utilisation des signaux à très haute fréquence.

Ça c’est la première partie de la phrase et je l’avais comprise
Ce qui me pose problème c’est ça :

[…] so the CPU knows what to say at what time to access memory and the memory knows how to reply with data when it is requested

Bon déjà je suis rassuré. L’AHCI est bien un protocole. Du coup sur le wiki c’est foireux…

En revanche, je ne comprends pas très bien ce que tu veux dire dans ta deuxième phrase.
Pour moi, on connecte un disque dur sur un port SATA et le protocole AHCI permet d’améliorer les fonctionnalités du SATA. Concernant l’IDE/PATA, il s’agit d’un autre type d’interface qui peut être émulé en utilisant un port SATA.
Pourquoi dis-tu qu’on n’utilise pas directement du SATA ? Vu qu’on branche un disque dur sur un port SATA, on l’utilise bien non ?

La deuxième partie du point 2 est juste une description de ce qu’est un protocole. C’est de la diatribe de Wikipédien qui ne veut rien dire à part "quand on utilise un protocole on sait à quelle adresse écrire les choses, lol".

Pour l’AHCI, c’est simple, le processeur voit une interface AHCI, et non une interface SATA. Le SATA est une interface hardware derrière. C’est un peu comme utiliser un socket TCP par dessus Ethernet, en réseau - tu vois TCP, en utilisant Ethernet. On dit "le processeur" comme si c’était une entité atomique mais tu as une carte mère avec des circuits d’interface, un chipset, et un processeur, et tout ça communique par différents bus, il n’y a pas une prise SATA sur le processeur…

Ouais diatribe c’est pas le mot adapté mais je vois ce que tu veux dire

Ce que j’ai du mal à comprendre c’est que si l’AHCI est un protocole, ça ne peut pas être une interface. Par définition, un protocole ne peut pas être une interface non ? D’ailleurs, un protocole ne peut pas être un truc physique. Si c’est bien le cas, alors il faut modifier la définition sur le wiki français parce que c’est pas clair leur truc…

Oui, de la même façon TCP est un protocole donc immatériel.

Arf ! Moi qui pensais avoir compris ce qu’était un protocole… Alors comme ça un protocole peut aussi être implanté physiquement ? Je croyais que du moment que c’était par définition un ensemble de règles convenues pour faciliter la communication (transfert de données), ça ne pouvait pas être matériel.
C’est assez abstrait comme notion quand même… Il n’empêche que fondamentalement un port (donc une interface) n’est pas la même chose qu’un protocole non ? Pas évident d’avoir les idées claires

En gros, AHCI au niveau matériel c’est un pont entre le processeur (via PCI) et un disque (via SATA). Au niveau logiciel c’est une interface avec des registres, des commandes, etc. C’est donc un composant physique présent dans la carte mère ou le package du processeur, interfacé avec le processeur lui-même via PCI, pour lequel on écrit un driver, et qui communique à son tour avec le périphérique via le bus SATA.

Merci. Ton explication est très claire

Franchement, c’est une spécificité d’architecture assez technique qui intéresse Intel, AMD et les développeurs d’OS. Là où tu auras le plus de réponses c’est encore en lisant la spec, parce que je n’en sais guère plus. Wikipédia est souvent une mauvaise source pour les sujets "propriétaires" comme ça - AHCI c’est une norme Intel que le reste du monde suit.

Grace à toi j’ai bien compris ce qu’était le AHCI. Il faut maintenant que j’arrive à me faire à l’idée qu’un protocole peut être matériel… (ça ne colle pas avec la définition… ^^)

Salut,

Les mots interface, protocole, spécifications ne sont pas mutuellement exclusifs.

Une interface, de manière très générale, est ce qui sépare deux entités différentes. Par exemple, un connecteur PCIe est une interface physique entre la carte mère et le périphérique. En programmation orientée objet, une interface désigne ce qui connecte l’objet au reste du programme.

Un protocole est simplement une manière de faire les choses. Un protocole expérimental désigne la suite des opérations à effectuer pour obtenir un résultat donné. Le protocole diplomatique dicte comment se comporter pour les relations internationales. Un protocole de communication désigne comment deux entités doivent échanger des informations entre elles.

Une spécification est une description précise de quelque chose. Tu peux spécifier ce que tu veux : un procédé de fabrication, un système de communication, un protocole, les caractéristiques d’un matériau de construction, etc.

En fin de compte, tu peux écrire une spécification qui décrit un protocole de communication permettant à deux systèmes (un CPU et un disque dur par exemple) de s’interfacer.

Salut @Aabu,

Oui je suis d’accord mais, par définition, une manière de faire les choses n’est pas un objet. La réponse à la question qui est ce qui dicte comment deux entités doivent échanger des informations entre elles ? n’est pas pas un objet non plus. En fait la seule chose qui me turlupine encore c’est comment on considérer un protocole comme étant un élément matériel. Parce qu’au final, un protocole c’est un peu comme une recette de cuisine non ?

En fin de compte, tu peux écrire une spécification qui décrit un protocole de communication permettant à deux systèmes (un CPU et un disque dur par exemple) de s’interfacer.

Oui, je te suis mais de quelle façon un protocole permet-il à 2 systèmes de s’interfacer ? Un port (pas dans le sens "port TCP/IP") est un élément matériel qui permet de brancher des périphériques. C’est donc une interface.
Un bus désigne l’ensemble des liaisons physiques (câbles, conducteurs électriques gravés sur les circuits imprimés…) permettant aux différents composants d’un ordinateur de communiquer entre eux. Il s’agit donc bien d’une interface.
Mais un protocole ? Je ne vois vraiment pas en quoi cela pourrait être matériel.

D’ailleurs le protocole NVME est clairement immatériel non ?

@Stranger et @Aabu,
J’espère que je ne vous gonfle pas trop avec ce genre de questionnement. Merci pour votre aide en tout cas

Disons que si un protocole est fondamentalement quelque chose d’abstrait, son implémentation peut être logicielle, ou matérielle.

Absolument, et si c’est une drôle d’idée pour un OS complet, l’exemple d’I²C est bien connu des amateurs de microcontrôleurs. Une stack plus ambitieuse comme USB est moitié logicielle, moitié matérielle.

D’accord. C’est beaucoup plus clair maintenant. Merci
Il me reste juste 3 (petites) questions :

1) Le protocole AHCI a été à la fois implanté matériellement et logiciellement ou simplement matériellement ?

2) Le protocole NVME est simplement logiciel de ce que j’ai compris. Vous confirmez ?

3) @Stranger et @Aabu
Dans un précédent message (Stranger) tu disais qu’une interface et un protocole était la même chose. D’après @Aabu il y a quand même une différence. C’est le protocole qui permet d’interfacer, ce n’est pas une interface lui-même.
Qu’en est-il du coup ?

Je débarque un peu après le début de la bataille, mais hier j’étais trop occupé à boire des bières (c’est Stranger qui m’a parlé du topic).

Ce qu’il en ressort de ces premiers échanges, c’est qu’on joue beaucoup sur le vocabulaire : protocole, interface, bus, etc. Sauf que ce n’est jamais explicitement défini et de toute façon dans la vie de tous les jours personne n’utilise parfaitement les termes.

L’autre point que j’ai remarqué c’est qu’à aucun moment non plus il y a une différence faite entre les différentes strates des bus cités : PCIe, SATA. En effet aujourd’hui les ces bus/protocoles/interfaces ne sont pas uniquement définis au niveau physique stricto census (niveau de tension par exemple) mais aussi au niveau protocolaire : de plus en plus de bus intègre une couche de données permettant la réalisation des transactions, de manière invisible pour les couches logicielles hautes.

(Bon finalement Aabu réagi sur ce point)

1) Le bus PCIe et le bus SATA utilisant tous les deux une liaison en série qu’est ce qui fait que concrètement le PCIe est plus rapide que le SATA ? Un port PCIe x4, par exemple, utilise 4 lignes de transmission en série. Comment le bus SATA gère t-il ses lignes de transmission ?

2) J’ai lu sur un forum anglais ceci mais j’ai du mal à comprendre le sens de la deuxième partie de la phrase :

A bus is a specific kind of interface and it uses an implementation of some protocol to manage communication going through itself, so the CPU knows what to say at what time to access memory and the memory knows how to reply with data when it is requested

3) C’est la question qui me préoccupe le plus :/ L’AHCI c’est quoi ? D’après son nom on pourrait penser qu’il s’agit d’une interface physique mais en même temps j’ai lu à droite à gauche qu’il s’agissait d’un protocole. Pour moi c’est un protocole car je n’ai jamais vu de port AHCI ou quoi que ce soit. Si un disque dur est connecté sur un port SATA, j’ai le choix (depuis le BIOS) entre 3 modes d’opération : AHCI, IDE (il ne s’agit que d’une émulation à vrai dire) et RAID. Déjà c’est quoi qu’il entendent par mode d’opération ?

Sur le wiki français ils parlent de mécanisme matériel. What !?

1) Le bus PCI express en 1x n’a pas tout le temps été plus rapide que le SATA. En 2004 sort le SATA 3Gbps (300MB/s). Le PCI express 1.0 culmine à 250MB/s jusqu’à la sortie du PCIe v2.0 en 2007 qui monte à 500MB/s.
Le SATA 6Gbps (600MB/s) sort en 2009 et le PCIe v3.0 (984MB/s) en 2010.

Néanmoins les deux bus utilise le même principe 2 paires différentielles en full duplex (une TX et une RX). Si au début les deux protocoles utilisent un codage 8b/10b impliquant un overhead de 20%, à partir du PCIe v3.0 ce dernier passe au codage 128b/130b ce qui réduit l’overhead et donc augmente la bande passante utile (d’où le 984MB et non un chiffre rond). Le SATA reste sur le 8b/10b pour le moment.

Enfin il y a une question de besoin aussi. Ce qui entraîne les évolutions du PCIe c’est le besoin de bande passante supplémentaire de la part des carte graphiques et cartes de calcul. Le SATA sert uniquement aux disques durs et jusqu’à l’avènement des SSD les 6Gbps étaient rarement occupés à 100%. Aujourd’hui les SSD sont capables d’utiliser pleinement la bande passante et même plus et on voit le développement de SSD sur PCIexpress, permettant un débit plus important.

2) Un bus n’est pas qu’une ligne électrique. Aujourd’hui l’USB, le PCIe, le SATA, etc. implémentent du logiciel (très) bas niveau pour gérer les transactions, sans action externe.

3) Tout est expliqué dans la norme qu’à donné Stranger.

1)Ca ne veut rien dire implémenté matériellement et logiciellement. Même si on parle de FPGA et donc de la possibilité de tout faire en dur, en théorie tu n’a pas à connaître l’implémentation.
Par exemple j’ai travaillé sur l’AFDX qui est un dérivé de l’Ethernet. Une société proposait des puces gérant un certain nombre de liens en RX et en TX. Mais un des clients cherchait à faire surtout du RX et donc ils ont implémenté la gestion du protocole sur un processeur en soft.

De plus aujourd’hui via des registres et même des micro-codes on peut très bien modifier le fonctionnement d’une puce. Par exemple les contrôleurs DDR peuvent être implémentés en dur (il fait partie de la puce) comme en soft (on le fait avec les portes) sur un FPGA et on est capable de le configurer pour fixer la fréquence de la RAM par exemple.

Une norme spécifie un protocole, des contraintes à respecter, mais dans la mesure du possible n’indique jamais l’implémentation, cette dernière doit être libre.

2) Le NVME est semblable au AHCI, donc l’implémentation est la discrétion de celui qui l’utilise.

Je ne m’attendais pas à ce que mon topic soit mentionné dans une quelconque autre discussion (IRL ou non). D’autant que j’ai essayé d’imaginer la conversation. Ça m’a bien fait sourire…

Ce qu’il en ressort de ces premiers échanges, c’est qu’on joue beaucoup sur le vocabulaire : protocole, interface, bus, etc. Sauf que ce n’est jamais explicitement défini et de toute façon dans la vie de tous les jours personne n’utilise parfaitement les termes.

Mouais et c’est bien le genre de truc que je n’aime pas… employer des mots qui ont une définition obscure. Mais je comprends que ça ne soit pas évident.

1) Ca ne veut rien dire implémenté matériellement et logiciellement. Même si on parle de FPGA et donc de la possibilité de tout faire en dur, en théorie tu n’a pas à connaître l’implémentation. Par exemple j’ai travaillé sur l’AFDX qui est un dérivé de l’Ethernet. Une société proposait des puces gérant un certain nombre de liens en RX et en TX. Mais un des clients cherchait à faire surtout du RX et donc ils ont implémenté la gestion du protocole sur un processeur en soft. […]
Une norme spécifie un protocole, des contraintes à respecter, mais dans la mesure du possible n’indique jamais l’implémentation, cette dernière doit être libre.

Attends je ne comprends pas. Tu dis que implémenter matériellement ou logiciellement ne veut rien dire mais plus loin tu parles d’implémentation en soft. Le protocole AHCI (pas forcément dans son entier) ne peut pas être considéré comme implanté physiquement sur le port SATA ? (ptêt que je raconte une bêtise là…)

2) Le NVME est semblable au AHCI, donc l’implémentation est la discrétion de celui qui l’utilise.

Mais tout le monde utilise le NVME et le AHCI de la même façon non ?

Merci pour tes précisions en tout cas.

Oui l’exemple d’un contrôleur DDR en soft ou en hard justement, pour moi, montre que l’implémentation on s’en fout : il fonctionne de la même façon car il respecte les spécifications des normes des mémoires.
De même pour l’AFDX : le protocole a été implémenté en hard sur une puce mais l’a aussi été en soft sur un processeur, dans les deux cas ça fonctionne parfaitement ! Donc l’implémentation hard ou soft d’un protocole (sachant que pour moi le protocole concerne l’algorithme pour la gestion de l’interface)

Et c’est ce que je dit à la fin : une norme (qui en général spécifie un protocole, une interface et/ou un bus) n’a pas vocation à donner l’implémentation d’une spécification. L’implémentation doit être libre.

J’en discutais encore aujourd’hui sur l’Ethernet à propos du fonctionnement sans transformateur. La norme Ethernet ne dit pas qu’il faut utiliser un transformateur pour assurer une isolation galvanique. Non elle indique des niveaux de tensions (1500V pendant 60s par exemple) à supporter. Un des moyens simple et efficace est l’utilisation d’un transformateur, mais on peut très bien utiliser des condensateurs en série.

De même on entend souvent dire que la longueur d’un cable Ethernet c’est 100m maximum. Et bien non, la norme ne spécifie pas de longueur maximale mais un délai de propagation maximum, qui dans le cas d’un cable RJ45 classique (ce qui ne veut rien dire au passage) correspond grosso modo à 100m. Mais si on utilise un cable plus performant (qui atténue moins le signal électrique) on peut très bien faire une longueur de 120 ou 130m et respecter la norme Ethernet.

Pour revenir sur ma phrase en gras, voici un schéma de la norme Ethernet sur le 10G :

La partie physique est spécifique à une interface. Ici dans le cas de l’Ethernet 10G, 4 interfaces sont possibles : 10GBase-W, 10GBase-R, 10GBase-KR et 10GBase-T.
Le "protocole" c’est la couche OSI 2 (Data Link) : Mac + LLC.

Pour t’embrouiller un peu plus l’esprit, y compris à l’intérieur de la partie "PHY" il y a une partie protocole.

Ici on peut voir les trois partie d’un PHY : le PCS, le PMA et le PMD et leur relation. On peut voir des noms de signaux physiques électriques (XGMII et MDI en haut et en bas) ainsi que des noms internes qui lient les différentes parties.

Et voici le diagramme d’état du PCS :

Et ça, ça s’implémente en hard comme en soft, c’est un algorithme. Et c’est pour moi le protocole du PCS : les règles à respecter pour communiquer avec lui (enfin faut lire la norme pour les avoir toutes, le diagramme n’étant qu’un résumé).

Ce que je veux dire c’est que le NVME est une norme semblable au AHCI : ça définit une manière d’accès aux données d’un disque dur.

D’accord. Merci pour les approfondissements.