Quelle est la taille du cache des SSD avec contrôleur Indilinx ?

[Grosnours]

Tu aurais pu encore trouver plus petit comme screenshot, parce que là c'est galère à lire...

Bon voilà le mien :


La différence dans la manière dont le firmware (l'histoire est racontée ici, un article à lire absolument) est codé explique nos différences de perfs, mais j'ai beau chercher le net à la recherche d'un tracé HD Tune de ton disque comme référence, je n'ai rien trouvé. D'où tire-tu les perfs "supposées normales" de ton disque ?

[Jonathan]

D'où tire-tu les perfs "supposées normales" de ton disque ?

Du SSD !
G.Skill affiche partout (SSD, boite, doc, site) les fameux (et très optimistes) 230 Mo/s (lecture) et 135 Mo/s (écriture).
Mais le sujet du topic, ce n'est pas les performances du Falcon.

Pour revenir au cache, l'erreur de détection a toujours été mon hypothèse favorite. Aurons-nous un jour un logiciel capable de faire le job correctement ?

[Grosnours]

Bonne question.
Mais en même temps, je ne sais pas si c'est une fonctionnalité essentielle à implémenter dans les yeux des devs.

[newbie06]

Mais en même temps, je ne sais pas si c'est une fonctionnalité essentielle à implémenter dans les yeux des devs.

C'est surtout qu'il n'y a aucun moyen fiable de deviner la taille de cette cache.

Petit exemple : imaginons qu'un constructeur mette 64 Mo de RAM sur son disque/SSD. Il pourrait tres bien utiliser une partie de cette RAM pour stocker des infos qui ne sont pas des donnees a transferer (genre liste des secteurs libres, liste des blocks recemment ecrits/lus, etc.). Du coup seule une partie de cette RAM est dediee au cache data, donc tout logiciel qui va tenter d'evaluer la taille de cache va indiquer la taille de cette partie qui est inferieure a la quantite de RAM effective sur le controleur.

Apres on peut toujours dire que les constructeurs n'ont qu'a nous dire ce qui est vraiment utilise comme cache data, mais c'est une autre histoire, et en plus ca dependra du firmware