Bonjour tout le monde...    
 
Petite question à laquelle je n'ai pas su trouver de réponse...
 
Si je prends une carte mère B550 (ROG Strix B550-E Gaming, par exemple), elle est équipée de deux emplacements M.2 : un PCIe 4.0 et un PCIe 3.0.
Quels sont les débits max proposés par l'emplacement PCIe 3.0 ?
Question autrement posée : un Samsung 980 PRO (7000 Mo/s en lecture et 5000 Mo/s en écriture) serait bridé par le PCIe 3.0, mais quels seraient ses débits ?
 
Merci d'avance !  

3600/3600 à la louche, comme ça.

Sachant que pour avoir ces débits il faut être dans les bonnes conditions.
Dans la vraie vie il y a peu de chance que tu y arrives.

PCI-E 3.0 : 4Go/s en x4 au maximum.
PCI-E 4.0 : 8Go/s en x4 au maximum.

Perso j'ai ça sur un crucial P2 1to 'basique' en crystaldiskmark

crystal ce n'est pas la vraie vie mais du test.

On est bien d'accord mais c'est la référence usuelle de débit....

Même si en usage courant c'est 3x moins en pratique dur copie fichiers....

et encore c'est plutôt 4 à 5 fois moins.

Ouais c'est comme avec l'USB, perso j'ai jamais eu les débits annoncés, au mieux j'ai à peine 3 fois moins.

Merci à tous pour vos réponses !    
 
@ zonka :  
Question p'tet bête, mais comment peux-tu avoir du 3,6Go/s en lecture et en écriture avec un Crucial P2 qui est donné pour 2,4Go/s et 1,8Go/s ?    
https://www.crucial.fr/products/ssd/crucial-p2-ssd
 
Je pourrais tourner ma question initiale de la sorte :  
Est-ce qu'un SN850 fera (beaucoup) mieux qu'un SN750 dans un emplacement M.2 PCIe 3.0 ?
Ou bien est-ce stupide de mettre un disque PCIe 4.0 dans un emplacement PCIe 3.0 ?

Pour l'USB, c'est surtout la mémoire du support externe qui ralentie la copie. Le connecteur, normalement, est toujours adapté pour qu'il ne sature pas mais on peut être très très loin des taux de transfert qu'il permet. De plus, très souvent, on t'annonce les taux de transferts en lecture en gros sur la boite (je pense surtout aux clés USB) mais on oublie de te dire que que la vitesse en écriture est divisée par 4 ou 5.  
 
En revanche pourquoi investir dans un 980 pro si tu comptes le mettre dans un port en pcie 3x? C'est quand même bcp plus cher pour un gain dont tu ne pourras même pas profiter. Autant allez vers un 970 evo plus ou équivalent, non?

Pour le P2 peux pas le tester a vide il tourne H24 pour l'instant mais j'avais des chiffres de cet ordre

@ damiou_03 :
Ben pour l'instant, j'en suis à me demander si c'est intelligent ou si c'est une grosse con***** que d'installer un disque PCIe 4.0 dans un emplacement PCIe 3.0.
Un disque PCIe 3.0, c'est en gros de la lecture à 3 500 Mo/s et de l'écriture à 3 000 Mo/s (en théorie, pour les plus performants).
Et un disque PCIe 4.0, c'est de l'ordre de 7 000 Mo/s en lecture et 5 000 Mo/s en écriture.
Si le PCIe 3.0 bride un disque à 3 600 Mo/s en lecture et en écriture, le jeu n'en vaut pas la chandelle.
Mais si le PCIe 3.0 bride à 5 000 Mo/s, c'est déjà plus intéressant.
 
Donc voilà... Je me demande si le fait d'installer un disque PCIe 4.0 dans un emplacement PCIe 3.0 est intéressant ou pas. :-)

Dans ce cas, c'est bien ce que t'indiquais Artouillasse, débit théorique max à 4go/s pour le pcie3. Mieux vaut pour toi partir sur un bon NVME en Pci3 que surpayer un Pcie4 maintenan qui sera bridé.  
 
Je serai juste un peu moins définitif que mes collègues sur l'utilité d'aussi gros débits pour un usage courant. A moyen terme, avec des choses comme le direct storage qui va être intégré dans Dx12, on devrait pouvoir y trouver une utilité un peu plus mainstream.

Merci pour ta réponse !
 
En fait, je suis en train de dresser la liste des composants de mon prochain PC, à usage "montage vidéo".
Le second SSD M.2 servira pour les rushes.

C'est alléchant sur le papier en effet mais je pense qu'on ne le verra pas débarquer à la prochaine génération de jeux vidéos, ou alors sur 2-3 titres mais pas plus, peut-être que ça se démocratisera à l'avenir mais pas dans l'immédiat, déjà parce que ça suppose que le client ait les moyens d'une plateforme récente avec du PCI-E 4.0.
 
Apparemment la "beta" de direct storage serait dans les bacs en septembre 21, faudra bien laisser une année aux dev de jeux pour implémenter la techno dans leur création, voir plus. Avec les divers bug et autres correctifs qui seront certainement apportés il faudra en plus attendre la version finale de Direct storage.
Bref à mon avis on est encore à peu près tranquille pendant 3 ans le temps que la techno aboutisse en elle même, et à celà s'ajoutera le temps que la plupart des éditeurs de jeux l'adoptent.

Cette histoire de direct storage, il y a malheureusement de grandes chances que ce soit artificiellement limité aux disques NVME alors que même les disques durs devraient pouvoir en profiter.
S'ils ne limitent pas ca au NVME, il est possible que les SSD Sata ne se retrouvent pas bien loin derrière les SSD PCIE.
 
Il n'y a qu'a voir sur PS4 ce qu'une simple mise à jour système a permis de gagner en temps de chargement sur certains jeux avec son HDD anémique.

Du coup ce serait plus une histoire de temps d'accès que de débits si je te suis bien ?

Oui surtout d'IOPs. La décompression étant faite par le GPU et non plus le CPU:

 
Le temps nous le dira mais sachant que c'est pris en charge sur console donc il y a de bonnes chances que ce soit adopté rapidement pour les jeux qui en tirent un bénéfice.

Je ne suis pas d'accord. Le direct storage est prévu spécifiquement pour bénéficier des débits et temps d'accès des NVME, ce ne me semble pas artificiel. Dans les faits, un NVME en pcie 4 peut fournir un débit de près de 3Go/s en 4k Q8T8, plus 10 fois ce que peut fournir un bon SSD Sata, mais c'est extrêmement gourmand en usage CPU et donc pas du tout adapté au jeu.  
 
De ce que j'ai compris, un des buts de direct storage en plus de proposer la décompression des texture via le GPU, est d'optimiser dans l'API la gestion des requêtes qui n'est pas adapté à ce que permettent les NVME et qui fait qu'actuellement, les perfs en SATA ou NVME sont à peu prêt identiques.
 
https://www.techpowerup.com/281289/ [...] -ssds?cp=2

Je ne dis pas le contraire juste que les SSD Sata devraient également pouvoir en tirer parti et donc proposer au moins des temps de chargement plus courts.
Car d'un point de vu IOPs les NVME ne sont pas à des années lumières des Sata (HDD -> SDD SATA ~x125, SSD SATA -> NVME ~x10 (en prenant le meilleur SSD de chaque catégorie) sinon on est plus autour de x5) et je ne pense pas que les SSD Sata soient exploités à leur plein potentiel actuellement.
 
Bref, wait and see

Ah je pensais que la ram n'était pas utilisée dans la boucle du Direct storage, je croyais qu'il n'y avait le lien qu'entre le GPU et le SSD.

 
Pas vraiment parce que le problème du SATA est que la file d'attente est limitée à 32 requêtes contre 65000 pour le NVME, donc il n'y a pas de gain possible en SATA, là où la marge est très importante pour un Nvme rapide car il est actuellement bridé par l'API qui a été dimensionnée pour du SATA.

Les 65536 listes de 65536 commandes du NVME par rapport à la liste de 32 commandes de l'AHCI permettent d'avoir plus d'IOPS théoriques supporté par le protocol mais cela ne veut pas dire que les matériels peuvent supporter autant.
Les valeurs communiquées par les constructeurs sont des valeurs théoriques max que le HW peut supporter faisant abstraction des couches de plus haut niveau. Donc le facteur 10 reste toujours valide, peu importe ce que le protocol permet.
On peut partir du même constat sur le système de chargement des jeux qui n'a pas évolué non plus lors du passage du HDD vers le SSD et donc pourrait être largement bénéfique aux SSD AHCI.

Tout cela reste de la philosophy de comptoir. J'espère que cette nouvelle méthode ne sera pas uniquement réservée au NVME, ne serait-ce que pour profiter de l'utilisation mémoire réduite (et donc des transferts PCIE réduits) et de la charge moindre du CPU.
Pour rappel, les NVME PCI-E 3.0 4x d'entrée de gamme plafonnent à 110k IOPS 1600 Mo/s read, 800 Mo/s write donc rien de bien sexy. Mon SSD PCIE AHCI fait mieux en write et en IOPS (810Mo/s et 120K) et les SSD Sata ne sont pas bien loin derrière.