Avenir USB

Le 26-05-2008, à propos de
Re: Avenir USB,
Francois Petillon écrivait dans fr.comp.stockage :

On Mon, 26 May 2008 11:30:21 +0000, JKB wrote:

J'aimerais qu'on me les présente, justement. Et je n'ai jamais parlé
de cartes SCSI _intelligentes_, mais de cartes standard de part et
d'autre (sinon, j'aurais même mis du raid hard). D'ailleurs,
j'aimerais qu'on définisse ce qu'est une carte intelligente et une
qui ne le serait pas.

Une carte intelligente est une carte capable de décharger le CPU de
certaines taches. Typiquement, pendant très longtemps, l'interface ATA
était exclusivement gérée par le CPU (de fait, ATA signifiait
AT-attached : les nappes respectaient les timings/specs du bus ISA des PC
IBM AT) ce qui entrainait une consommation CPU considérable (de mémoire
mais je peux me planter, il devait y avoir une interruption déclenchée
tous les mots de 16 bits). Aujourd'hui, les cartes controlleurs sont
censées gerer les transferts de donnée directement sans passer par le
CPU, les fonctionnalités RAID peuvent être gerées avec plus ou moins de
bonheur par l'electronique, etc.

Mais on s'en fout. Une carte xATA effectue des accès DMA, mais par
petits bouts parce qu'elle est bridée par la vitesse de la connexion
avec le disque, donc il y a des problèmes d'accès mémoire
concurrents à gérer. Une carte SCSI ou SAS ne se comporte pas du
tout de la même façon parce que le flux de données est plus
régulier. Essayez de faire des benchs de montée en charge sur un
serveur (en accès aléatoire) avec un coup des disques xATA et un
autre des SCSI.

Pour mémoire :
SCSI : adaptateur côté carte-mère et contrôleur sur disque
xATA : contrôleur côté carte-mère et adaptateur côté disque
Je ne sais pas si vous saisissez bien la différence du point de vu
fonctionnel...

Vous pourriez définir les différences que vous attribuez entre
"adapteur" & "controleur" ? Personnellement, j'ai tendance à considerer
qu'un adapteur est "simple" (mais ce serait en conflit avec votre
description puisque de tout temps les controlleurs SCSI ont été
relativement évoluées alors que les périphériques ATA étaient
simplistes au possible et releguaient tout le boulot au CPU).

Je parle de fonctionnement _logique_. Du point de vue logique, une
carte SCSI est plus simple qu'une carte xATA parce que le gros du
boulot est fait dans le contrôleur qui est sur le disque alors que
le contrôleur ATA est sur la carte avec un adaptateur sur le disque.
Par ailleurs, les mots adaptateur et contrôleur sont ceux qui sont
utilisés en électronique.

De toute manière, tout ceci se passe derrière la carte controleur et
n'est pas censé être visible aujourd'hui au niveau du CPU.

Non. Le CPU ne travaille peut-être plus pour gérer des IO (mais il y
a belle lurette que le contrôleur xATA n'est plus géré directement
par le CPU), mais il y a toujours une consommation de temps système
plus importante que dans le cas du SCSI parce que justement, le
contrôleur est sur la carte-même ! Faites un schema, vous
comprendrez mieux ou se situe le goulot d'étranglement.

Bon. Je vais donc reprendre. Comment expliquer que pour une machine
avec une carte Adaptec 29160 et une autre SATA dont j'ai oublié le
nom (faudrait que j'ouvre la bête, mais c'est une adaptec aussi),
sur une carte mère Tyan bipro
Opteron, avec des disques SATA-II et U320 de Fujitsu par ailleurs
_identiques_ (même caractéristiques à un pouillème près sauf
l'interface), une requête sur une base de données sur les U320 prend
quelques secondes alors que sur la réplique en SATA-II, cela prend
plusieurs minutes en bouffant du temps système de façon éhontée ?

Personnellement, je gère un petit paquet de serveur en
SCSI/SAS/FC/ATA/SATA. Il n'y a pas grande différence de consommation CPU
entre les uns et les autres. Dès qu'on commence à sortir de la BP (genre
ftp.free.fr qui utilise du SATA), ce sont les interfaces ethernet qui
représentent le gros de la consommation CPU.

Je parle d'accès aux disques pour une utilisation locale, pas
d'accès réseau qui est un goulet d'étranglement. J'ai aussi un tas
de machines avec 32 procs et avec au choix U320/SAS/FC et SATA
(désolé, pas d'ATA dans ces configs) et je ne vais pas jouer à celui
qui a la plus grosse, j'ai passé l'âge. Les cartes réseaux ne sont
pas sollicitées, sauf pour le résultat de requêtes SQL, donc très
peu sollicitées. La différence se fait simplement au niveau des
accès disque.

JKB

PS: fin de la discussion

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Dans le message :slrng3lk7h.139.knatschke@rayleigh.systella.fr,
JKB a écrit:

Le 26-05-2008, à propos de
Re: Avenir USB,
Francois Petillon écrivait dans fr.comp.stockage :
......

Personnellement, je gère un petit paquet de serveur en
SCSI/SAS/FC/ATA/SATA. Il n'y a pas grande différence de consommation
CPU entre les uns et les autres. Dès qu'on commence à sortir de la
BP (genre ftp.free.fr qui utilise du SATA), ce sont les interfaces
ethernet qui représentent le gros de la consommation CPU.

Je parle d'accès aux disques pour une utilisation locale, pas
d'accès réseau qui est un goulet d'étranglement. J'ai aussi un tas
de machines avec 32 procs et avec au choix U320/SAS/FC et SATA
(désolé, pas d'ATA dans ces configs) et je ne vais pas jouer à celui
qui a la plus grosse, j'ai passé l'âge. Les cartes réseaux ne sont
pas sollicitées, sauf pour le résultat de requêtes SQL, donc très
peu sollicitées. La différence se fait simplement au niveau des
accès disque.

Arf, je pense que tu ne sais pas bien qui est François.
Je pense que son expérience sur les disques est tout à fait valable et pas
du tout inintéressante ;-))

Perso je constate juste sur une petite dizaine de serveurs qui me sont
passés entre les mains que tant que l'on reste sous windows j'en ai vu très
peu égaler les perfs d'un petit serveur sous linux tant en SMB qu'en FTP !
Et même avec des disques SCSI récent l'usage local n'est guère plus
performant qu'avec un bète PC en sata sur plein d'opérations.

Dans ton cas c'est p'têt bien SQL qu'est mal fichu ? ;-))

--
Eric
Reply-to valide, laissez tel quel !
Texte brut vivement conseillé !!

On Mon, 26 May 2008 15:02:26 +0000, JKB wrote:

Mais on s'en fout. Une carte xATA effectue des accès DMA, mais par
petits bouts parce qu'elle est bridée par la vitesse de la connexion
avec le disque, donc il y a des problèmes d'accès mémoire
concurrents à gérer.

Elle est bridée par la vitesse de connexion avec le disque ? Plait-il ?
Pour commencer, la carte controlleur peut bufferiser (typiquement, les
cartes controlleurs que nous utilisons gèrent entre 512 Ko et quelques
Go) et je ne vois pas l'interet de balancer en mémoire centrale des
données avant d'avoir le bloc complet (d'aucuns diront que cela permet de
réduire légèrement la latence mais c'est relativement négligeable). De
plus, OK, considerons que vous ayez raison. Ces problemes d'accès
mémoire concurrents ralentissent legerement les accès mémoires.
Maintenant, ce sont tous les accès mémoires qui sont ralentis, pas juste
lorsque le CPU est en mode systeme. De fait, votre explication ne cale pas
avec le probleme que vous aviez décrit.

Une carte SCSI ou SAS ne se comporte pas du
tout de la même façon parce que le flux de données est plus
régulier.

La régularité du flux de données est négligeable en regard des
capacités de l'electronique (au sens où le controlleur passe son temps
à attendre). De plus, les disques, qu'ils soient SCSI, SATA, PATA ou
autre, ne transferent les données qu'une fois qu'elles ont été lues
(donc bloc par bloc). Il n'y a donc pas de regularité/irrégularité dans
le transfert de données sur le bus SCSI/xATA/autre.

Essayez de faire des benchs de montée en charge sur un
serveur (en accès aléatoire) avec un coup des disques xATA et un
autre des SCSI.

Je bosse pour un FAI et je gère/j'ai géré quelques services
relativement lourds nottament sur les accès disques et ce sur
SCSI/PATA/SATA/FC. Maintenant, les choix de techno sont fait précisement
en fonction du type d'accès effectué (SCSI/FC quand on requete de
nombreux petits blocs, PATA/SATA quand les IOs disques sont optimisables).

Je parle de fonctionnement _logique_. Du point de vue logique, une
carte SCSI est plus simple qu'une carte xATA parce que le gros du
boulot est fait dans le contrôleur qui est sur le disque alors que
le contrôleur ATA est sur la carte avec un adaptateur sur le disque.
Par ailleurs, les mots adaptateur et contrôleur sont ceux qui sont
utilisés en électronique.

Vous pourriez justifer vos assertions ?

Non. Le CPU ne travaille peut-être plus pour gérer des IO (mais il y
a belle lurette que le contrôleur xATA n'est plus géré directement
par le CPU), mais il y a toujours une consommation de temps système
plus importante que dans le cas du SCSI parce que justement, le
contrôleur est sur la carte-même ! Faites un schema, vous
comprendrez mieux ou se situe le goulot d'étranglement.

Vos controlleurs, qu'ils soient sur la carte mère ou sur une carte fille,
se trouvent quasi-systematiquement sur un bus PCI (standard, étendu,
express ou tout autre) et ont exactement accès aux mêmes
fonctionnalités.

PS: fin de la discussion

Comme c'est facile.

François

Salut,

Typiquement, pendant très longtemps, l'interface ATA
était exclusivement gérée par le CPU (de fait, ATA signifiait
AT-attached : les nappes respectaient les timings/specs du bus ISA des PC
IBM AT) ce qui entrainait une consommation CPU considérable (de mémoire
mais je peux me planter, il devait y avoir une interruption déclenchée
tous les mots de 16 bits).

Euh, faut quand même pas exagérer. :-) Une interruption par secteur
c'était déjà bien assez.

On Mon, 26 May 2008 11:30:21 +0000, JKB wrote:

Pour mémoire :
SCSI : adaptateur côté carte-mère et contrôleur sur disque
xATA : contrôleur côté carte-mère et adaptateur côté disque

Ça vient d'où ? Pour ma part c'est adaptateur côté hôte et contrôleur
côté disque dans les deux cas. Il n'y a que dans les très vieux disques
pré-IDE (ST-506) que le contrôleur n'était pas intégré au disque mais
sur une carte d'interface (comme les lecteurs de disquettes).

Bon. Je vais donc reprendre. Comment expliquer que pour une machine
avec une carte Adaptec 29160 et une autre SATA dont j'ai oublié le
nom (faudrait que j'ouvre la bête, mais c'est une adaptec aussi),
sur une carte mère Tyan bipro
Opteron, avec des disques SATA-II et U320 de Fujitsu par ailleurs
_identiques_ (même caractéristiques à un pouillème près sauf
l'interface), une requête sur une base de données sur les U320 prend
quelques secondes alors que sur la réplique en SATA-II, cela prend
plusieurs minutes en bouffant du temps système de façon éhontée ?

Carte ou pilote SATA moisi ?

On Tue, 27 May 2008 12:18:14 +0200, Pascal Hambourg wrote:

Typiquement, pendant très longtemps, l'interface ATA
était exclusivement gérée par le CPU (de fait, ATA signifiait
AT-attached : les nappes respectaient les timings/specs du bus ISA des PC
IBM AT) ce qui entrainait une consommation CPU considérable (de mémoire
mais je peux me planter, il devait y avoir une interruption déclenchée
tous les mots de 16 bits).
Euh, faut quand même pas exagérer. :-) Une interruption par secteur

c'était déjà bien assez.

Ooops, au temps pour moi. Effectivement, l'interruption était là pour
signaler qu'un secteur avait été lu et il fallait aller récuperer les
256 mots de 16 bits sur l'IO port.

François

Le 27-05-2008, à propos de
Re: Avenir USB,
Francois Petillon écrivait dans fr.comp.stockage :

On Mon, 26 May 2008 15:02:26 +0000, JKB wrote:

Mais on s'en fout. Une carte xATA effectue des accès DMA, mais par
petits bouts parce qu'elle est bridée par la vitesse de la connexion
avec le disque, donc il y a des problèmes d'accès mémoire
concurrents à gérer.

Elle est bridée par la vitesse de connexion avec le disque ? Plait-il ?

Il est très rare d'avoir une lecture séquentielle
d'un seul fichier de plusieurs centaines de Mo. Et pour avoir fait
des tests avec des cartes contrôleur à buffer identiques mais avec
des tailles de buffers différentes, on ne voit plus de différence
dès qu'on utilise un buffer raisonnablement grand (typiquement dans
mes tests, j'obtenais de bons résutats pour 128 Mo).

Pour commencer, la carte controlleur peut bufferiser (typiquement, les
cartes controlleurs que nous utilisons gèrent entre 512 Ko et quelques
Go) et je ne vois pas l'interet de balancer en mémoire centrale des
données avant d'avoir le bloc complet (d'aucuns diront que cela permet de
réduire légèrement la latence mais c'est relativement négligeable). De
plus, OK, considerons que vous ayez raison. Ces problemes d'accès
mémoire concurrents ralentissent legerement les accès mémoires.
Maintenant, ce sont tous les accès mémoires qui sont ralentis, pas juste
lorsque le CPU est en mode systeme. De fait, votre explication ne cale pas
avec le probleme que vous aviez décrit.

Une carte SCSI ou SAS ne se comporte pas du
tout de la même façon parce que le flux de données est plus
régulier.

La régularité du flux de données est négligeable en regard des
capacités de l'electronique (au sens où le controlleur passe son temps
à attendre). De plus, les disques, qu'ils soient SCSI, SATA, PATA ou
autre, ne transferent les données qu'une fois qu'elles ont été lues
(donc bloc par bloc). Il n'y a donc pas de regularité/irrégularité dans
le transfert de données sur le bus SCSI/xATA/autre.

S'il n'y a _que_ les données qui circulent, ce qui n'est pas le cas.

Essayez de faire des benchs de montée en charge sur un
serveur (en accès aléatoire) avec un coup des disques xATA et un
autre des SCSI.

Je bosse pour un FAI et je gère/j'ai géré quelques services
relativement lourds nottament sur les accès disques et ce sur
SCSI/PATA/SATA/FC. Maintenant, les choix de techno sont fait précisement
en fonction du type d'accès effectué (SCSI/FC quand on requete de
nombreux petits blocs, PATA/SATA quand les IOs disques sont optimisables).

C'est exactement ce que je dis, mais exprimé avec d'autres mots.

Je parle de fonctionnement _logique_. Du point de vue logique, une
carte SCSI est plus simple qu'une carte xATA parce que le gros du
boulot est fait dans le contrôleur qui est sur le disque alors que
le contrôleur ATA est sur la carte avec un adaptateur sur le disque.
Par ailleurs, les mots adaptateur et contrôleur sont ceux qui sont
utilisés en électronique.

Vous pourriez justifer vos assertions ?

Ouvrez n'importe quel databook de composant SCSI ou ATA.

Non. Le CPU ne travaille peut-être plus pour gérer des IO (mais il y
a belle lurette que le contrôleur xATA n'est plus géré directement
par le CPU), mais il y a toujours une consommation de temps système
plus importante que dans le cas du SCSI parce que justement, le
contrôleur est sur la carte-même ! Faites un schema, vous
comprendrez mieux ou se situe le goulot d'étranglement.

Vos controlleurs, qu'ils soient sur la carte mère ou sur une carte fille,
se trouvent quasi-systematiquement sur un bus PCI (standard, étendu,
express ou tout autre) et ont exactement accès aux mêmes
fonctionnalités.

Et alors ? Le bus PCI est un bus dont les techniques d'accès ont des
performances basses dès qu'on essaye de transférer des petits blocs
de données. Donc les perfs sont différentes en fonction de
l'utilisation du bus indépendamment de la carte qui est connectée
dessus.

PS: fin de la discussion

Comme c'est facile.

Non, ce n'est pas facile. J'ai fait du hard avant de faire du soft
sur des équipements temps réel (de ceux où on compte les nombres de
cycles sur les bus) pendant plus de dix ans avant d'avoir changé de boulot.
Contrairement à ce que vous pensez, j'ai une très bonne connaissance
des techniques d'accès aux disques, du hard qu'il y a derrière et
des différents problèmes des différents bus et de la complexité
sous-jacente.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

On Tue, 27 May 2008 11:52:20 +0000, JKB wrote:

Je parle de fonctionnement _logique_. Du point de vue logique, une
carte SCSI est plus simple qu'une carte xATA parce que le gros du
boulot est fait dans le contrôleur qui est sur le disque alors que
le contrôleur ATA est sur la carte avec un adaptateur sur le disque.
Par ailleurs, les mots adaptateur et contrôleur sont ceux qui sont
utilisés en électronique.
Vous pourriez justifer vos assertions ?

Ouvrez n'importe quel databook de composant SCSI ou ATA.

Voilà une requete de lecture de secteurs en SATA :
----
READ FPDMA QUEUED (60h)

Word 00h : Feature
the number of logical sectors to be transferred. A value of 0000h
indicates that 65536 are to be transfered
Word 01h : Count
bit description :
15:8 -> Reserved
7:3 -> NCQ Tag
2:0 -> Reserved
Word 02h/03h/04h : LBA
Adress of the first logical sector to be transferred
Word 05h : Device
bit description :
15 -> FUA (forced unit access)
14 -> shall be set to one
13 -> reserved
12 -> shall be set to zero
11:8 -> reserved
7:0 -> command (60h)
----
bref, une requete en lecture transmise à un périphérique SATA est formée
par une commande composée de l'identifiant de la commande elle-même
(60h), la quantité de données (Feature) à transferer depuis une adresse
spécifié (LBA) et un identifiant de requete (NCQ Tag).

Passons au SCSI maintenant :
----
Read(32)

Bytes 00h : Operation code (7Fh)
Bytes 01h : Control
Bytes 02-05h : Reserved
Bytes 06h :
bit 7-5 : Reserved
bit 4-0 : Group number
Bytes 07h : Additional CDB length (18h)
Bytes 08-09h : Service Action (0009h)
Bytes 10h :
bit 7-5 : RDPROTECT
bit 4 : DPO
bit 3 : FUA
bit 2 : Reserved
bit 1 : FUA_NV
bit 0 : Reserved
Bytes 11h : not defined in documentation!
Bytes 12-19h : LBA
Bytes 20-23h : Initial Logical Block Reference Tag
Bytes 24-25h : Expected Logical Block Application Tag
Bytes 26-27h : Logical Block Application Tag Mask
Bytes 28-31h : Transfer length
----
Bref, on peut voir qu'il y a des informations supplémentaires transmises
(sur la gestion des erreurs, le stockage de la requete dans le cache du
périphérique) mais on retrouve la même base : un identifiant de
requete, un offset et la quantité de données.

Bref, où voyez-vous une différence _fondamentale_ entre ces deux
requetes ?

François

On Fri, 23 May 2008 10:55:08 +0200, Francois Petillon
<fanch@fanfan.staff.proxad.net> wrote:

Maintenant, il n'existe pas de solution parfaite et c'est la
problematique qui doit diriger le choix de la technologie.

exactement, et si au meme prix on peut passer de 36Go à 1To pour des
techno différentes on peut raisonnablement se poser la question de
savoir s'il y a une raison ou si c'est juste un attrappe couillon.


--
pas de turlututu. apres l'@robase

Le Gaulois wrote:

Je ne vois pas l'intérêt de consulter une quelconque vidéo sur ce
sujet, à moins que ce ne soit une astuce pour inciter à la voir.
Le jour où le port USB aura un débit comparable à l'interface IDE on
en reparlera.

Il n'y a pas que pour le débit que l'USB n'est pas très satisfaisant.
Il y a aussi le taux d'occupation du CPU, le problème des HUB qui ne
sont pas toujours transparents, les mises en protection de
l'alimentation de l'ordinateur à cause de l'alimentation d'un
appareil USB, les plantages de l'explorateur de Windows 2000 au
moment du branchement d'un appareil USB, etc.
Le SCSI n'est plus à la mode et c'est assez nettement plus cher
mais c'est nettement plus agréable à utiliser.

de toute façon son post n'a pas de sens car il contient une question
particulière, et un titre qui n'a pas forcément à voir... que les disques
deviennent tous externes pourquoi pas, mais pour l'usb...