Empezamos la clase comentando los errores de la quinta practica:
- Hay que plantear objetivos reales, con cargas de trabajo reales.
Ejemplo: El tiempo que tarda en arrancar el SO no es una carga real.
- Los objetivos no pueden ser sobre la tasa de uso de un componente (memoria, CPU)
- Las pruebas se diseñan en funcion del objetivo.
- El objetivo tampoco es bajarse algun programa que optimize el sistema por nosotros.
Ahora vemos un ejemplo de una buena practica de un compañero.
El ha planteado como objetivo el servir el maximo nº posible de paginas por segundo con un servidor apache.
Practica de Fran Torres
Surgen varios comentarios a raiz de esta practica, ya que en realidad lo que ha hecho es comparar 2 sistemas y ver cual de ellos es mas apropiado para su tarea.
Vemos a continuacion las notas de clase de Sara (recordemos que en la clase anterior se explico la practica 6 y el trabajo final).
Ahora pasamos a ver un ejercicio de autoevaluacion de davis87
Una pagina curiosa: http://www.geek.com/the-x86-evolution-will-lead-the-revolution/
Seguimos con el temario...
4.2 Utilización de un benchmark
Empieza el profesor aclarando la diferencia entre monitor y benchmark: el monitor muestra la carga real del sistema y el benchmark aplica una carga a tal sistema y hace mediciones en relacion a el.
4.2.1 ¿Quién propone un benchmark?
Para difundir los benchmarks hay 2 alternativas:
- Que sean evaluados por una empresa externa, al a que se le paga por ella.
- Que los benchmarks sean propuestos por un conjunto de empresas o instituciones que acepten los resultados que arrojen.
4.2.2 Tipos de benchmarks
La clasificacion se hace en funcion de la representacion de la carga de trabajo:
- Programas reales: Realizan una carga de trabajo real.
- Núcleos o kernel: Representan las operaciones fundamentales de una carga de trabajo.
- Benchmarks de juguete: Miden parámeros básicos, como los megahercios o la latencia de la memoria.
- Sintéticos: Operación estadística que mide la carga de trabajo usada con una serie de programas y resume la carga.
4.2.4 Errores comunes
- Representar solo la carga media: No se representan los tipos de carga.
- Ignorar la distribución desigual de las peticiones de dispositivos
- No controlar el nivel de carga
- Ignorar los excesos de la cache: Es importante, dado el nº de caches que tienen los sistemas hoy en dia. El tamaño de la caché influira por tanto en los resultados.
- Ignorar el overhead del monitor
- No validar las medidas
- No asegurarse de las mismas condiciones iniciales: Si estamos probando 2 ordenadores, tienen que estar en las mismas condiciones y con la misma configuracion.
- No medir las prestaciones del transitorio
- Utilizar los porcentajes de uso de los dispositivos para comparar prestaciones: MUY IMPORTANTE PARA EL TRABAJO FINAL
- Recoger demasiados datos con muy poco análisis
4.2.5 Juegos de benchmarking
- Usar configuraciones diferentes para ejecutar la misma carga de trabajo
- Elegir las especificaciones de forma que favorezcan a una máquina determinada
- Usar una secuencia de trabajos sincronizada, de forma que el solapamiento entre el trabajo de la CPU y del subsistema de E/S produzcan mejores prestaciones
- Elegir una carga de trabajo arbitraria, que puede dar buenas prestaciones para una máquina determinada
- Usar benchmarks demasiado pequeños
- Proyectar o interpolar resultados de un benchmark, es decir, medir las prestaciones de un ordenador con un procesador determinado, y proyectar los resultados a otro ordenador con un número de procesadores diferente
- Elegir el sistema base de normalización de forma arbitraria
Video del dia: Temperatura y benchmarking
martes, 13 de mayo de 2008
martes, 22 de abril de 2008
Apuntes de clase 22/04/08
Comenzamos la clase comentando los fallos de la practica 4, que por lo general tiene un nivel mas bajo que las prácticas anteriores. Algunos de los fallos mas comunes son:
- Lo del nombre y el e-mail era solo para la primera práctica
- Demasiados pantallazos y nada de análisis: hay que hacer medias y representarlas
- Algunos miden cantidades irrelevantes: bytes/s (en un programa de red), paginación (en un programa que lee/escribe en disco), swap (en un sistema sin problemas debería ser 0)
- No se pone el objetivo, o se hace algo diferente a lo que se dice en el objetivo
- Se aplican cargas de trabajo que hacen bastante uso de la tarjeta gráfica pero sin embargo no se monitoriza
- Faltas de ortografía
- Errores de representación de las gráficas
*Como capturar gráficas (excel u openoffice): En vez de capturar pantalla, se le da a exportar y se selecciona la carpeta donde exportar el gráfico. Lo exportamos como html y ya tenemos el gráfico. También es posible con openoffice guardar el archivo como ods y descomprimirlo después (Yo directamente le he dado a ctrl+c con excel y me ha funcionado...)
Vemos como ejemplo de práctica la de nuestro compañero tupakamaru. El objetivo esta bien definido. La gráfica tiene varios defectos, como que por ejemplo no compara los resultados magnitud a magnitud sino que tiene barra con magnitudes diferentes juntas. Otro fallo es que en el eje x no indica cual es el sistema 1 y el sistema 2. Con estas gráficas no podemos detectar con certeza si el sistema falla o no, sobre todo con el uso del HD, ya que esa magnitud medida es algo ambigua.
Vemos ahora un ejercicio de autoevaluacion del blog aullidosdigitales.
Ejercicio de autoevaluación 3.1
Seguimos viendo algunos ejercicios del compañero Alejandro Peña Lorenzo, aunque no los comentamos.
Seguimos ahora con el temario...
3.4 Mejora de prestaciones de la CPU
Para mejorar la CPU, hay que seguir los siguientes pasos:
- Cambiar el setup de la BIOS de forma que la CPU vaya más rápida, en un pequeño incremento.
- Cambiar en el setup también la velocidad del bus del sistema, para que se empareje con la velocidad de la CPU. Ambas velocidades son submúltiplos de la velocidad del reloj del sistema, que, en general, es el doble de la velocidad del procesador.
- Si es posible, cambiar el voltaje al que funciona la CPU, en alguna pequeña cantidad, tratando de disminuirlo, siempre dentro de los límites de tolerancia de los componentes. Algunas placas madre, tales como las Abit (http://www.abit.com.tw) lo permiten.
- También es conveniente añadir un ventilador para el procesador solo (o cambiar el que hay por otro más potente), para evitar que se caliente demasiado.
- Si no se queda colgado, probar algún benchmark sobre el nuevo sistema, a ver qué incremento de velocidad se ha conseguido.
- Volver al principio, a intentar conseguir velocidades superiores.
En el caso de los sistemas multiprocesador, los dos procesadores deben acceder a memoria, para lo que tienen lo que se conoce como mutexes, que son objetos de exclusion mutua. Es decir, si un procesador esta trabajando en una zona de la memoria, este elemento impide la entrada del otro procesador a esa zona.Si uno de los procesadores no da el rendimiento esperado, puede que sea culpa de los mutexes. Para linux se puede utilizar un monitor que se conoce como mpstat, disponible dentro del paquete systat.
3.5 Sintonización de la memoria
Las dos tareas principales de la memoria son la paginacion y el intercambio(swapping). Para ver como funciona swap, el profesor ejecuta un programa. Una vez que se llena la memoria física, se empieza a utilizar la memoria swap almacenando los programas que no tienen espacio hasta que haya mas memoria física libre.Para evitar problemas con la memoria física podemos hacer lo siguiente:
- Limitar el tamaño de los procesos
- Usar librerías compartidas: Las librerias estáticas son las que se crean cuando se compila un programa, mientras las librerias dinámicas son aquellas que son compartidas por varios programas
- Modificar el algoritmo de paginación (aunque es bastante arriesgado). El parámetro mas relevante swappiness, que establece la tendencia del kernel a la hora de hacer swapping (cuanto mas alto este el valor, mas pronto realizará swapping)
- Cambiar el tamaño de la partición de swap
- Usar herramientas de gestión de prioridad por proceso
Algunos enlaces interesantes sobre el tema:
Wiki bandaancha.st
Guia de tuning para linux
Red Paper sobre el mismo tema (pdf)
3.6 Mejora de prestaciones en entrada/salida
Es bastante complicado mejorar las prestaciones de E/S ya que en estas operaciones intervienen multitud de dispositivos.Centrandonos en los discos duros, la eficiencia de estos sistemas estará en tres factores diferentes: throughput por proceso, throughput total, y eficiencia en el almacenamiento.
Por hoy ya dejamos el temario,y como siempre para finalizar...
Video del dia: comparativa DD/SSD
- Lo del nombre y el e-mail era solo para la primera práctica
- Demasiados pantallazos y nada de análisis: hay que hacer medias y representarlas
- Algunos miden cantidades irrelevantes: bytes/s (en un programa de red), paginación (en un programa que lee/escribe en disco), swap (en un sistema sin problemas debería ser 0)
- No se pone el objetivo, o se hace algo diferente a lo que se dice en el objetivo
- Se aplican cargas de trabajo que hacen bastante uso de la tarjeta gráfica pero sin embargo no se monitoriza
- Faltas de ortografía
- Errores de representación de las gráficas
*Como capturar gráficas (excel u openoffice): En vez de capturar pantalla, se le da a exportar y se selecciona la carpeta donde exportar el gráfico. Lo exportamos como html y ya tenemos el gráfico. También es posible con openoffice guardar el archivo como ods y descomprimirlo después (Yo directamente le he dado a ctrl+c con excel y me ha funcionado...)
Vemos como ejemplo de práctica la de nuestro compañero tupakamaru. El objetivo esta bien definido. La gráfica tiene varios defectos, como que por ejemplo no compara los resultados magnitud a magnitud sino que tiene barra con magnitudes diferentes juntas. Otro fallo es que en el eje x no indica cual es el sistema 1 y el sistema 2. Con estas gráficas no podemos detectar con certeza si el sistema falla o no, sobre todo con el uso del HD, ya que esa magnitud medida es algo ambigua.
Vemos ahora un ejercicio de autoevaluacion del blog aullidosdigitales.
Ejercicio de autoevaluación 3.1
Seguimos viendo algunos ejercicios del compañero Alejandro Peña Lorenzo, aunque no los comentamos.
Seguimos ahora con el temario...
3.4 Mejora de prestaciones de la CPU
Para mejorar la CPU, hay que seguir los siguientes pasos:
- Cambiar el setup de la BIOS de forma que la CPU vaya más rápida, en un pequeño incremento.
- Cambiar en el setup también la velocidad del bus del sistema, para que se empareje con la velocidad de la CPU. Ambas velocidades son submúltiplos de la velocidad del reloj del sistema, que, en general, es el doble de la velocidad del procesador.
- Si es posible, cambiar el voltaje al que funciona la CPU, en alguna pequeña cantidad, tratando de disminuirlo, siempre dentro de los límites de tolerancia de los componentes. Algunas placas madre, tales como las Abit (http://www.abit.com.tw) lo permiten.
- También es conveniente añadir un ventilador para el procesador solo (o cambiar el que hay por otro más potente), para evitar que se caliente demasiado.
- Si no se queda colgado, probar algún benchmark sobre el nuevo sistema, a ver qué incremento de velocidad se ha conseguido.
- Volver al principio, a intentar conseguir velocidades superiores.
En el caso de los sistemas multiprocesador, los dos procesadores deben acceder a memoria, para lo que tienen lo que se conoce como mutexes, que son objetos de exclusion mutua. Es decir, si un procesador esta trabajando en una zona de la memoria, este elemento impide la entrada del otro procesador a esa zona.Si uno de los procesadores no da el rendimiento esperado, puede que sea culpa de los mutexes. Para linux se puede utilizar un monitor que se conoce como mpstat, disponible dentro del paquete systat.
3.5 Sintonización de la memoria
Las dos tareas principales de la memoria son la paginacion y el intercambio(swapping). Para ver como funciona swap, el profesor ejecuta un programa. Una vez que se llena la memoria física, se empieza a utilizar la memoria swap almacenando los programas que no tienen espacio hasta que haya mas memoria física libre.Para evitar problemas con la memoria física podemos hacer lo siguiente:
- Limitar el tamaño de los procesos
- Usar librerías compartidas: Las librerias estáticas son las que se crean cuando se compila un programa, mientras las librerias dinámicas son aquellas que son compartidas por varios programas
- Modificar el algoritmo de paginación (aunque es bastante arriesgado). El parámetro mas relevante swappiness, que establece la tendencia del kernel a la hora de hacer swapping (cuanto mas alto este el valor, mas pronto realizará swapping)
- Cambiar el tamaño de la partición de swap
- Usar herramientas de gestión de prioridad por proceso
Algunos enlaces interesantes sobre el tema:
Wiki bandaancha.st
Guia de tuning para linux
Red Paper sobre el mismo tema (pdf)
3.6 Mejora de prestaciones en entrada/salida
Es bastante complicado mejorar las prestaciones de E/S ya que en estas operaciones intervienen multitud de dispositivos.Centrandonos en los discos duros, la eficiencia de estos sistemas estará en tres factores diferentes: throughput por proceso, throughput total, y eficiencia en el almacenamiento.
Por hoy ya dejamos el temario,y como siempre para finalizar...
Video del dia: comparativa DD/SSD
jueves, 17 de abril de 2008
¡Mamá salgo en la tele!
Ayer salió en el programa Camara Abierta 2.0 el reportaje que nos hicieron sobre el método con el que damos clase en la asignatura.No sé si el método sera tan innovador como dicen (supongo que sí) pero lo que si ha quedado patente es mi innata naturalidad con la camara, donde interpreto el papel de alumno de forma magistral (un Oscar ya, por favor). También sale este blog asi como el que no quiere la cosa, o mas bien sale mi tortuga ninja.
Para descargaros el video, un amigo mio de teleco lo ha subido a internet (por cierto él sale en el video, es uno de los que hacen el vago al final)
link
Para descargaros el video, un amigo mio de teleco lo ha subido a internet (por cierto él sale en el video, es uno de los que hacen el vago al final)
link
martes, 15 de abril de 2008
Apuntes de clase 15/04/08
Empezamos la clase recordando lo visto en la clase anterior gracias al resumen de un compañero (aqui el resumen) y vemos un interesante articulo sobre gráficas manipuladas tomando como ejemplo el ultimo anuncio de movistar.
Seguimos viendo un ejercicio de autoevaluacion del tema 3 (bloque 3.1).Uno de los ejemplos que ha puesto no funciona con kubuntu, parece que solo funciona con gentoo. El resto de ejercicios que ha hecho el compañero estan bien.
Seguimos con el Tema 3 por donde lo dejamos el otro dia...
3.2 Gestión de carga y prestaciones en el sistema operativo
Un administrador tiene que mantener a sus usuarios felices y satisfacer sus peticiones. Por tanto la gestión debe plantearla de la siguiente forma:
- Planificación y definición de la carga del sistema: Es conveniente acordar de antemano qué se consideran unas prestaciones aceptables. Una vez llevada a cabo esta planificación, hay que comprobar si, con el sistema tal como está, se puede llevar a cabo ese acuerdo y si en el futuro previsible, con los usuarios y la carga pico prevista, se va a poder cumplir.
Ejemplo: Adquisición de un servidor web
Basándose en el número de peticiones por minuto y la hora a las que se van a recibir, habrá que estimar el tamaño de la memoria necesaria, el ancho de banda necesario en función de las peticiones que se van a servir y el tamaño de disco duro. Además, el administrador deberá comprobar la evolución del número de peticiones y prever los picos para, si es necesario, solicitar más ancho de banda (bandwidth-on-demand; algunos servidores permiten solicitar en un momento determinado más ancho de banda que el que se tiene asignado; algunos te cobrarán por ancho de banda adicional con sumido, y la mayoría, directamente te cortan la conexión con un error 509) o una ampliación del sistema; o bien cambiar la configuración para que soporte el pico de demanda.
A raiz del ejemplo del servicio web, vemos los tipos de hosting que puede proporcionar una empresa que presta ese servicio, y bajo que condiciones se contrata el servicio (espacio disponible, ancho de banda,numero de bases de datos o de cuentas de correo...).
Un truco para no consumir tanto ancho de banda es utilizar el modulo de apache mod_rewrite para que si se procede de una pagina externa al sitio (google por ejemplo) se redireccione a otro sitio.
- Configurar las herramientas de monitorización del sistema: Como por ejemplo para controlar el ancho de banda o el nivel de paginas servidas por un servidor para que alerte cuando se llegue a un nivel no deseable. Un ejemplo de herramienta de este tipo es Logwatch. Tambien es posible utilizar scripts del sistema (de hecho el lenguaje Perl se creó con este fin). Otro lenguaje de este tipo es AWK
- Tratar de resolver problemas mediante políticas de gestión del sistema: Limitación de uso interactivo, limitación de uso de disco mediante cuotas...
- Ampliar el sistema: Si todo lo anterior falla (y dentro de las posibilidades que haya).
3.3 Políticas de gestión del sistema
Tanto el usuario como el administrador pueden tomar medidas para mejorar el sistema. Algunas medidas que pueden tomar los usuarios son:
- Usar comandos internos de shell en vez de los de Unix (por ejemplo utilizar el comando echo en vez de ls, echo $PWD y no pwd)
- Evitar los caminos largos, que hacen que el ordenador tenga que leer muchos directorios cada vez que se ejecuta un comando.
- Evitar los directorios con muchos ficheros.
- Usar las versiones mas eficientes de cada tipo de programa.
- Eliminar daemons inútiles para la máquina.
- Limitar tiempos de ejecución interactivos, y renicear procesos a discreción.Se puede limitar el tiempo de ejecución con el comando limit (o ulimit, que es el comando interno del bash).
- Modificar los parámetros del sistema operativo.Para eso hace falta conocer la estructura del kernel.
Terminamos por hoy el temario y pasamos a explicar la Practica 5.
Practica 5 - Mejora de las prestaciones de un Sistema
Esta practica es importante ya que constituye el primer "ensayo" para el trabajo final. En esta practica hay que definir un objetivo (ejemplo: quiero que compilar el programa tarde un 5% menos). Por tanto hay que plantearse el sistema antes y despues del cambio. Si decidimos hacerlo con un servidor web es útil el programa Apache benchmark.
Los cambios que realicemos pueden ser tanto software como hardware. Es importante tener en cuenta que la mejora debe realizarse sin tener en cuenta la carga del sistema para medir las prestaciones.
Plantilla de la practica
Fecha de entrega: 7 de Mayo.
Acabamos como siempre con el video del dia: Overclocking extremo.
Seguimos viendo un ejercicio de autoevaluacion del tema 3 (bloque 3.1).Uno de los ejemplos que ha puesto no funciona con kubuntu, parece que solo funciona con gentoo. El resto de ejercicios que ha hecho el compañero estan bien.
Seguimos con el Tema 3 por donde lo dejamos el otro dia...
3.2 Gestión de carga y prestaciones en el sistema operativo
Un administrador tiene que mantener a sus usuarios felices y satisfacer sus peticiones. Por tanto la gestión debe plantearla de la siguiente forma:
- Planificación y definición de la carga del sistema: Es conveniente acordar de antemano qué se consideran unas prestaciones aceptables. Una vez llevada a cabo esta planificación, hay que comprobar si, con el sistema tal como está, se puede llevar a cabo ese acuerdo y si en el futuro previsible, con los usuarios y la carga pico prevista, se va a poder cumplir.
Ejemplo: Adquisición de un servidor web
Basándose en el número de peticiones por minuto y la hora a las que se van a recibir, habrá que estimar el tamaño de la memoria necesaria, el ancho de banda necesario en función de las peticiones que se van a servir y el tamaño de disco duro. Además, el administrador deberá comprobar la evolución del número de peticiones y prever los picos para, si es necesario, solicitar más ancho de banda (bandwidth-on-demand; algunos servidores permiten solicitar en un momento determinado más ancho de banda que el que se tiene asignado; algunos te cobrarán por ancho de banda adicional con sumido, y la mayoría, directamente te cortan la conexión con un error 509) o una ampliación del sistema; o bien cambiar la configuración para que soporte el pico de demanda.
A raiz del ejemplo del servicio web, vemos los tipos de hosting que puede proporcionar una empresa que presta ese servicio, y bajo que condiciones se contrata el servicio (espacio disponible, ancho de banda,numero de bases de datos o de cuentas de correo...).
Un truco para no consumir tanto ancho de banda es utilizar el modulo de apache mod_rewrite para que si se procede de una pagina externa al sitio (google por ejemplo) se redireccione a otro sitio.
- Configurar las herramientas de monitorización del sistema: Como por ejemplo para controlar el ancho de banda o el nivel de paginas servidas por un servidor para que alerte cuando se llegue a un nivel no deseable. Un ejemplo de herramienta de este tipo es Logwatch. Tambien es posible utilizar scripts del sistema (de hecho el lenguaje Perl se creó con este fin). Otro lenguaje de este tipo es AWK
- Tratar de resolver problemas mediante políticas de gestión del sistema: Limitación de uso interactivo, limitación de uso de disco mediante cuotas...
- Ampliar el sistema: Si todo lo anterior falla (y dentro de las posibilidades que haya).
3.3 Políticas de gestión del sistema
Tanto el usuario como el administrador pueden tomar medidas para mejorar el sistema. Algunas medidas que pueden tomar los usuarios son:
- Usar comandos internos de shell en vez de los de Unix (por ejemplo utilizar el comando echo en vez de ls, echo $PWD y no pwd)
- Evitar los caminos largos, que hacen que el ordenador tenga que leer muchos directorios cada vez que se ejecuta un comando.
- Evitar los directorios con muchos ficheros.
- Usar las versiones mas eficientes de cada tipo de programa.
- Eliminar daemons inútiles para la máquina.
- Limitar tiempos de ejecución interactivos, y renicear procesos a discreción.Se puede limitar el tiempo de ejecución con el comando limit (o ulimit, que es el comando interno del bash).
- Modificar los parámetros del sistema operativo.Para eso hace falta conocer la estructura del kernel.
Terminamos por hoy el temario y pasamos a explicar la Practica 5.
Practica 5 - Mejora de las prestaciones de un Sistema
Esta practica es importante ya que constituye el primer "ensayo" para el trabajo final. En esta practica hay que definir un objetivo (ejemplo: quiero que compilar el programa tarde un 5% menos). Por tanto hay que plantearse el sistema antes y despues del cambio. Si decidimos hacerlo con un servidor web es útil el programa Apache benchmark.
Los cambios que realicemos pueden ser tanto software como hardware. Es importante tener en cuenta que la mejora debe realizarse sin tener en cuenta la carga del sistema para medir las prestaciones.
Plantilla de la practica
Fecha de entrega: 7 de Mayo.
Acabamos como siempre con el video del dia: Overclocking extremo.
martes, 8 de abril de 2008
Apuntes de clase 8/04/08
El profesor empieza diciendo que se reabre el plazo de entrega de las practicas de la 1 a la 3, con una puntuación maxima sobre 8.
Comentarios segunda practica
Posteriormente, pasa a comentar algunos de los errores mas comunes que se ha encontrado en la correción de la segunda práctica. Estos son los siguientes:
- Faltas de ortografía
- Errores al incluir imágenes/enlaces
- Confusión de benchmark con monitor de prestaciones
- Medición de cantidades irrelevantes
Las notas son por lo general bastante buenas, ya que hay pocos suspensos.Los monitores mas utilizados son los siguientes:
- Perfmon
- Sysinternals
- CS Fire Monitor
- System Explorer
Comentarios tercera practica
En primer lugar vemos el ejemplo de un compañero.
Bastante gente ha elegido un programa que realiza la sucesión de Fibonacci hasta un limite n, ya que era un programa que se utilizo en otra asignatura del primer cuatrimestre(TA).
El ejemplo esta bastante bien, ya que realiza un análisis bastante completo del programa y se nota que lo ha analizado de forma correcta.
Los problemas que se han encontrado en esta práctica son los siguientes:
- Uso de programas "de broma" (que no hacen absolutamente nada util)
- No incluir el tiempo total del programa
- Mejoras que cambian el programa totalmente (en vez de que haga lo mismo de forma optimizada, hace otra cosa diferente que resulta mas rápida)
- El nunca suficientemente bien ponderado uso de las referencias constantes: Hay que tener en cuenta cuando se devuelve por valor y por referencia, ya que las llamadas por valor utilizan en constructor de copia de forma que eso consume parte del tiempo de ejecución
- Copias: Uno de los alumnos parece que se ha copiado, y la primera vez que se detecta la copia es un 0 y la segunda es un suspenso.
Un compañero habla de un programa llamado kcachegrind, que se encarga de realizar un analisis con programas que estan en ejecucíon puesto que detecta las llamadas a caché. Vemos unos cuantos pantallazos del programa, que parece bastante completo y con una interfaz muy intuitiva.
**NOTA: La fecha de entrega de la practica 4 es el 21 de abril.**
Comparativa Windows Vista vs. XP
En esta web aparece una comparativa entre las 2 versiones mas recientes de Windows, y tiene como conclusión que XP es mas rápido que Vista. El profesor señala un error de esta comparación, pues NUNCA se debe utilizar el uso de un sistema como un parámetro para la comparación entre ellos. Es mas conveniente hacer una medición de prestaciones que ponga de manifiesto los defectos (o las virtudes) de uno frente al otro. El arranque y el apagado es mucho mas lento en Vista, pero la copia de archivos es mas rapida que en Windows XP.
Ejercicio Autoevaluación Tema 2-Bloque 3
Antes de seguir con el temario, vemos un par de ejercicios de autoevaluación del tema 2. Estan disponibles aqui.
Parece que hay un fallo, ya que las barras se utilizan para categorias,y las lineas se utilizan para funciones o bien variables que necesitan una progresión.
Ahora si seguimos con el temario...
Tema 3 - Solución de problemas en un sistema informático
La idea de este tema es dar una serie de reglas que permitan mejorar las prestaciones de un sistema informático. Debemos ponernos por tanto en la situación del Administrador de Sistemas, es decir, tenemos un sistema al que accede mucha gente y queremos que funcione bien.Las politicas que se suelen seguir son las siguientes:
- Ajuste de parámetros del sistema operativo: Hay algunos parámetros que el superusuario, o administrador del sistema, puede modificar, usando programas suministrados con el sistema operativo o recompilando alguna parte.
- Ajuste de parámetros del hardware: Examinar la configuración hardware del sistema y ver qué parámetros se pueden alterar, tales como por ejemplo la activación de cachés hardware, el reloj del sistema, frecuencia del bus. Algunos de estos cambios pueden ser peligrosos.
- Equilibrado de cargas: Repartir las cargas a las que son sometidos los diversos dispositivos.
- Ampliación: Cuando todo lo anterior falla, y si hay dinero, tiempo y ganas, se pueden comprar dispositivos nuevos, o cambiar los dispositivos por otro más rápido.
- Cambio del software: Puede ser una actualización de una parte del sistema o cambiar a una versión superior, o cambiar el software que se está usando por otra versión u otra marca. Es peligroso a veces.
A la hora de mejorar las prestaciones hay que tener en cuenta los siguientes principios:
- Conocer y comprender tu entorno
- Hay que buscar el equilibrio: Cuando se quiere mejorar algo, forzosamente se va a empeorar otra cosa.
- Throughput contra latencia: Cantidad de cosas que se hace por unidad de tiempo contra el tiempo que se tarda en realizar una cosa. La primera métrica es del tipo mayor es mejor y la segunda del tipo menor es mejor.
- No sobreutilizar un recurso: La utilización de recursos es del tipo nominal es mejor, al igual que el disco duro por ejemplo.
- Diseñar las pruebas con cuidado: No hay que actuar cambiando algo sin saber las consecuencias que puede traer.
Por ultimo comentamos en clase algunos de los ejercicios de autoevaluación. que vienen al principio del Tema 3.
Ahora para finalizar vemos el video del dia
Comentarios segunda practica
Posteriormente, pasa a comentar algunos de los errores mas comunes que se ha encontrado en la correción de la segunda práctica. Estos son los siguientes:
- Faltas de ortografía
- Errores al incluir imágenes/enlaces
- Confusión de benchmark con monitor de prestaciones
- Medición de cantidades irrelevantes
Las notas son por lo general bastante buenas, ya que hay pocos suspensos.Los monitores mas utilizados son los siguientes:
- Perfmon
- Sysinternals
- CS Fire Monitor
- System Explorer
Comentarios tercera practica
En primer lugar vemos el ejemplo de un compañero.
Bastante gente ha elegido un programa que realiza la sucesión de Fibonacci hasta un limite n, ya que era un programa que se utilizo en otra asignatura del primer cuatrimestre(TA).
El ejemplo esta bastante bien, ya que realiza un análisis bastante completo del programa y se nota que lo ha analizado de forma correcta.
Los problemas que se han encontrado en esta práctica son los siguientes:
- Uso de programas "de broma" (que no hacen absolutamente nada util)
- No incluir el tiempo total del programa
- Mejoras que cambian el programa totalmente (en vez de que haga lo mismo de forma optimizada, hace otra cosa diferente que resulta mas rápida)
- El nunca suficientemente bien ponderado uso de las referencias constantes: Hay que tener en cuenta cuando se devuelve por valor y por referencia, ya que las llamadas por valor utilizan en constructor de copia de forma que eso consume parte del tiempo de ejecución
- Copias: Uno de los alumnos parece que se ha copiado, y la primera vez que se detecta la copia es un 0 y la segunda es un suspenso.
Un compañero habla de un programa llamado kcachegrind, que se encarga de realizar un analisis con programas que estan en ejecucíon puesto que detecta las llamadas a caché. Vemos unos cuantos pantallazos del programa, que parece bastante completo y con una interfaz muy intuitiva.
**NOTA: La fecha de entrega de la practica 4 es el 21 de abril.**
Comparativa Windows Vista vs. XP
En esta web aparece una comparativa entre las 2 versiones mas recientes de Windows, y tiene como conclusión que XP es mas rápido que Vista. El profesor señala un error de esta comparación, pues NUNCA se debe utilizar el uso de un sistema como un parámetro para la comparación entre ellos. Es mas conveniente hacer una medición de prestaciones que ponga de manifiesto los defectos (o las virtudes) de uno frente al otro. El arranque y el apagado es mucho mas lento en Vista, pero la copia de archivos es mas rapida que en Windows XP.
Ejercicio Autoevaluación Tema 2-Bloque 3
Antes de seguir con el temario, vemos un par de ejercicios de autoevaluación del tema 2. Estan disponibles aqui.
Parece que hay un fallo, ya que las barras se utilizan para categorias,y las lineas se utilizan para funciones o bien variables que necesitan una progresión.
Ahora si seguimos con el temario...
Tema 3 - Solución de problemas en un sistema informático
La idea de este tema es dar una serie de reglas que permitan mejorar las prestaciones de un sistema informático. Debemos ponernos por tanto en la situación del Administrador de Sistemas, es decir, tenemos un sistema al que accede mucha gente y queremos que funcione bien.Las politicas que se suelen seguir son las siguientes:
- Ajuste de parámetros del sistema operativo: Hay algunos parámetros que el superusuario, o administrador del sistema, puede modificar, usando programas suministrados con el sistema operativo o recompilando alguna parte.
- Ajuste de parámetros del hardware: Examinar la configuración hardware del sistema y ver qué parámetros se pueden alterar, tales como por ejemplo la activación de cachés hardware, el reloj del sistema, frecuencia del bus. Algunos de estos cambios pueden ser peligrosos.
- Equilibrado de cargas: Repartir las cargas a las que son sometidos los diversos dispositivos.
- Ampliación: Cuando todo lo anterior falla, y si hay dinero, tiempo y ganas, se pueden comprar dispositivos nuevos, o cambiar los dispositivos por otro más rápido.
- Cambio del software: Puede ser una actualización de una parte del sistema o cambiar a una versión superior, o cambiar el software que se está usando por otra versión u otra marca. Es peligroso a veces.
A la hora de mejorar las prestaciones hay que tener en cuenta los siguientes principios:
- Conocer y comprender tu entorno
- Hay que buscar el equilibrio: Cuando se quiere mejorar algo, forzosamente se va a empeorar otra cosa.
- Throughput contra latencia: Cantidad de cosas que se hace por unidad de tiempo contra el tiempo que se tarda en realizar una cosa. La primera métrica es del tipo mayor es mejor y la segunda del tipo menor es mejor.
- No sobreutilizar un recurso: La utilización de recursos es del tipo nominal es mejor, al igual que el disco duro por ejemplo.
- Diseñar las pruebas con cuidado: No hay que actuar cambiando algo sin saber las consecuencias que puede traer.
Por ultimo comentamos en clase algunos de los ejercicios de autoevaluación. que vienen al principio del Tema 3.
Ahora para finalizar vemos el video del dia
martes, 1 de abril de 2008
Practica 2: Monitorizacion de un sistema
He subido aqui la practica 2 que he hecho por si alguien quiere verla (aunque no sea gran cosa):
link
link
Suscribirse a:
Entradas (Atom)