ZONA DE PRUEBAS

Acabo de comprar (por rellenar un pedido) una serie de aparatos USB 3.0, como un adaptador de disco duro y un lector de tarjetas. Me gustaría compararlos con el hardware que ya tengo para ver si hay una diferencia de rendimiento apreciable.

El tema es que el equipo que tengo tiene 8 Gb, y me da en la nariz que las cachés de Linux y de Windows van a falsear bastante los resultados. ¿Hay alguna forma de hacer una prueba de este tipo sin que las cachés intervengan?

No usando el sistema de ficheros, sino leyendo o escribiendo directamente al dispositivo de bloques. En lectura, haz lecturas a posiciones de bloque aleatorias, no secuenciales, ya que las últimas aprovechan precisamente la secuencialidad para cargar de caché el siguiente bloque.

De todas formas los resultados que obtengas siempre tendrán alguna incertidumbre, ya que precisamente al cachearse el acceso a los siguientes bloques, al hacer una lectura desde el software, no puedes estar seguro de que se esté haciendo sólo una lectura a nivel hardware. Aquí la solución consiste en mirar si en los IOCTL's del dispositivo de bloques en particular al que estás accediendo existe alguno que deshabilite por completo la caché.

Por supuesto hablo de Linux. En Windows también existen los mismos conceptos y mecanismos, no obstante.

Lo más sencillo, probablemente, es que uses algún programa de benchmarking de discos duros que ya tiene en cuenta todas estas cosas.

No entiendo el razonamiento de la cache en accesos secuenciales... si accedes una única vez a cada posición secuencialmente, la caché no debería tener ningún dato de esas posiciones ya que cada acceso se está realizando por primera vez, aunque sea un bloque completo. En una acceso aleatorio sí que puede acelerar porque puede haber leido ese bloque con anterioridad y estar cacheado.

Yo siempre uso dd para probar la velocidad secuencial de un dispositivo, por ejemplo con un dd if=/dev/sdX of=/dev/null bs=256M count=4 transfieres el primer GB de la unidad secuencialmente. Como prueba rápida me sirve

DistWave escribió:No entiendo el razonamiento de la cache en accesos secuenciales... si accedes una única vez a cada posición secuencialmente, la caché no debería tener ningún dato de esas posiciones ya que cada acceso se está realizando por primera vez, aunque sea un bloque completo. En una acceso aleatorio sí que puede acelerar porque puede haber leido ese bloque con anterioridad y estar cacheado.

Si accedes al disco de forma secuencial, el primer bloque lo lees efectivamente gastando el tiempo que se tarda en leer fisicamente el bloque, pero el hardware del disco duro aprovecha esa lectura para guardar en caché propia los bloques que siguen a continuación, ya que cuesta muy poco leerlos (el cabezal del disco duro ya está en la pista adecuada) y por el principio de localidad referencial, es muy probable que si se ha leído un bloque, a continuación quiera leerse el que le sigue a continuación.

Esa misma filosofía se sigue en las cachés del sistema, ya que pedir los datos de los bloques que están a continuación de aquél que hemos leido cuesta muy poco.

Asi que cuando lees, pongamos, 8 bloques secuenciales, puede pasar que el primero realmente lo leas gastando el tiempo de acceso al disco, pero los 7 restantes los estés leyendo de la caché. De ahí que una lectura secuencial no sea, por lo general, la mejor forma de medir el rendimiento de un disco duro mecánico. De hecho la lectura secuencial se usa para averiguar el máximo throughput del disco, porque se sabe que es cuando el sistema disco-caché-cable SATA funcionan con el máximo de transferencia. Es lo que aparece en los programas de benchmarking como "lectura burst" o "lectura por ráfaga". Fíjate que esto de acelerar los accesos secuenciales se usa incluso en la memoria del sistema, que trabaja más rápido si se accede a ella secuencialmente.

En un acceso aleatorio (si es exhaustivo) la caché nunca o casi nunca tendrá el dato cacheado de antes, ya que la caché es muchas veces menor en tamaño que el disco que pretendes medir y en un acceso aleatorio exhaustivo nunca se pide leer la misma dirección de bloque durante el benchmark sino que son todas diferentes.

El tema es que a veces dd hace cosas raras (sobre todo al escribir en USB). He visto casos en los que hace la lectura en RAM y vuelve a línea de comandos antes de completar la escritura, falseando las estadísticas.

Ahora que lo pienso, una solución cutre sería usar un script con dd y sync para medir el tiempo.