Página 1 de 858 123451151101501 ... ÚltimoÚltimo
Resultados 1 al 10 de 8572

Tema: SSD - Casi todo lo que siempre quisiste saber y nadie supo responder

  1. #1
    Vive aquí
    Ubicación
    España
    Mensajes
    784

    Predeterminado SSD - Casi todo lo que siempre quisiste saber y nadie supo responder

    Gracias al gran trabajo de mk_dir, este hilo se ha vuelto un hilo de referencia en el foro para la gente que quiere saber más sobre SSD's. Así que se me ocurrió ofrecerle mi colaboración para modificar los primeros hilos de este post de forma que la gente que empiece a leer post encuentre más fácilmente la información que busca.

    De lo que se trata aquí es que la gente después de leer esto tenga una idea más clara de qué va esto de los SSD's. Y si queréis profundizar más sobre el tema al final encontrareis links muy interesantes (recomiendo leer los dos de anandtech antes que los demás para completar el curso "rápido" de SSD's). Así que sin más demora vamos a empezar.

    Versión del 28/08/09

    INTRODUCCIÓN

    A diferencia de los discos duros normales los discos SSD no tienen discos magnéticos, motores, cabezales ni partes que se muevan. Un disco SSD no es más que un grupo de módulos de memoria flash conectadas en una placa de PCB. Este PCB tiene una controladora, los módulos de memoria flash y opcionalmente una cantidad variable de memoria DRAM que se usa a modo de memoria caché.

    Hasta aquí un disco SSD y un USB stick se parecen mucho, pero principalmente hay dos cosas que los diferencian. En primer lugar, el disco SSD va conectado por SATA (o PATA) un protocolo mucho más eficiente que el USB. En segundo lugar, un disco SSD, gracias a su avanzada controladora puede leer de muchos módulos de memoria a la vez (unos 8 o 10 es un valor normal en los SSD actuales).

    Muy bien, pero ¿cuáles son las diferencias con un disco duro normal de toda la vida? Un disco duro tiene uno o varios platos magnéticos que giran y cabezales que se mueven hasta el punto donde está la información a leer o a escribir, todo esto realizado unos motores eléctricos. En cambio un disco SSD no tiene que hacer todo este proceso mecánico por lo cual el tiempo de acceso a la información, en teoría, es mucho más rápido.

    Una de las diferencias básicas entre diferentes SSD es la memoria que usan. La Flash que usan los discos SSD (y los USB sticks) puede ser de dos tipos diferentes:
    - SLC (Single Level Cell): almacena un solo bit de información en cada celda. Esto la hace más robusta por lo cual es más rápida y tiene un tiempo de vida 10 veces superior a una memoria MLC (de media). Por estos motivos se usan en productos para servidores y para empresas y en productos antiguos (pues todavía no existía MLC).
    - MLC (Multi Level Cell): almacena más de un bit en cada celda. Esto la hace más lenta y menos duradera, pero es mucho más barata de fabricar. El reducido precio de fabricación es lo que hace que no encontremos ante el producto que usaremos nosotros los usuarios de PC ahora y en el futuro.
    Las celdas SLC tienen un máximo de alrededor de 1 millón de ciclos de escritura frente a los 100.000 ciclos de las celdas MLC. Esto hace que la controladora tenga que repartir un poco la información por todo las celdas disponibles para optimizar la vida del producto. Como veremos más adelante esto tiene ciertas implicaciones importantes.


    RENDIMIENTO I

    Bueno, los SSD's son muy rápidos pero no todos y no en todas las cosas son mucho más rápidos que los discos duros. Así que vamos a empezar explicando los diferentes tipos de escenarios en que nos podemos encontrar. Antes de nada permitidme una "licencia poética" definiendo tres categorías: discos duros (los de toda la vida), SSD's malillos (los SSD's baratos que no deberías comprar a menos que esteis muy seguros de lo que haceis), SSD's buenos (los que realmente son mejores o iguales que un disco duro en todos los aspectos).

    Los test de rendimiento donde SSD's buenos = SSD's malillos = discos duros:
    -Lectura secuencial: leer un archivo de 1 GB o cargar un mapa de un juego (rendimientos equivalentes con diferencias del simple al doble).
    -Escritura secuencial: escribir un archivo de 1 GB como sería grabar un rar de una ISO (rendimientos equivalentes con diferencias menos que en el caso anterior).

    Los test de rendimiento donde SSD's buenos = SSD's malillos > discos duros:
    -Lectura aleatoria de archivos pequeños: encender el Photoshop, el Outlook y el pasar el scanner del antivirus todo a la vez (todos los SSD, hacen esto de maravilla, los discos duros son MUY MUY MALOS en esto (40MB/s vs 0,8 MB/s)).
    -Tiempo de acceso en lectura: el tiempo que tarda el disco en empezar a leer un archivo, está relacionado con el dato anterior (todos los SSD, hacen esto de maravilla, los discos duros son MUY MUY MALOS en esto (0,1 ms vs 10ms)).

    Los test de rendimiento donde SSD's buenos > discos duros > SSD malillos:
    -Escritura aleatoria de archivos pequeños: cuando estás navegando por internet en páginas web que usan cookies, chatear con el messenger (con los logs activados), el archivo de paginación de Windows, modificar el nombre del artista de muchos mp3 a la vez en el iTunes, etc ... (los "SSD buenos" son muy rápidos en estas tareas, unas 20 veces más que los discos duros normales y estos son unas 20 veces más rápidos que los "SSD malillos")
    -Tiempo de acceso en escritura: el tiempo que tarda el disco en empezar a escribir un archivo, está relacionado con el dato anterior (los "SSD buenos" son muy rápidos en estas tareas, unas 20 veces más que los discos duros normales y estos son unas 20 veces más rápidos que los "SSD malillos").


    Continua en el siguiente post...
    Última edición por pmonti80; 28/08/2009 a las 15:08

  2. #2
    Con domicilio en Noticias3d.com Avatar de mk_dir
    Ubicación
    Santiago de Compostela
    Edad
    27
    Mensajes
    8,081

    Predeterminado Re: SSD's casi todo lo siempre quisiste saber y nadie supo responder (Anandtech)

    (ACTUALIZADO 26/12/09)

    DISEÑO INTERNO Y CONTROLADORAS

    El modelo inicial y protagonista de los SDD más baratos es la controladora JMicron 602/602B. Es por tanto el diseño más básico. El problema es que su rendimiento en escritura (sobre todo no secuencial) es muy bajo e irregular, además sufren stuttering (micro bloqueos, como cuando metes un CD en el ordenador, pero más corto) al no contar con memoria DRAM de apoyo (la JM602 únicamente tiene 16KB de memoria interna).



    Estas controladoras también pueden funcionar en RAID0 interno (controladas por una 3º que las gestiona de forma exclusiva, como se puede apreciar en la imagen). El rendimiento aumenta considerablemente pero los problemas de base de este tipo de controladores no se solucionan:



    Tras haber quedado muy superada por otras controladoras, JMcron tiene desde hace tiempo un nuevo diseño en desarrollo, se trata de la JMF612, que como mínimio solucionaría los problemas más graves presentes en su antecesora. Ya existen algunos modelos disponibles aunque no de forma generalizada, como el A-DATA S596. En Bit-Tech se ha publicado una completa review con este nuevo diseño como protagonista, se puede encontrar aquí. Las impresiones son muy buenas y la mejora más que notable. Además parece que estos SSDs serán actualizables además de contar con soporte TRIM y sistemas de autolimpieza. Con estas mejoras, JMicron podría competir en igualdad de condiciones con los actuales reyes del sector.



    Cada vez más se percibe cuales serán los diseños que dominarán el mercado a, por lo menos, medio plazo. Son los tres que os comento a continuación.



    El famoso Indilix Barefoot (ARM7) utilizando DRAM Elpida (diseño utilizado por Vertex y recientemetne Supertalent UltraDrive ME), con un gran potencial de mejora, ya que se desconoce hasta donde podrá llegar la eficiencia de la controladora Barefoot y su pipeline que gestiona los datos desde la interfaz SATA hasta las celdas NAND. Se han visto prototipos de esta controladora funcionando en RAID0 interno (de forma similar a las JMicron duales), el rendimiento que alcanza deja a la interfaz SATA2 pequeña. OCZ fue la primera, pero actualmete ya se pueden encontrar más SSDs basados en este diseño, como el G Skill Falcon o el SuperTalent Ultra ME.



    El diseño de Intel con su controladora propia y DRAM Samsung. Hasta ahora el diseño a batir, seguido muy de cerca por los otros dos, cada vez las diferencias son menores. Además Intel se ha centrado explícitamente en el rendimiento lectura/escritura aleatorio, dejando un poco de lado el rendimiento secuencia, sobre todo el de escritura. Además, su coste por GB actualmente es mayor, aunque se esperan novedades importantes antes de final de año. He aquí un ejemplo de la orientación hacia el rendimiento aleatorio de la controladora de Intel:




    Se rumorea que Hitachi utilizará este diseño de forma similar a lo que ya ha hecho Kingston.

    Existe un tercer diseño que está empezando poco a poco a cobrar más presencia, no es otro que el controlador diseñado por Samsung (la DRAM también es de Samsung), que también ha mejorado bastante últimamente a través de nuevos firmwares. No nos olvidemos, que será el diseño que por ejemplo utilizarán los inminentes OCZ Summit (Junio). Corsair ya ha presentado una gama completa utilizando este diseño.



    Ninguno de estos diseños sufre ni problemas de stuttering ni de longevidad, el único punto flaco a nivel técnico es la degradación de rendimiento (más información en el siguiente apartado), a la espera de sistemas que soporten instrucciones TRIM. De todas formas, lo más seguro es que estos 3 diseños cuenten con ese soporte (de hecho el Vertex ya lo tiene en versión experimental).

    Hay algunos datos sobre una nueva controladora de Marvell, de la que por ahora solo hemos podido ver en un prototipo SATA3 con memorias ROM (no NAND), existe una preview en PC Perspective. Antes de emitir ningún juicio sobre el diseño, será mejor esperar a más información, aunque no es probable que Marvell defraude, con la ventaja de poder evaluar como está el mercado de los SSDs actualmente y probando ya prototipos para SATA3, podría ser un contendiente a tener en cuenta.



    Al parecer OCZ está planeando lanzar una nueva gama de SSDs con un nuevo controlador de la mano de la hasta ahora poco conocida SandForce, con dos controladoras SF-1200 y SF-1500.

    Aunque los detalles técnicos y benchs (lo que nos interesa) no se desvelarán hasta el CES, serán versiones con NAND tanto MLC como SLC, interfaces que van desde SAS 6Gb/s hasta SATA 6Gb/s y capacidades entre 50GB y 400GB. En cuanto a las famosas tasas secuenciales, se comenta que serían unos 260MB/s tanto para lectura como escritura. Otras características anunciadas:

    • DuraWrite™, which optimizes the number of program cycles to the flash effectively extending flash rated endurance by 80x or more when compared to standard controllers.
    • Powerful flash media error correction (ECC) and RAISE™ (Redundant Array of Independent Silicon Elements), which deliver an orders-of-magnitude improvement in drive reliability versus today’s SSDs and enterprise HDDs. The result is single-drive RAID-like protection and recovery from a potentially catastrophic single flash block or die failure – all while avoiding the inefficiencies of traditional RAID.
    • Wear Leveling and Monitoring, which provides monitoring of flash block operational metrics to optimize wear leveling algorithms, further extending flash endurance.
    • Advanced Read/Program Disturb Management, which safeguards against errant reprogramming of cells during read and program cycles and unexpected power loss.
    • Recycler, which intelligently performs garbage collection with the least impact on flash endurance.


    La noticia es de The Tech Report.

    Ya tenemos una preview en Anandtech del primer SSD basado en la controladora de Sandforce, no es otro que el OCZ Vertex 2 Pro.



    Si existe un SSD más prometedor que los demás ahora mismo, ese es el Micron RealSSD C300 basado en una controladora propia. Sólo hay que echar un vistazo a sus especificaciones para darse cuenta:

    • Micron Technology, Inc. today introduced the RealSSD C300 solid-state drive (SSD), the fastest SSD for notebook and desktop personal computers (PCs)
    • The RealSSD C300 drive is the first to leverage the SATA 6Gb/s interface, providing read speeds of up to 355 megabytes per second (MB/s) and write speeds of up to 215MB/s
    • The RealSSD C300 drive is the first to use ONFI 2.1 high-speed synchronous NAND
    • Leveraging Micron’s industry-leading 34-nanometer (nm) multi-level cell (MLC) NAND flash memory, Micron’s RealSSD C300 drive – available in 128 gigabyte (GB) and 256GB capacities – is now sampling in limited quantities


    Con esas tasas secuenciales, obviamente será un SSD SATA 6GB/s.Aquí la nota de prensa de Micron.




    Un grande de los discos duros mecánicos como es Seagate, por fin ha movido ficha en cuanto a los SSD, anque por ahora únicamente con modelos Enterprise y NAND tipo SLC. Se trata de los Seagate Pulsar, aquí está la noticia y algunos datos. Aunque lo más interesante lo podemos encontrar en Anandtech con algunas pruebas preliminares. Muy prometedor pero por ahora a la expectativa de encarnaciones Mainstream con NANDs MLC.




    RENDIMIENTO II

    Una de las grandes críticas que últimamente se le hacen a este tipo de dispositivos es sin duda la degradación de rendimiento que sufren (gracias al trabajo de webs como Legit Reviews o PC Perspective, que se dieron cuenta del fenómeno al repetir las pruebas a lo largo del tiempo). Esta degradación la sufren TODOS los discos SSD, se produce en gran medida por la estructura interna de las memorias NAND y su organización. Un SSD se conforma de páginas de 4KB y bloques formados por un total de 128 páginas, es decir 512KB. La cuestión es que se pueden llevar a cabo procesos de escritura y lectura sobre páginas, sin embargo, sólo se pueden realizar procesos de borrado sobre bloques como unidad mínima.



    La forma en que funcionan los sistemas operativos hace que cuando borras un archivo simplemente se modifica una pequeña tabla que indica que ese espacio está libre. En un disco duro ese espacio no se borra realmente hasta que es sobreescrito por otro archivo y evidentemente los SSD's funcionan igual. La diferencia clave está en que pasa cuando sobreescribes un archivo en un disco duro y que pasa cuando lo haces en un SSD. Con el disco duro simplemente sobreescribes la zona del disco. En el SSD simplemente modificarás la tabla interna y grabarás los datos en una zona de espacio no asignada.
    Esto provoca que si los procesos de escritura que solicite la controladora no cuentan con espacio (páginas libres suficientes por cada cada bloque), se necesita una reorganización de los datos (páginas), y por tanto la necesidad de acometer un borrado (bloques). En primer lugar necesitas moverlos a una caché (puede ser la incluida en el SSD si existe en el mejor de los casos, en caso contrario deberá utilizarse una memoria off-die). Una vez hecho, el controlador puede iniciar los procesos de borrado para luego volver a escribir los datos que ha tenido que mover a caché, finalmente, el bloque se desplaza nuevamente al LBA del SSD después de haber realizado varias operaciones sobre caché. Obviamente, todo este proceso implica una penalización de rendimiento.



    Si la escritura cuenta con páginas libres todo este proceso no es necesario, la escritura se produce directamente, y mientras tenga espacio libre (páginas suficientes) el proceso será llevado a cabo de esta forma. Sin embargo, es obvio que con el uso del SSD, esta circunstancia terminará por no ocurrir y las reorganizaciones serán necesarias. En ese momento, el rendimiento del SSD decaerá a medida que aumenten estas reorganizaciones.




    Un Intel X25-M afectado claramente por un estado de degradación. Más abajo, el rendimiento Con el SSD limpio.

    Es complicado precisar cuánto tarda un SSD en degradarse, en primer lugar porque se trata de algo progresivo, y en segundo lugar porque depende proporcionalmente del número de borrados y escrituras (procesos implicados en este fenómeno, no así la lectura por ejemplo). Además generalmente la degradación del rendimiento en los SSD's con buenas controladoras está limitado, quizá se pierda un 20% de rendimiento con respecto al estado limpio, pero aún así será mucho más rápido que los discos duros normales. Cierto es que se han encontrado algunos casos extremos, pero parece que a medida que se van descubriendo las compañías van sacando firmwares que solucionan esto (al menos Intel ya lo ha hecho una vez). Mientras llega una solución consistente, lo mejor es realizar benchmarks cuando el SSD está limpio, y así tener una referencia comparativa a lo largo del tiempo. Asimismo, también es muy recomendable contar con una imagen de sistema para respaldarla rápidamente si queremos "resetear" el SSD, al menos hasta que TIRM esté implantado completamente....

    Actualmente el mejor antídoto contra este fenómeno son precisamente las instrucciones TRIM. TRIM forma parte del estándar ATA. Así que cualquier sistema que soporte la especificación T13 para TRIM/DISCARD lo soportará automáticamente (como las últimas actualizaciones del kernel de Linux).
    En definitiva, si los controladores AHCI/SATA se actualizan con los parches con soporte para TRIM, sistemas como XP, Vista, Linux o MAC OS X ya estarían preparados. Aunque se comenta también la posibilidad de utilizar una utilidad de OCZ para forzar su uso en los comandos ATA.
    Por tanto, es necesario que lo soporte tanto el SO como el SSD en cuestión. Su funcionamiento simplifica mucho esos procesos de reorganización que producen la degradación de rendimiento. Cuando se elimina un fichero, el SO lanza el comando TRIM sobre el LBA del SSD, la controladora copia entonces el bloque a la caché limpiando ya las páginas que se han marcado como eliminadas y escribe directamente el bloque con las páginas ya disponibles de nuevo en el LBA del SSD. Por tanto el viaje por caché es mucho más breve y a demás, el proceso de escritura de los nuevos datos se realiza directamente en el SSD y no en caché. Por tanto, la degradación de rendimiento se ve paliada en gran medida, aunque por supuesto no se erradica. Actualmente las implementaciones TRIM a nivel experimental pueden ejecutarse bajo demanda del usuario, recorriendo y reorganizando los bloques cuando se lo ordenemos y poniendo a punto el SSD. Sin embargo, una implementación más integrada a nivel de SO permitirá que el SSD aproveche los tiempos de inactividad para llevar a cabo estos procesos de optimización automáticamente de forma transparente para el usuario. Como sabéis, la RC de W7 ya implementa este soporte, sólo falta que los nuevos Firmwares comiencen a aprovechar esta función. En cuanto a Linux, todavía no cuenta con ese soporte. Sin embargo su implantación necesita tiempo, básicamente por la falta de unidades SSD con soporte en el mercado (algo fundamental para el desarollo del soporte en el mundo GNU/Linux). Lo que sí es seguro es que ext4 contará con él antes o después.

    Hablando de W7, TRIM no será la única mejora que se introducirá a favor de los SSD, aunque quizás sí la más importante. Según sus propios diseñadores, se han intentado reducir la frecuencia de escrituras a nivel general, además, el sistema si detecta un SSD deshabilitará automáticamente la desfragmentación, superfetch y ready boost. En cuanto al pagefile, no recomiendan que los mantengamos en el propio SSD.

    DEGRADACIÓN DE RENDIMIENTO Y REUTILIZACIÓN DE BLOQUES

    La degradación de rendimiento es un efecto colateral del propio funcionamiento de la NAND. Ya sabéis, escribes en páginas (4KB) pero sólo puedes borrar en bloques (512KB). El SSD no elimina información cuando tu lo ordenas, sólo cuando se queda sin espacio para hacerlo y es ahí donde comienzan los procesos de reorganización y entrarían en juego las instrucciones TRIM o los algoritmos de autolimpieza a nivel de FW. Es decir, realmente no arreglas nada dejando una parte de la capacidad del SSD sin utilizar porque, al fin y al cabo lo que importa es la estructura lógica sobre la que estás trabajando, el echo de que existan X GB marcados como libres, no quiere decir que no existan datos en ellos, la organización del LBA no es tan simple. De hecho, ya la propia controladora del SSD establece su propia spare area sin que el usuario tenga que dejar espacio "libre". Por ejemplo en el caso de un X25-M de 80GB, aproximadamente 5.5GB. De todas formas el controlador de Intel es dinámico y utilizará cualquier parte del SSD para sus procesos internos, aunque no dejará al sistema acceder nunca a esos 5.5GB.

    Es decir, el área mínima de escritura es la página, pero eso no significa que sea el tamaño más grande que el SSD puede escribir, ya que existe el concepto de página lógica. Por un lado el software ve el SSD como una lista de direcciones lógicas, por otro, como el SSD escribe y borra información realmente en las NAND. Existe una capa de abstracción intermedia.

    Actualmente una cuestión clave es la limpieza de los bloques (donde TRIM tiene precisamente mucho que decir).



    Cuando llega una petición de escritura, se ubica en un nuevo bloque (extraido de FREE BLOCK POOL) y su estado pasa a ser usado (DATA BLOCK POOL), y será objetivo del algoritmo de limpieza cuando tenga el suficiente número de páginas con datos válidos escritas. En eso consisten básicamente los procesos de auto garbage collection.

    Estes procesos tienen una penalización en los picos de latencia de las escrituras aleatorias, aunque siguen siendo bajos en las medias, es el precio a pagar por los movimientos que realizan los algoritmos de garbage collection. Sin embargo, combanten de forma muy efectiva la degradación de rendimiento.

    A mayores, las instrucciones TRIM permiten dar prioridad a los borrados de bloques. Cuando desde el SO se envía una orden de borrado, TRIM interfiere y indica los LBAs asociados que ya no son necesitados para que añada esos bloques para limpieza y los devuelva a la FREE BLOCK POOL.



    Para ampliar información en este punto, nada mejor que el 2º artículo de Anandtech, The SSD Releap.

    FIRMWARE

    Como habéis podido comprobar, los Firmwares tienen un papel relevante en lo que al rendimiento y caracterísiticas de un SSD se refiere. Por un lado contribuyen a aumentar el rendimiento en alguna o varias facetas del SSD, por otro, pueden incluir soporte para nuevas tecnologías, el caso más relevante es TRIM por supuesto. Actualmente, varios SSD son actualizables, por supuesto todos los basados en Indilix Barefoot con la familia Vertex a la cabeza (que es el que mejor soporte recibe actualmente), pero también G Skill Falcon, aunque su foro está todavía empezando, e los Super Talent UltraDrive ME que ya cuentan con algun firmware que mejora el rendimiento en W7.
    Por su parte, las controladoras Intel también han recibido recientemente una actualización firmware que mejora los rendimientos de escritura y frena la fragmentaciíon interna gracias a unos algoritmos de escritura más eficientes.
    En cuanto a los SSD basados en controladoras Samsung como los Corsair, la cosa está un poco en el aire. En los foros de Corsair se asegura que no es necesaria ninguna actualización de firmware porque el SSD funciona correctamente. Como el soporte sólo es ofrecido por un sistema en fase RC y no se puede considerar acabado puede que se trate de una cuestión de tiempo, al fin y al cabo, en los otros SSD se puede considerar como soporte experimental. En definitiva, parece que cuando tanto el estándar como W7 esté finalizado, ese soporte llegará.

    Por lo que se puede leer en sus foros oficiales, parece que las tres controladoras contarán antes o después con ese soporte. Más alla de eso, podemos decir que Intel y OCZ son los que actualmente más actualizan sus firmwares para mejorar sus SSDs.



    Proceso de actualización de un X25-M.

    SITUACIÓN ACTUAL:

    Centrándonos en los 3 diseños actuales que mejor resultado están demostrando dar:

    Indilix Barefoot es la que más acusa la degradación de rendimiento, digamos que es el diseño que más espera la llegada de TRIM, cuenta con utilizades de restablecimiento de celdas pero su funcionalidad no es ni much menos óptima. Tiene muy buen rendimiento secuencial pero en general es más lento que la Intel y la Samsung en entornos reales. En definitiva, todavía tiene mucho potencial. Los SSDs que la montan son actualizables y las revisiones de firmware son habituales. Tanto es así, que la última revisión firmware de Barefoot implementa un algoritmo denominado Auto Garbage Collection, que inicia procesos de reorganización cuando el SSD está en reposo, tenemos algunas pruebas al respecto en PC Perspective. OCZ ha sido la primera en lanzar su FW para su Vertex (1.40 Beta, pronto disponible la versión final), otros SSD ya anunciado que están trabajando en firmwares con este soporte. Por si fuera poco, esta nueva versión también tiene soporte TRIM, aunque por ahora no operativa:

    ATA8 ACS2 TRIM is on the feature list for the new firmware (1.40 Beta), and the code is complete, but the feature was turned off in the 1585 build of OCZ's firmware. We *should* be seeing it at work in future builds, and will bring you the details once we see it in action on our testbed.
    La versión genérica del firmware para Indilinx Barefoot que da soporte para TRIM es la 1819, aunque al utilizarla se experimenta una ligera penalización en el rendimiento (-15% aprox) por lo que sólo es recomendable si podemos tener la funcionalidad TRIM activa en nuestro sistema. En caso contrario lo que recomendamos es utilizar el FW anterior (1571) y realizar las tareas de mantenimiento de forma manual a través de herramientas como wiper. Se trata de elegir entre la comodidad de TRIM, o mejores prestaciones a costa de tener que "limpiar" el disco manualmente de forma periódica. Sinceramente, pienso que mejor con TRIM, a pesar de la perdida de rendimiento, lo que ocurre es que los requisitos para su implantación son ahora mismo muy estrictos.

    A modo de resumen:

    • - Todos los Indilix usan el mismo firmware, aunque los llamen de otra manera (Mushkin Europe II, Falcon I, OCZ Vertex, etc)
    • - Hay dos firmware, el 1571 y el 1819.
    • - El 1571 no soporta TRIM y, por lo tanto requiere Wiper para mantener su rendimiento en el tiempo.
    • - El 1819 soporta TRIM para evitar la degradacion (solo con W7, solo algunas controladoras Intel, sin Raid, y con los drivers de Seven, no los de Intel) y es más lento que el 1571 porque el TRIM consume recursos, ciclos de lectura-escritura.
    • - La única excepción es el firmware 1.41 GC de OCZ, que no soporta TRIM, pero ejecuta la limpieza el solo sin intervención del usuario y sin limitaciones de Raid, S.O., u otras. Es más agresivo pero no necesita Wiper. Se puede flashear un disco que no sea OCZ con el, pero se pierde la garantía si algo falla.
    • - Wiper no debe de usarse con X64. En un alto porcentaje de equipos se pierden datos.



    A la hora de escogerlos, todos son muy similares ya que al fin y al cabo su diseño interno es el mismo (siempre hablando del conjunto de los Indilix Barefoot), con algunas consideraciones a tener en cuenta, el Agility por ejemplo utiliza unas NAND de peor calidad (y rendimiento, sobre todo para escrituras) que el Vertex, lo que le ayuda a ser más económico, otro caso sería el Falcon II, que utiliza una controladora versión ECO de menor rendimiento junto unas NAND de 34nm, ambas características contribuyen a disminuir su precio... Son actualizables y además, pese a que cada fabricante suele renombrarlos según su nomenclatura particular, los FW son originarios de la propia Indilix (son los fabricantes los que los numeran y adaptan para sus modelos en concreto). Así que al fin y al cabo lo más determinante será el precio por GB.

    El Intel es el más maduro, con el nuevo Firmware combate muy bien el efecto de degradación, además es el rey del rendimiento IOP y en escritura aleatoria (en WS o servidores es el rey). Quizá se desenvuelva mejor en servidores que en un entorno doméstico, en todo caso, sigue siendo una opción ganadora. El problema es que el soporte TIRM de esta controladora está un poco en el aire, aunque realmente, si siguen mejorando los algoritmos de borrado como han hecho ya, no sería tan necesario. Otra cuestión que puede desconcertar un poco es su bajo rendimiento en escrituras secuenciales, se cree, analizando su comportamiento, que el FW de intel limita las tasas de estas unidades para este tipo de operaciones, con el fin de aportar un grado de diferenciación con sus series SLC. De todas formas, la importancia de las operaciones de escritura secuencial es relativa, y en todo caso rondan de forma constante los 80MB/s.

    Con la salida de las series Postville (serie G2, con memorias NAND en 34nm) se ha asegurado que ese soporte exisitirá, aunque desgraciadamente no para las series G1. Por si fuera poco, las series Postville han mejorado mucho el coste por GB, haciéndose todavía más fuertes donde estos SSD ya sobresalían, en rendimiento aleatorio.

    Intel ha presentado un FW y una aplicación (SSD Tool Box) que añade el soporte TRIM para sus SSDs (únicamente para sus series G2 - Postville), además de mejorar el rendimiento secuencial en escritura de la versión de 160GB hasta los 100MB/s. Por otro lado, el SSD Tool Box añade herramientas de gestión así como una aplicación de limpieza bajo demanda bastante similar a wiper. La primera versión de este FW fué muy problemática y convertía en inservibles muchos de los SSD que se sometían al proceso de actualización. Sin embargo, ese FW fué retirado pocos días después. Ahora mismo, y tras semanas de espera, ha sido publicado ya el FW corregido, disponible para descarga, y su funcionamiento es correcto. Por tanto es recomendable la actualización para todos los propietarios de este SSD.

    Sobre la actualización de FW en SSDs Intel (aplicable a las dos generaciones), tenéis toda la información del proceso aquí en un documento publicado por la propia intel.

    La versión final se denomina 2CV102HD y ya está disponible en el site de Intel para descarga.

    Otra duda común que rodea a los Intel Postville es la identificación del formato por el código/referencia, se puede resumir en lo siguiente:

    • La terminación 01 indica que es OEM y de 7.0mm de grosor.
    • La terminación R5 indica que es Retail (incluye adaptador a 3.5") y de 9.5mm de grosor.
    • También hay la terminación C1 que es OEM y de 9.5mm de grosor


    Después del éxito de las series X25-M, Intel pretende ahora lanzar unas series denominadas X25-X orientadas a la gama más baja. Por ahora sólo ha sido oficialmente lanzado el modelo en 40GB (renombrado por Kingston, aquí una review). El rendimiento es bueno (la controladora es la misma que utilizan sus hermanos mayores) pero su escasa capacidad y su grave limitación para la escritura secuencial (40MB/s) perjudican bastante el resultado final. Esperemos que la rumoreada versión de 80GB pueda mejorar estos aspectos sobre todo los que conciernen a las limitaciones de tasas secuenciales.

    Sobre el SSD Optimizer de Intel, este white papper es una lectura muy recomendable.


    La controdadora Samsung tiene problemas serios con la degradación y la escritura aleatoria, de hecho su rendimiento IOPs es el peor con diferencia ya que cae en picado. Con todo, tiene a su favor un muy buen rendimiento en entornos reales de tranferencia y creación de ficheros. El problema fundamental de estas controladoras, es que pese a que los nuevos firmwares van introduciendo mejoras (soporte TRIM para la salida de W7?), no está del todo claro si los SSD ya en el mercado serán actualizables lo cual supone un problema, ya que la degradación afecta mucho al rendimiento secuencial en general de la controladora, aunque en las pruebas en entornos reales no han sido demasiado determinantes.

    Se ha confirmado que Samsung implantará soporte TRIM en sus nuevas revisiones firmware, el problema fundamental, es que sus SSD no son actualizables, asi que es interesante esperar a la hora de escoger un SSD con esta controladora.

    Artículo de referencia en The Tech Report.

    Finalmente, algunos de los modelos basados en controladoras Samsung RBB de más relevancia (como lo son el Corsair serie P y el OCZ Summit). El FW debe haber sido facilitado por Samsung hace poco ya que el anuncio por parte de los ensambladores ha sido prácticamente simultáneo. La mejor noticia sea quizá la presencia de los updaters para estas unidades, eliminando por fin uno de los grandes lastres de los diseños Samsung frente a la competencia más directa (Indilinx/Intel), la capacidad de actualización. No sólo eso, en el caso del OCZ Summit, también se incorpora el algoritmo GC desarrollado por ellos para los entornos donde la ejecución de TRIM no sea posible (la mayoría). Nos faltaría por ver si, el FW de OCZ puede utilizarse en otros SSD basados en la misma controladora Samsung, es decir algo similar a lo que ocurre con la controladora de Indilinx.

    Aquí un enlace al hilo oficial de Corsair y aquí otro al de OCZ. Aquí la noticia publicada en The Tech Report.

    Como se puede apreciar, los últimos avances se centran en eliminar el último gran problema técnico de estos dispostivos, la degradación de rendimiento. De aquí a final de año la situación habrá mejroado bastante; con la llegada de W7, un soporte para TRIM completo y la presencia de algoritmos de autolimpieza efectivos y que no requieran la intervención del usuario, de la mano de nuevas revisiones FW.


    SSDs EN LINUX



    Como veo que no está muy extendido el uso de los nuevos discos SSDs en Linux por el foro, voy a crear esta pequeña guía sobre congiuración, uso y precauciones que hay que tomar cuando vayamos a usar este tipo de dispositivos en Linux. No soy ningún gurú, así que toda la inforamación la he ido sacando de muchas páginas y muchos foros, y de ir peleandome con ello, lo que haré es juntar aquí todo lo que he ido recopilando y aprendiendo, y lo que considero personalmente que es lo que mejor va.

    Para más información sobre SSDs en general, controladoras disponibles, descripción técnica, étc, consultad este hilo

    Comentar que los SSDs han sido el mayor avance en el rendimiento del Pc desde hace muchisimo tiempo, y aunque ahora tengan un precio algo alto (sobre los 2€ por GB), espermos que dentro de un tiempo no muy lejano tenga unos precios más acordes y todo el mundo pueda tener acceso a una de estas maravillas.


    COMPARACION CON DISCOS TRADICIONALES (controladora SF-1200)

    ·Tiempo de acceso irrisorio (0,1 msg vs 8-10msg en HDDs)
    ·Velocidad de escritura/lectura sostenida (270MB/Sg vs 120MB/sg en HDDs)
    ·Hasta 60.000 IOPS (operaciones de entrada/salida por segundo) teóricos. Cifremoslo en el mundo real en 25.000 vs las 130 de un HDD.
    ·Consumo (2W vs 10W de un HDD)


    ¿QUÉ SISTEMA DE FICHEROS ELEGIR?

    Actualmente hay dos preparados para los SSDs: Ext4 y Btrfs.
    Mientras el primero es estable desde hace ya unas cuantas versiones del kernel y está en un buen estado de madurez, el segundo, prometedor donde los haya está aún en versión desarrollo.
    Además Ext4 tiene un rendimiento superior actualmente, así que este será nuestro sistema elegido para las particiones en un SSD.


    PRECAUCIONES A TENER EN CUENTA

    Si ya habeis leido el hilo de referencia (que deberia ser obligado), veremos que esta tecnología presenta un par de problemas:

    -Pérdida de rendimiento con el tiempo al ir escribiendo en las celdas.
    Tenemos un mecanismo para paliar esto llamado TRIM. Para usarlo debemos asegurarnos que estamos usando un kernel no anterior a la version 2.6.33. Además de ellos tendremos que montar las particiones ext4 con la opción discard

    -Número de ciclos de escritura no tan elevado como en discos mecánicos.
    Para evitar escrituras innecesarias en el disco vamos a montar las particiones con la opción noatime.
    Además sabemos que Ext4 es un sistema que realiza journaling, así que otra medida que podemos tener para evitar estas escrituras es deshabilitar el journaling a la hora de crear las particiones. Esto lo dejo a elección de cada uno, yo particularmente lo tengo deshabilitado, pero se puede habilitar en cualquier momento.
    Las cachés de los navegadores, los temporales, logs del sistema, etc, también realizan muchas escrituras, así que nos encargaremos de que en vez de escribir al SSD escriban a la RAM.
    La partición Swap la realizaremos en un disco mecánico, aunque para la gente que disponoga de 4GB de RAM y no quiera hibernar, mi recomendación es nisiquiera tenerla.

    Todo esto lo comentaba de una manera teórica. Más adelante explicaré detalladamente los pasos a seguir para realiazr todo lo que hemos comentado.


    PARTICIONADO DEL DISCO

    Este es un punto importante. Para sacar todo el rendimiento posible a un disco de estado sólido las particiones tienen que estar alineadas. Esto a grandes rasgos significa que una particion debe comenzar en un punto de la memoria que sea múltiplo del tamaño de borrado de celdas que tenga el SSD (dependiendo de uno u otro podría ser 128, 256, 512KB...)

    Si queremos usar una única partición que contenga /, /home, etc, con una distribución como Ubuntu 10.10, bastará entonces con meter el cd y que Ubuntu haga la partición del disco entero, ya que teóricamente lo alineará bien.

    Pero si vamos a tener varias particiones, o a deshabilitar el journal, o a instalar junto a Windows en el mismo disco necesitaremos realizar las particiones a mano y para esto vamos a usar fdisk.

    Se podría usar tanto GPT, como MBR, pero vamos a seguir por ahora con el tradicional MBR que es el que más compatibilidad tiene. Con las futuras sustituas de las BIOS, EFI, considero mejor usar GPT.

    Arrancamos con un livecd, o liveusb, de por ejemplo Ubuntu o alguna otra distribución. O si queremos podemos usar la instalacion que tengamos previa en otro disco duro para hacer el particionado del SSD. Es conveniente colocarlo en la primera toma SATA que tengamos de la placa, es decir, SATA 0, con lo que debería ser reconocido como /dev/sda. En caso de tener otro nombre, utilizar el que corresponda.

    Ejecutaremos en consola el siguiente comando:
    fdisk -S 32 -H 32 /dev/sda
    con el que le estamos indicando que la tabla de particiones tenga 32 sectors y 32 heads con lo que usará un tamaño de cilindro de 1024 bytes.
    Ahora vamos a crear las particiones, en mi caso voy a crear 2, una para / y otra para /home. Posteriormente comentaré el caso en el que queramos particionar con Windows también. / tendrá un tamaño de 20GB y el resto serán para /home

    Command (m for help): o
    Building a new DOS disklabel with disk identifier 0x8cb3d286.
    Changes will remain in memory only, until you decide to write them.
    After that, of course, the previous content won't be recoverable.

    The number of cylinders for this disk is set to 15711.
    There is nothing wrong with that, but this is larger than 1024,
    and could in certain setups cause problems with:
    1) software that runs at boot time (e.g., old versions of LILO)
    2) booting and partitioning software from other OSs
    (e.g., DOS FDISK, OS/2 FDISK)
    Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

    Command (m for help): n
    Command action
    e extended
    p primary partition (1-4)
    p
    Partition number (1-4): 1
    First cylinder (1-15711, default 1): 2
    Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711):+20G

    ......

    Command (m for help): n
    Command action
    e extended
    p primary partition (1-4)
    p
    Partition number (1-4): 2
    Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711):

    .....

    Command (m for help): w
    The partition table has been altered!

    Calling ioctl() to re-read partition table.
    Syncing disks.
    Bien ya hemos creado las 2 particiones, ahora vamos a darles el formato con nuestro sistema de ficheros elegidos: Ext4.

    Aqui también vamos a alinear los sistemas de ficheros, para los cuales usaremos según el disco que tengamos diferentes valores del stripe. Os pongo la informacion que saqué de un artículo referente a esto mismo:

    Intel SSDs with an erase block size of 128 (or 512 KiB -- Intel isn't quite straightforward with this, see the comments section for a discussion on the subject - if anyone from Intel is reading this, help us out! ) that are not part of a software RAID:
    -E stride=32,stripe-width=32

    OCZ Vertex SSDs with an erase block size of 512 KiB that are not part of a software RAID:
    -E stride=128,stripe-width=128

    Normal hard drives that are not part of a software RAID
    trust the defaults

    Any software RAID:
    -E stride=raid chunk size / file system block size,stripe-width=raid chunk size x number of data bearing disks
    Así que al estar haciendo las pruebas en un OCZ Vertex 2 vamos a crear los formatos con el valor que nos recomiendan:

    mkfs.ext4 -b 1024 -E stride=128,stripe-width=128 -O ^has_journal /dev/sda1
    mkfs.ext4 -b 1024 -E stride=128,stripe-width=128 -O ^has_journal /dev/sda2
    Fijaros en el parámetro -O ^has_journal. Con esto he indicado que la partición ext4 no tengo journaling. si alguno de vosotros quiere que sí lo tenga bastaría con quitar ese parámetro a la hora de darle formato a las particiones.



    CONFIGURACIÓN DEL SISTEMA OPERATIVO

    Una vez instalado el sistema que hayamos elegido vamos a proceder a tomar todas las precauciones a la hora de evitar escrituras innecesarias y repetidas, y habilitar la posibilidad de TRIM (todo lo que comenté anteriormente).


    Montaje de particiones

    En primer lugar vamos a tocar el archivo /etc/fstab, dónde se le dice al sistema los puntos de montaje y las opciones de montaje. Así deberían quedar las líneas referente al montaje a las particiones (si alguno le pone alguna opción más que la incluya).

    /dev/sda1 / ext4 defaults,noatime,discard 0 1
    /dev/sda2 /home ext4 defaults,noatime,discard 0 1
    Es conveniente como ya comenté antes que los logs, y temporales no escriban constantemente en el disco duro, así que vamos a crear unos tmpfs para que se escriban en la RAM. Esto se añadirá también al archivo /etc/fstab

    none /tmp tmpfs nodev,nosuid,noatime,size=2000M,mode=1777 0 0
    tmpfs /var/tmp tmpfs noexec,defaults,noatime 0 0
    tmpfs /var/log tmpfs defaults,noatime 0 0
    Le he dado un tamaño a /tmp de 2GB teniendo 4GB, pero podeis dejarlo sin ese tamaño y que se vaya ajustando sólo. Lo puse para que no llegara a saturarme la RAM en caso de creciera mucho, porque suelo compilar en el temporal para no gastar el disco duro, y un kernel ocupa bastante.
    Realmente si no compilais kernel en RAM podeis quitar esa opcion o dejar simplente 1GB, que es como lo tenia al principio. Esa tamaño que indicamos no va a ser el que esté ocupado, simplemtene pone un límite para ocupar en RAM, lo que se vaya ocupando es lo que se irá marcando en el consumo.


    Navegadores

    Vamos a mover también a la RAM las cachés de los navegadores, que realizan muchas escrituras, con lo cual no sólo ganaremos eso, sino que el navegador irá más rápido.

    Para Chromium:
    Añadir a /etc/fstab:
    cache-chromium /home/user/.cache/chromium tmpfs defaults,noatime,mode=1777 0 0
    Donde user es nuestro usuario. Después eliminar el archivo de caché que nos haya creado en nuestra /home y volverlo a crear:
    rm -R /home/user/.cache/chromium
    mkdir /home/user/.cache/chromium
    Para Opera ahora lo mismo:
    Añadir a /etc/fstab:
    cache-oprea /home/user/.opera/cache tmpfs defaults,noatime,mode=1777 0 0
    y después eliminar el archivo de caché que nos haya creado en nuestra /home y volverlo a crear:
    rm -R /home/user/.opera/cache
    mkdir /home/user/.opera/cache
    Para Firefox:
    Escribir about:config en la barra de navegacion.
    Botón derecho y New->String. Escribir como nombre browser.cache.disk.parent_directory y como valor /tmp/firefox-cache


    Scheduler

    Por último vamos a tratar del tema del scheduler de I/O. Nomalmente los discos tradicionales usan el scheduler CFQ, sin embargo para las memorias flash y discos de estado sólidos dan más rendimiento schedulers como noop o deadline. Hay una gran discusión sobre cual va mejor. Yo he probado los 2 y no os sé decir, actualmente tengo noop.

    Para ajustar el scheduler que queramos hay 2 opciones:
    -Cargarlo una vez arrancado el sistema, que sería hacerlo mediante el archivo /etc/rc.local (en arch y algunas otras distros), /etc/init.d/rc.local (en Debian y derivadas) añadiendo:
    echo noop > /sys/block/sda/queue/scheduler
    -O meterlo como opcion de arranque del kernel. Editando ya sea el /boot/grub/menu.lst para grub o el /etc/default/grub para grub2. El parámetro a añadir es:
    elevator=noop
    Hasta ahora lo tenía como parametro del kernel, pero he visto que arrancando así me pone a todos los discos el mismo scheduler, así que creo que voy a recurrir a la primera opción mediante rc.local, o mejor aún para que directamente arranque con noop, poner en rc.local que el resto de mis discos rígidos tengan el cfq. (Es una instrucción más que la otra opción porque tengo 2 discos duros más nera pero lo prefiero así.


    INSTALACIÓN JUNTO CON WINDOWS
    Bueno no difiere mucho, lo único que tendríamos que hacer es a la hora de hacer fdisk que la primera partición sea la de windows. Y seguir el mismo procedimiento, de empezar en el sector 2, y luego ir añadiendo los tamaños con +xG (donde x es el número de gigas), la última partición basta con darle al Enter para que coja todo el resto, o si queremos dejar algo libre simplemente indicar el tamaño para la partición. Después instalaríamos Windows en la primera partición (Windows 7 crearía 2, una para boot y una para sistema), y más tarde instalar Linux en las otras particiones con lo que grub se instalaría en el MBR como siempre.


    Bueno hasta aquí hemos llegado. Con las novedades iré actualizando esto, al igual que cuando btrfs esté maduro y estable, ya que viene preparado para SSD con una opción directa. Espero que todas las horas que me he pasado con esto durante meses por ahí os ayuden con ete tema, y os invito a que deis el salto cualitativo a este tipo de dispositivos si podeis. Ya os pondré una captura y video de arranque del sistema, carga de aplicaciones y demás cuando pueda.

    COMBATIR LA DEGRADACIÓN DE RENDIMIENTO A NIVEL DE USUARIO

    Existen varias opciones para ello, la incial consistía en realizar una imagen del sistema para despues limpiar el SSD utilizando una herramienta de borrado a bajo nivel, es un sistema bastante engorroso y actualmente existen procedimientos más cómodos para el usuario final. Eso sí, con este método se recupera completamente el rendimiento del SSD ya que se devuelve al estado original. Se pueden utilizar aplicacións como Sanitary Erase, HDDErase o DBAN.

    La famosa aplicación wiper.exe, desarrollada por OCZ y compatible con los SSD Indilinx, es una herramienta de limpieza bajo demanda bastante efectiva. Eso sí, hay que tener en cuenta algunas cosas antes de ejecutarla aunque en general es el más efectivo actualmente, y no tiene limitación de S.O. Recupera alrededor del 90% del rendimiento (el 100% solo se consigue con un borrado "sanitario" completo), pero falla bajo X64 (se debe de ejecutar desde otro S.O. o con un CD de arranque X32) y manualmente (hay gente que lo tiene programado en su Windows). También es recomendable configurar la controladora SATA en modos Legacy IDE para la ejecución, en el caso del RAID es necesario deshacerlo, de forma temporal claro. Intel también tiene una aplicación de funcionamiento similar incluida en su SSD Tool Box.

    Los métodos implementados a nivel de firmware son los comandos TRIM, y los algoritmos de GC.

    El Garbage Collection aprovecha las pausas del disco para limpiarlo. No necesita TRIM, no necesita ejecutar utilidades de limpieza, funciona en Raid, y no penaliza el rendimiento. Su único punto negativo es que desgasta más el disco que TRIM y desde luego que wiper o derivados, pero no parece que tanto como para que te dure sensiblemente menos. A mi me parece la solución más práctica de todas, mucho más que el restrictivo TRIM, que solo funciona en entornos muy determinados y penalizando el rendimiento, y mejor que tener que ejecutar aplicaciones como Wiper u otras con periodicidad. Es un desarrolo propio de OCZ, lo bueno es que el FW puede utilizarse en otros SSD Indilinx, el FW se identifica como 1.41.

    En cuanto a TRIM, actualmente casi todos los SSD tienen soporte a través de nuevos FW (Samsung es la última en incorporarse). Su funcionamiento es completamente automático, sin embargo todavía tiene dos problemas. Penaliza ligeramente el rendimiento general del SSD, y además, solo puede configurarse bajo circunstancias determinadas, a saber:

    • Placa Intel (ICH7 o superior)
    • Windows 7
    • Controladores de Microsoft (instalados por defecto por Seven). Desde la versión 9.6, los controladores Intel Rapid Storage soportar TRIM (incluso estando la controladora en modo RAID, eso sí, el SSD no puede formar parte de ningún array, es una funcionalidad drive through), además, benefician el rendimiento.
    • Modo AHCI (no vale Raid)
    • FW con soporte


    CONSIDERACIONES A NIVEL DE SISTEMA OPERATIVO WINDOWS

    Existen una serie de consideraciones a tener en cuenta cuando instalamos un SSD que dependen en gran medida del sistema operativo que esteamos utilizando. Windows 7 es el mejor sistema Microsoft para utilizar con un SSD, ya que al detectar su presencia toma una serie de medias sobre todo a nivel de servicios. Con Vista es necesario realizar esos ajustes manualmente y con XP, a mayores, hay que cambiar el align del offset ya que el que utiliza por defecto no es apropiado (para usuarios de Windows XP este hilo es muy recomendable, en el foro oficial de OCZ).

    Para Seven/Vista los servicios a tener en cuenta serían los siguientes:

    PAGINACIÓN
    DESFRAGMENTACIÓN
    PREFETCH
    SUPERFETCH
    INDEXACIÓN

    En general, lo normal es una configuración como; desfragmentación y prefetch desactivados (auto, si W7 no lo ha hecho, hazlo tú), Index Server desactivado y Superfecth en ejecución y paginación activada en el SSD.Index Server es una cuestión más de gustos.

    En cuanto al Index Server, es un servicio de indexación que organiza los datos en segundo plano para mejorar la velocidad de las búsquedas. Se puede deshabilitar/habilitar para cada una de las unidades lógicas de tu sistema (que bien pueden corresponder a HD, particiones...) es decir, puedes deshabilitarlo en el HD/SSD del sistema y tenerlo activo en otras unidades si te interesa y viceversa.

    Realmente, con prefetch (que no superfetch) si que conviene deshabilitarlo, ya que tampoco tiene mucho sentido en un SSD y es un servicio que puede llegar a ser molesto. Por cierto guarda relación con los procesos de desfragmentación, solo que de forma automatizada a través del servicio. Superfetch es diferente, ya utiliza la memoria RAM de forma predictiva para mejorar el rendimiento de las aplicaciones más utilizadas, alojando allí los datos. Es un servicio algo molesto tamibén sobre todo al inicio del sistema, sin embargo, continua siendo ventajoso respeco al SSD ya que al fin y al cabo utiliza memoria principaly esta es bastante más rápida, aunque las diferencias no son tantas como respecto a un disco mecánico. Es casi más una decisión del usuario que un consejo general.

    Sin embargo, creo que por defecto tanto prefetch como superfetch son deshabilitados cuando W7 detecta un SSD con un buen rendimiento aleatorio, aunque realmente el prefetch debería deshabilitarse en todo caso al no tener mucho sentido en un SSD.

    Yo la verdad la función Superfetch de Seven sí la dejaría, ya que al parecer está bastante mejorada y funciona bien, aunque ya lo hacía en Vista realmente. Existen muchas guías de optimiazación de sistemas Windos por la red (son muy típicas incluso en prensa escrita por que no decirlo) que insisten que deshabilitarlo es conveniente en todo caso para agilizar el sistema y ahorrar memoria principal... cuando realmente, como mínimo, no es exacto. Este link es recomendable si buscais más info.

    Para desactivar esas cosas, pasaros por aquí.

    Para Index Server, su ubicación es la siguiente:



    Sobre los controladores, actualmente la elección más adecuada serí, en función de la controladora:

    1 Intel chipset IDE mode = Intel driver

    2 Intel chipset AHCI mode = Microsoft driver

    3 Intel chipset raid mode = Intel driver

    4 AMD chipset IDE mode = Microsoft driver

    5 AMD chipset AHCI mode = Microsoft driver

    6 AMD chipset raid mode = AMD driver

    7 Nvidia chipset IDE mode = Microsoft driver

    8 Nvidia chipset AHCI mode = Microsoft driver

    9 Nvidia chipset raid mode = Nvidia driver
    Por último, el modo ACHI favorece el rendimiento de forma notable, asi que si estamos utilizando un SSD siempre es recomendable tenerlo activo. Si ya tenéis el sistema instalado, podéis hacer lo siguiente (es una modificación del registro así que tomad las debidas precauciones).

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\msahci, en Start pones el valor 0.
    Luego apagas y al reiniciar ya puedes configurar en la bios el AHCI y arrancar sin problema si el sistema cuenta ya con los controladores debidos (se asume que sí).


    MODELOS RECOMENDADOS:

    A continuación enumeramos aquellos SSD que por su diseño y características consideramos recomendables:

    A-Data 500 Plus series (Indilinx)
    Corsair P Series (Samsung)
    Corsair X Series (Indilinx)
    G SKill Falcon / Falcon II (Indilinx)
    Intel X25-M G2 (Intel)
    Kingston SSDNow M Series (Intel)
    OCZ Summit (Samsung)
    OCZ Vertex (Indilinx)
    OCZ Agility (Indilixx)
    Patriot Torqx (Indilinx)
    Samsung MMCRE (Samsung)
    Supertalent Ultradrive ME (Indilinx)
    Mushkin Europa 2 / IO (Indilinx)
    Crucial M225 (Indilinx)




    LINKS:

    PC Silencioso - SSDs: Guía básica y modelos recomendados
    SSD WORLD NET
    ANANDTECH SSD ANTHOLOGY (se recomienda encarecidamente su lectura)
    ANANDTECH: The SSD Relapse: Understanding and Choosing the Best SSD
    ANANDTECH: THE SSD IMPROV
    ANANDTECH VERTEX UPDATE (se recomienda encarecidamente su lectura)
    SSD EN ENTORNOS ENTERPRISE
    SSD EN INFRAESTRUCTURAS VMWARE
    OCZ VERTEX EN EBAY
    OCZ VERTEX FIRMWARE UPDATE
    INTEL SSD FRIMWARE UPDATE
    WINDOWS 7 Y SSD
    RAIDS Y TAMAÑOS DE STRIPE
    HERRAMIENTA DE BORRADO A BAJO NIVEL
    INTEL, SAMSUNG E INDILIX BAJO CONDICIONES DE DEGRADACIÓN EN WINDOWS VISTA
    INTEL 2º GEN SSD PREVIEW
    SSD DECODERS RING - PC PERSPECTIVE

    REVIEWS EN EL FORO NOTICIAS 3D:

    A SSD BENCHMARK (RELACIÓN DE RESULTADOS DE FOREROS DE N3D)
    VERTEX 30GB RAID0 (ROCKET)
    VERTEX 30GB RAID0 PRUEBAS CON DEGRADACIÓN Y RESTAURADO (ROCKET)
    INTEL X25-M RAID0 (MK_DIR)
    VERTEX 60GB (SALEGRE)
    VERTEX 30GB RAID0 (BLADEC)
    G. SKILL FALCON 128GB (PEPILLO)

    FOROS OFICIALES:


    OCZ SSD FORUM

    G SKILL SSD FORUM
    SUPERTALENT FORUM
    PATRIOT MEMORY FORUM



    Muchas gracias a pmonti80 por su inestimable colaboración. Gracias también a ROCKET, Pepillo, Bladec, Salegre, kmatxo, kpablo, Alex_22 y Viper_Scull (...) por sus comentarios y pruebas, asi como también a todos los foreros por su participación en este hilo.
    Última edición por mk_dir; 19/01/2010 a las 09:43

  3. #3
    Vive aquí
    Ubicación
    España
    Mensajes
    784

    Predeterminado Re: SSD's casi todo lo siempre quisiste saber y nadie supo responder (Anandtech)

    Anand dice que en unas semanas revisara el rendimiento del OCZ Summit (al tener la versión definitiva) y del OCZ Vertex (al usar el último Firmware).

  4. #4
    Con domicilio en Noticias3d.com Avatar de mk_dir
    Ubicación
    Santiago de Compostela
    Edad
    27
    Mensajes
    8,081

    Predeterminado Re: SSD's casi todo lo siempre quisiste saber y nadie supo responder (Anandtech)

    Cita Iniciado por pmonti80 Ver mensaje
    Anand dice que en unas semanas revisara el rendimiento del OCZ Summit (al tener la versión definitiva) y del OCZ Vertex (al usar el último Firmware).
    Dos de los modelos más interesantes hoy día sin duda.
    Sin embargo ahora una de las cuestiones que más empezarán a sonar es que sí Windows 7 soportará TRIM (como parece que va a ser, cumpliéndose esos rumores de sistema SSD friendly) los actuales dispositivos podrán recivir un update para soporarlo, en el artículo se sugiere que sería posible). Yo me quedo con esa duda.

    Saludos

  5. #5
    Vive aquí
    Ubicación
    España
    Mensajes
    784

    Predeterminado Re: SSD's casi todo lo siempre quisiste saber y nadie supo responder (Anandtech)

    Cita Iniciado por mk_dir Ver mensaje
    Dos de los modelos más interesantes hoy día sin duda.
    Sin embargo ahora una de las cuestiones que más empezarán a sonar es que sí Windows 7 soportará TRIM (como parece que va a ser, cumpliéndose esos rumores de sistema SSD friendly) los actuales dispositivos podrán recivir un update para soporarlo, en el artículo se sugiere que sería posible). Yo me quedo con esa duda.

    Saludos
    Supongo que todo depende de la voluntad de las compañias. Yo por defecto soy muy desconfiado en estas cosas, así que excepto contadas excepciones juraría que pocos soportarán la actualización.

  6. #6
    Con domicilio en Noticias3d.com Avatar de mk_dir
    Ubicación
    Santiago de Compostela
    Edad
    27
    Mensajes
    8,081

    Predeterminado Re: SSD's casi todo lo siempre quisiste saber y nadie supo responder (Anandtech)

    Siendo tan interesante de cara sobre todo a la degradación de rendimiento (aunque también cumple otras funciones, implanta un algoritmo de borrado más efectivo) yo quiero pensar que tendrán en cuenta los SSD que hay ahora en el mercado. Con los X25-M en el punto de mira... Yo por el que sí apostaría sería por el Vertex, de hecho ya está sufriendo mejoras con nuevos firmwares más depurados hoy día.

    Saludos

  7. #7

    Predeterminado Re: SSD's casi todo lo siempre quisiste saber y nadie supo responder (Anandtech)

    mk_dir: Hace unos días comentaste sobre el cambio de firmware de los vertex, y que conllevaba un aumento muy significativo del rendimiento.
    Bien, después de leer el artículo de Anandtech he creído entender que sus últimas pruebas a los vertex eran sin este firmware nuevo que comentaste y que ya deben incorporarlo las unidades que están a la venta. ¿es así?
    De todas maneras, veo que para sortear el problema principal deberemos evitar cualquier escritura en el SSD; supongo que así no tendremos esa afectación de "reescritura".

    Saludos.

  8. #8
    Con domicilio en Noticias3d.com Avatar de mk_dir
    Ubicación
    Santiago de Compostela
    Edad
    27
    Mensajes
    8,081

    Predeterminado Re: SSD's casi todo lo siempre quisiste saber y nadie supo responder (Anandtech)

    Creo que no utilizan la última versión, la FW 1275, que según creo todavía esta en fase prerelease aun que ya se le han hecho pruebas. Desde luego si hay una compañía comprometida con el desarrollo de los SSD esa es OCZ...

    Saludos

  9. #9

    Predeterminado Re: SSD's casi todo lo siempre quisiste saber y nadie supo responder (Anandtech)

    Lo que mas me preocupa por el momento, con vistas a comprar uno en breve es el asunto del slowdown.

    En los vertex, aún con los nuevos firms y al margen de la mejora de rendimiento, no creo que se solucione, porque parece que es un problema estructural común en todos los SSD y que tendrán pulir.

    Para mí un defecto muy grave como para considerarlos una alternativa por el momento. Lástima habrá que esperar unos meses.

  10. #10

    Predeterminado Re: SSD's casi todo lo siempre quisiste saber y nadie supo responder (Anandtech)

    Bueno, la cuestion es que para el que necesite transferencias de una manera profesional y frecuente es evidente que no es la panacea; yo le recomendaría en ese caso otro tipo de soluciones. Ahora, las transferencias que solemos usar la gran mayoría (incluyendo incluso la edición de video) las podemos cubrir con discos mecánicos.
    Me da la impresión de que cuando se habla (en este u otros foros) de los SSD el entendimiento general es "quitar mi disco mecánico y poner un SSD" y, bueno, ojala llegue el día, pero aquellos que tenemos decidida la compra de una unidad SSD no tenemos ni por asomo la idea de la substitución (al menos hasta que lleguen soluciones definitivas al único handicap de estas unidades) sino de aumentar la velocidad del sistema y aplicaciones, o sea, accesos a disco(lecturas), y en eso son absolutamente imbatibles.
    Yo tengo 2 discos samsung de 1Tera y no voy a substituirlos por un Vertex, pero si voy a sacar el sistema y aplicaciones y los voy a meter en él.
    Hace 2 meses tenía la idea de comprar un velociraptor, ya no; para mi (ojo, para mi) sería tirar el dinero.

Página 1 de 858 123451151101501 ... ÚltimoÚltimo

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •