CS de rendimiento de almacenamiento
Esta prueba comprueba que el rendimiento del dispositivo de almacenamiento cumple los requisitos de rendimiento.
Detalles de las pruebas
| Especificaciones |
|
| Plataformas |
|
| Versiones admitidas |
|
| Tiempo de ejecución esperado (en minutos) | 240 |
| Categoría | Prueba comparativa |
| Tiempo de espera (en minutos) | 14400 |
| Requiere reinicio | false |
| Requiere una configuración especial | false |
| Tipo | automatic |
Documentación adicional
Las pruebas de esta área de características pueden tener documentación adicional, incluidos los requisitos previos, la configuración y la información de solución de problemas, que se pueden encontrar en los temas siguientes:
Ejecución de la prueba
El dispositivo de almacenamiento debe estar conectado al controlador adecuado. La prueba no es destructiva, por lo que no se destruirán archivos ni particiones durante las pruebas. Sin embargo, los archivos se escribirán en la unidad. Es importante minimizar la cantidad de actividad que se produce en la unidad fuera de la prueba del logotipo. Dado que se trata de una prueba de rendimiento, la actividad externa puede afectar a los resultados.
Solución de problemas
Para solucionar problemas genéricos de errores de prueba de HLK, consulte Solución de problemas de errores de prueba de HLK de Windows.
Comprobar seguimiento de WTT:
Vaya a los resultados del trabajo secundario de RunJob - Biblioteca de rendimiento de almacenamiento.
Vea el registro de tareas de ejecución de StorPerf.
Abra el archivo de registro StorPerf.wtl.
Compruebe si hay mensajes que puedan resolver el problema.
Error de tamaño del intervalo:
Mensaje de error: "El tamaño del intervalo solicitado, 10737418240 bytes, es mayor que el archivo de condición previa, 7195066368 bytes. Prueba de logotipo invalidada."
Si el tamaño del intervalo solicitado es mayor que el archivo de condición previa, se registrará un error, pero la prueba continuará ejecutándose. El archivo testzone.tmp creado es demasiado pequeño para probar suficientemente el intervalo requerido por la prueba.
Se debe crear más espacio para crear este archivo o el archivo era demasiado pequeño y no se eliminó correctamente antes de comenzar las pruebas.
Actualmente, el tamaño mínimo del archivo de condición previa requerido es de 10 Gb. El 20 % de espacio libre también debe dejarse en la unidad. La fase de condición previa escribe un archivo que rellena todo el espacio libre dejando el 20 % del espacio libre total en la unidad.
Tamaño total del disco * 20 % + 10 GB < de espacio libre
Compruebe los resultados de las pruebas individuales:
Examine los registros de trabajo del rendimiento de almacenamiento CS/Rendimiento de almacenamiento USB3.
Hay varios tipos de archivos para cada caso de prueba que se ejecuta dentro de la prueba que se copian de nuevo en el controlador para evaluar la evaluación de prioridades. Estos archivos contienen más información de la que está disponible en los registros de WTT.
Los archivos .result son la salida de la consola de cada proceso que se inicia desde esta prueba.
La carga de trabajo que realiza esta prueba genera los archivos .xml. Es lo que se analiza para obtener las métricas.
El archivo .csv es el agregado de todos los datos analizados para cada caso de prueba.
El archivo .xls es el mismo agregado que el archivo .csv del mismo nombre, excepto que tiene un paso o error codificados en color junto con lo que era el valor de la barra de métricas esperada.
La nomenclatura de los archivos .result y .xml identifica de forma única la ejecución del caso de prueba.
Scen = Escenario.
La cadena hexadecimal larga identifica todos los parámetros pasados a la carga de trabajo.
La cadena hexadecimal de tres dígitos es el identificador del subproceso.
Los últimos dígitos son las ejecuciones de este mismo caso de prueba exactamente en la misma carga de trabajo.
Si se produce un error en el registro, el primer lugar para comprobar es el archivo .result del mismo nombre que el caso de prueba donde se produjo el error. Cuando se produce un error en la carga de trabajo, el archivo .result se copia en el archivo de registro .wtl para facilitar el acceso al contenido.
Si no puede abrir un identificador en el disco, es posible que no tenga una partición en la unidad o que no se esté ejecutando como administrador.
Si hay una discrepancia sobre la métrica, los valores se encuentran en el archivo .xml
Si hay una discrepancia sobre la varianza o las interacciones de casos de prueba, los archivos /.csv/.xls muestran los resultados de todas las pruebas.
Problemas con los registros ETW abiertos:
Si la prueba se cierra durante la ejecución, es posible que un registro ETW permanezca activo.
La manera más fácil de restablecer es reiniciar el equipo.
El registrador también se puede cerrar manualmente:
Abra un símbolo del sistema con privilegios elevados.
Ejecución de la consulta logman -ets
Ejecutar logman stop -ets "Circular BitLocker Logger"
Para obtener más información de solución de problemas, consulte Solución de problemas de Device.Storage Testing.
Más información
El trabajo toma el identificador de instancia de dispositivo del dispositivo en prueba y convierte el identificador de instancia del dispositivo en un número de unidad física o letra de unidad según el escenario. Si es necesario en el escenario, el trabajo crea particiones y da formato a la unidad para obtenerla en la configuración necesaria para las pruebas. La prueba se ejecutará a través de una serie de casos de prueba asignados a los elementos de los requisitos. Los casos de prueba son independientes y se ejecutan secuencialmente. Se puede obtener una lista de casos de prueba mediante la opción de línea de comandos PrintPolicy con el dispositivo adecuado especificado. Cada uno de estos casos de prueba se puede ejecutar en la línea de comandos mediante la prueba en modo independiente con un archivo xml de directiva personalizada mediante la opción de línea de comandos PolicyXML para realizar pruebas o depuraciones adicionales.
La prueba de rendimiento de almacenamiento almacena una tabla de directivas que define para cada tipo de dispositivo qué pruebas de rendimiento se van a ejecutar y cuáles deben ser las métricas adecuadas. Una vez seleccionados los elementos adecuados de la tabla, la prueba generará secuencialmente instancias de la carga de trabajo especificada, StorageAssessment, en este caso, para probar los elementos especificados en la tabla para ese dispositivo. Una vez que StorageAssessment ha terminado de realizar sus pruebas y ha creado los resultados, la prueba de rendimiento de Storage analizará esos valores y los comparará con las barras definidas en los requisitos del logotipo para imprimir los registros de paso y error.
La marca DeviceTag hace referencia al escenario que se va a probar en la línea de comandos. Esta marca es testcaseGroup en el xml de la directiva. La prueba tiene algunos escenarios integrados, pero permite escenarios personalizados, si lo desea.
Un escenario se define mediante un orden, carga de trabajo, acceso, operación, valor de operación, tamaño de E/S, tamaño de intervalo, tiempo de ejecución, profundidad de cola, porcentaje de condición previa y MB de condición previa. Cada escenario definido en la tabla se corresponderá con la carga de trabajo que se genera una vez. Varios de los mismos escenarios definidos para un dispositivo solo invocarán un caso de prueba.
Una métrica se define por su tipo y valor. Intrínseco a la métrica es sus unidades y si la barra es un límite superior o inferior. Se pueden especificar muchas métricas para cada escenario, lo que hace que solo se invoque un caso de prueba para ese escenario.
Para cada entrada de la tabla hay un criterio de varianza especificado que define la varianza máxima permitida en el último conjunto de ejecuciones antes de detener las pruebas de ese caso de prueba. Para muchas de las entradas, se define como mínimo 5 ejecuciones, un máximo de 30 ejecuciones y la varianza de las últimas 5 ejecuciones debe estar por debajo del 10 % para continuar las pruebas. El caso de prueba se volverá a ejecutar hasta 30 veces o hasta que se cumpla el requisito de varianza. En ese momento, la métrica se evaluará según las propiedades definidas de la métrica (mínimo, máximo, promedio, promedio, etc.) durante el último conjunto de ejecuciones.
Aunque la prueba de rendimiento de almacenamiento no está limitada a una carga de trabajo, la mayoría de los escenarios definidos en la tabla de directivas usan la carga de trabajo StorageAssessment para generar la carga de trabajo de rendimiento y las métricas.
Uso de comandos
| Comando | Descripción |
|---|---|
StorPerf.exe /DriveLetter [StorageDriveLetter] /DeviceTag CS_Boot |
Ejecuta las pruebas de CS en la unidad especificada. DeviceTag también puede ser CS_Boot_HS200 para unidades compatibles con HS200. |
Sintaxis de comandos
| Opción de comando | Descripción |
|---|---|
<Número de unidad> |
Número de unidad física del dispositivo sometido a prueba. Ejemplo: /DriveNumber 0 |
/DriveLetter <letter> |
Letra de unidad del dispositivo sometido a prueba. Ejemplo: /DriveLetter C |
Valor /DeviceTag <> |
Identifica qué TestcaseGroup o ComparisonGroup se van a seleccionar como entrada de los archivos xml de configuración. Este parámetro distingue mayúsculas de minúsculas y se usa para indexar los archivos xml de directiva y comparación. Ejemplo: CS_Boot /DeviceTag |
Valor /PolicyXML <> |
Nombre del archivo xml de la directiva. Define todos los parámetros para ejecutar las cargas de trabajo de E/S. Si no se proporciona ninguna opción, se generará el archivo predeterminado. Ejemplo: /PolicyXML CSPolicy.xml |
/Compare <value value><> |
Los dos archivos xml que se van a comparar. Estos deben haberse generado a partir de una ejecución anterior de esta prueba. Los archivos "FinalTestCasesAggregated*.xml" deben usarse en lugar de los archivos "AllTestCasesAggregated*.xml", ya que no hay ninguna garantía de que el número de iteraciones sea el mismo para cada caso de prueba. Ejemplo: /Compare FinalTestCasesAggregated_42f4.xml FinalTestCasesAggregated_a732.xml |
/CompareXML <value> |
Nombre del archivo xml de comparación. Define todos los parámetros para ejecutar la comparación. Si no se proporciona ninguna opción, se generará el archivo predeterminado. Ejemplo: /CompareXML CSCompare.xml |
/PrintPolicy |
Imprime la tabla de directivas. |
Nota
Para obtener ayuda de la línea de comandos para este binario de prueba, escriba /h.
Lista de archivos
| Archivo | Ubicación |
|---|---|
StorPerf.exe |
<[testbinroot]>\NTTest\driverstest\storage\wdk\ |
StorageAssessment.exe |
<[testbinroot]>\NTTest\driverstest\storage\wdk\StorageAssessment\ |
ssdtest.dat |
<[testbinroot]>\NTTest\driverstest\storage\wdk\StorageAssessment\ |
Parámetros
| Nombre de parámetro | Descripción de los parámetros |
|---|---|
| LLU_NetAccessOnly | Cuenta de usuario para acceder al recurso compartido de archivos de prueba. |
| LLU_LclAdminUsr | Cuenta de usuario para ejecutar la prueba. |
| WDKDeviceID | Ruta de acceso de instancia del dispositivo que se va a probar. |
| Deviceid | DriveLetter o DriveNumber |
| DeviceTag | |
| DiskDeviceObjLink | Asignado por Crear parámetros de almacenamiento. |
| Destructivo | (0,1) 0=Pasivo, 1=Destructiva |
| QueryHS200 | Consultas si algún dispositivo admite el modo HS200 |