Clase del día 4 de marzo, de nuevo dejo aquí mis apuntes completos. Haré un anexo (una nueva entrada, vamos) para aclarar lo que comenté en clase con el profesor y con Antares y algunas cosillas más.
Comenzamos recordando un poco lo que hicimos en la última clase: Las 10 reglas/pasos para la evaluación/configuración de un sistema, La importancia de la comparación hacia un objetivo…
Hablamos de frames por segundo en aplicaciones 3D (en juegos más que nada), lo personal que puede llegar a ser a la hora de estar jugando, también la importancia del lag de la red si jugamos por internet, etc.
Hablamos de las métricas para evaluar una conexión de Internet: Latencia, ancho de banda…
El profesor comenta que una diferencia entre redes por cable ethernet y redes wifi es que las primeras tienen más ancho de banda y peor latencia y las wifi tienen lo contrario: mejor latencia, menos ancho de banda.
Para cada petición que se haga a un sistema (local o remotamente) hay tres tipos de respuesta posible:
- Que se conecte correctamente
- Que se conecte incorrectamente
- Que no se pueda conectar
En caso de que se realicen correctamente, se medirán ahora las siguientes tasas:
Tasa de responsividad (Por ejemplo para un gateway, sería el tiempo de respuesta)
Tasa de productividad (Igualmente para un gateway, el número de paquetes que procesa por segundo)
Tasa de utilización ( Igualmente, sería esta vez los recursos utilizados por tiempo)
La fiabilidad y disponibilidad de un sistema suele medirse en unidades de MTBF (mean time between failures, tiempo medio entre fallos).
La disponibilidad se mide en porcentaje del tiempo que está disponible.
Se habla de número de 9s, (es decir, 9%, 99%, 99,9%, 99,99%, 99,999%, etc) pero no es el tipo de cosas que vamos a tratar en nuestro trabajo final. (No trataremos de fiabilidades de 99,9999999% sino de bastante menos (relativamente)).
Hablamos de medir tasas de frames por segundo según el tipo de juego. Me permito la libertad de corregir a JJ cuando comenta que debemos medir con distintos tipos de juego, porque no se trata de eso, sino de medirlo con motores gráficos de distintas características. Por supuesto que usar juegos de distinto tipo puede solucionar eso, pero hay juegos de distinto tipo que comparten el mismo motor gráfico. Esto lo trataré en la nueva entrada.
Las métricas de prestaciones se suelen clasificar de la forma siguiente:
Cuando medimos una característica, puede haber tres posibilidades:
+ Más alto es mejor. Ejemplo: velocidad de un sistema.
+ Menos es mejor. Ejemplo: latencias.
+ Nominal es mejor. Estaría a medias entre los 2 anteriores, porque utilización baja puede significar infrautilización, o utilización alta: los tiempos de respuesta son altos.
Un Ejemplo sería con el caso del compilador que comentamos en la clase pasada.
El tiempo de compilación sería de tipo “menos es mejor”, mientras que el tamaño del ejecutable sería “nominal es mejor”.
Ojo, repetimos: Confundir las cosas que hay que medir con las características de lo que medimos -> golpe de remo
Hablamos de las técnicas más habituales usadas para evaluar un sistema, que son las siguientes:
La medición (tomar medidas directamente sobre el sistema en el que uno está interesado)
La modelación (para cuando se evalúa un sistema incompleto o aún sin construir)
La simulación (se usa antes de construir el sistema)
No es lo mismo un sistema que está todo el rato con
Las mediciones de rendimiento del sistema las vamos a hacer con programas que llamamos monitores. Programa monitor típico, el que te muestra los procesos que se están ejecutando. (Task Manager de Windows por ejemplo)
Nota: Vamos a medir sistemas en general, una de las cosas que incluye el sistema son programas, así que también mediremos programas.
Acabamos la clase viendo un vídeo de un programa monitor en Windows (perfmon.msc)
No hay comentarios:
Publicar un comentario