Apuntes 13-05-08

Comenzamos la clase haciendo unos breves comentarios sobre los errores cometidos durante la realización de la práctica 5.

1. Hay que plantear objetivos reales, con cargas de trabajo reales. En particular, el tiempo que tarda en arrancar un sistema no es una carga real.
2. Los objetivos no pueden ser sobre la tasa de uso de un componente (memoria, CPU)
3. Las pruebas se diseñan en función del objetivo, y no al revés. Si se trata de que “este programa vaya más rápido”, el programa debe ser representativo, no hecho ex profeso.
4. Hay que mejorar un sistema, no cambiarlo. El sistema, en general, será un ordenador, algún subsistema del mismo, o en general las prestaciones. No se trata de decir “cambio este programa por este otro más rápido, y ahora va más rápido”. O antes tenía esto en memoria, ahora lo quito, y ocupa menos menoria todo (o va más rápido).
5. Tampoco se trata de bajarse “PC optimizer 2000″, le doy a siguiente, siguiente siguiente, y luego mira la pantalla que pone “sistema optimizado”.

Unos ejemplos de prácticas bien hechas son las siguentes realizadas por los compañeros:

http://aullidosdigitales.blogspot.com/2008/05/prctica-5-medicin-de-las-prestaciones.html

o

http://mdyec.blogspot.com/2008/05/practica-5.html

Continuamos haciendo un resumen de la clase anterior:
http://saramggh.blogspot.com/2008/05/6-5-2008.html

Y continuamos ya con el temario…

4. Selección y Configuración de Sistemas Informáticos: Benchmarking

4.1 Introducción

Un benchmark es un programa o conjunto de programas que evalúan las prestaciones de un sistema informático reproduciendo una carga de trabajo genérica en dicho sistema informático.

4.2 Utilización de un benchmark

Los benchmarks son usados por una gran cantidad de personas, sus resultados son también aprovechados por una amplia gama de profesionales, y, por tanto, la mayoría tienen cierto grado de oficialidad o estandarización.

4.2.1 ¿Quién propone un benchmark?

Dado que los benchmarks sirven para comparar sistemas informáticos, deben de tener amplia difusión, y, de hecho, todos los sistemas informáticos deben ser evaluados por el mismo benchmark, para que efectivamente puedan ser comparados.

El propio interesado puede llevar a cabo los benchmarks, siempre que los diferentes sistemas informáticos estén disponibles y cuente con los recursos suficientes para hacerlo. De esta forma, se pueden enfocar claramente los objetivos del estudio, y usar las métricas y resultados que más interesen; además, tiene sentido que los usuarios conozcan como aplicar y qué suelen medir los benchmarks más importantes. Estas métricas se explican en el apartado siguiente.

4.2.2 Tipos de benchmarks

Hay diferentes tipos de benchmarks, dependiendo de cómo se representa la carga de trabajo.

• En algunos casos se pueden usar programas reales, realizando una carga de trabajo real.
• Núcleos o kernel, que representan las operaciones fundamentales de una carga de trabajo. Uno clásico son los bucles de Livermore, que representan operaciones comunes en cálculo numérico.
• Benchmarks de juguete: miden parámeros básicos, como los megahercios o la latencia de la memoria.
• Sintéticos, resultan de una operación estadística que mide la carga de trabajo usada con una serie de programas, y abstrae y resume la carga.

4.2.3 Unidades de medida

4.2.4 Errores comunes

En el proceso de medición de las prestaciones de un sistema informático se pueden producir una serie de errores, debidos a la inexperiencia de los realizadores, o bien por no haber tenido en cuenta ciertos factores importantes en las prestaciones de un sistema. Los errores más habituales son los siguientes:

• Representar solamente comportamiento medio en la carga de trabajo.
• Ignorar la distribución desigual de las peticiones de dispositivos.
• No controlar el nivel de carga de forma apropiada.
• Ignorar los efectos de la cache: las caches hacen que el orden en el cual se realizan las operaciones tenga importancia, porque puede conducir a que la información que necesita un programa se encuentre o no en la cache.
• Ignorar el overhead del monitor.
• No validar las medidas: se deben comprobar todas las medidas realizadas por dispositivos hardware, como en cualquier otro experimento.
• No asegurarse de las mismas condiciones iniciales.
• No medir las prestaciones del transitorio, ya que la mayoría de los experimentos están diseñados para predecir las prestaciones bajo condiciones estables.
• Utilizar los porcentajes de uso de los dispositivos para comparar prestaciones.
• Recoger demasiados datos con muy poco análisis: el resumir todos los resultados en un índice de la forma adecuada puede ser tan arduo como obtener los resultados en sí.

Mientras que estos errores son involuntarios, puede suceder que se cometan errores con el objetivo de probar que el ordenador que se está midiendo es mejor que el de la competencia. Es lo que se llaman juegos de benchmarking, como se verá a continuación.

4.2.5 Juegos de benchmarking

Hay diversas formas de engañar al público con los resultados de un benchmark, lo cual se ha venido a denominar benchmarketing.

• Usar configuraciones diferentes para ejecutar la misma carga de trabajo, por ejemplo distinta cantidad de memoria, o discos de diferente calidad o tamaño.
• 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, pero no tener nada que ver con las prestaciones reales de la misma.
• Usar benchmarks demasiado pequeños: que pueden hacer que los fallos de página y de cache sean mínimos, de forma que se ignore la ineficiencia de la organización de las mismas.
• Proyectar o interpolar resultados de un benchmark.
• Elegir el sistema base de normalización de forma arbitraria.

Sin embargo, en la mayoría de los casos, es difícil engañar con los resultados de los benchmarks, ya que ni el código de los mismos ni la presentación de sus resultados están bajo control de los fabricantes. Por eso lo más práctico es engañar directamente al benchmark, como se verá en la siguiente sección que veremos ya en el próximo dia.

Por último vemos el video del día:
http://video.google.com/videoplay?docid=-528884877021355232&q=benchmarking&ei=LX8pSIHvLJ2ciAKGiJjdCQ

Práctica 5

1. ESPECIFICAR LOS OBJETIVOS Y DEFINIR EL SISTEMA

El objetivo que me propongo para ésta practica es el de mejorar las prestaciones (en este caso rendimiento) de mi tarjeta gráfica, mediante la práctica de Overclock.

ENTORNO DE PRUEBAS:

El equipo de pruebas será mi propio equipo, sus características son las siguientes:

• Placa base: Asus P4S800D (5 PCI, 1 AGP, 1 WiFi, 4 DDR DIMM, LAN) (Chipset SiS 655FX)
• Procesador: Intel Pentium 4, modelo Prescott de 3.0 GHz (socket 478).
• Memoria del sistema: 2 Gbytes distribuidos en cuatro zócalos idénticos DDR de 512Mbytes y PC-3200 (2×200 MHz) con unas latencias CL3. Los cuatro módulos conectados en modo Dual Channel.
• Tarjeta Gráfica: BBA(Built By Ati) Ati Radeon X850XT 256MB AGP
• Tarjeta de Red: integrada en placa base.
• Tarjeta de sonido: integrada en placa base.
• Unidades de almacenamiento: Maxtor Serial-Ata con una capacidad de 200GBytes
• Unidades ópticas: Lector de DVD LG / Regrabadora de DVD Pioneer DVR-110D

Los drivers instalados en el sistema para la tarjeta gráfica son los ATI Catalyst 7.1

HERRAMIENTAS SOFTWARE:

Las herramientas que vamos a utilizar para realizar las pruebas serán las siguientes:

Overclocking:

ATITool 0.26
ATITool es una utilidad que permite realizar overclocking para obtener un mayor rendimiento. Permite modificar un gran número de aspectos, tales como la velocidad del procesador de la tarjeta (Core) y de la memoria. También permite buscar cuál es la máxima velocidad a la que podrían ir estos dos aspectos.

Benchmark:

3dmark 2005
3DMark 2005 es un programa de benchmarking (testeo) de nuestro equipo, y en especial de la tarjeta gráfica. Prueba varias funcionalidades de la tarjeta en forma de test y devuelve una puntuación global.

Analisis del PC:

Everest Home Edition (Version 2.20.405)
Everest Home Edition es una completísima herramienta que, en unos pocos segundos, realiza un extenso y detallado análisis del PC, mostrando prácticamente todos los aspectos del sistema referentes a hardware, software, configuración de red y más.

2. MÉTRICAS O CRITERIOS PARA COMPARAR PRESTACIONES

Para comparar las prestaciones ofrecidas por la tarjeta gráfica vamos a utilizar el puntaje suministrado por el benchmark descrito anteriormente (3dmark05). Al tratarse de una puntuación, podríamos clasificar ésta métrica como “más es mejor”.

3. PARÁMETROS QUE PUEDEN AFECTAR A LAS PRESTACIONES

La carga del sistema y/o el uso de la CPU/Tarjeta Gráfica por parte de algún otro programa, aparte del que nosotros estamos ejecutando y usando para para hacer la medición, puede afectar de alguna forma en la puntuación obtenida y no permitir que el sistema afronte el benchmark de testeo gráfico de una manera óptima. Por ello procuraremos que el sistema siempre se encuentre en las mismas condiciones antes de tomar las medidas correspondientes.

Además de lo antes mencionado, puede haber otros factores que afecten a las pruebas realizadas, como puede ser el aspecto hardware o las versiones del software instalado en el sistema. Es por ello que no se realizarán ningunas modificaciones en estos aspectos para conseguir la máxima igual de condiciones en cada una de las medidas tomadas.

4. SELECCIONAR LAS TÉCNICAS DE EVALUACIÓN

La técnica a utilizar será la de medicion ya que será posible medir valores “reales” en el sistema.

5. SELECCIONAR LA CARGA DE TRABAJO

La carga de trabajo será equiparada desde el software de benchmark 3dmark ya anteriormente descrito, realizando una “pasada” completa al mismo.

6. DISEÑO DE LOS EXPERIMENTOS, ANÁLISIS E INTERPRETACIÓN DE LOS DATOS

Para overclockear la tarjeta gráfica solo nos hará falta un programa, en mi caso utilizaré el ATITool (versión 0.26) ya mencionado al principio, pero también hay otros programas para este fin como puede ser el RivaTuner. En estos programas, nos solemos encontrar dos parámetros, la velocidad del procesador de la tarjeta (GPU) y la velocidad de la memoria.

El proceso a seguir es un proceso sencillo, basado en la prueba-error. Para ello iremos subiendo la frecuencia en primer lugar de la memoria, poco a poco, y luego ponemos alguna aplicación que haga uso de la tarjeta gráfica, en mi caso utilizaré la herramienta incluida para ello en el ATITool. Si vemos defectos en la imagen, puntos negros o de colores entonces eso nos querrá decir que hemos llegado al límite, en ese caso bajaremos la frecuencia de la memoria hasta la última velocidad segura.

Una vez que tenemos la máxima velocidad de la memoria haremos lo mismo que con el procesador de la tarjeta. Durante este proceso, es posible que el ordenador se quede colgado o que salgan defectos en la imagen, polígonos extraños, etc. comúnmente conocidos como artifacts.

Una vez que tenemos las máximas frecuencias hay que comprobar la estabilidad del sistema, esto requiere probar la configuración durante cierto tiempo con algún benchmark o juego. Si existiera inestabilidad, habría que rebajar nuevamente las frecuencias.

Para medir el rendimiento que vamos obteniendo según vamos subiendo las frecuencias de la tarjeta, utilizaremos el 3dmark05, obteniendo una puntuación y pudiendo comparar así el rendimiento obtenido gracias al overclock realizado.

PUESTA EN PRÁCTICA:

Antes de comenzar a subir las frecuencias, pasaremos por primera vez el 3dmark05 para ver cuál es el rendimiento obtenido con de frecuencias de serie de la tarjeta (520/540). La configuración del 3dmark05 será la que viene en el programa por defecto:

La puntuación obtenida es la siguiente:

A partir de ahora nos limitaremos a ir subiendo las frecuencias tanto de memoria como del core e iremos testeando la estabilidad de la nueva configuración. Las frecuencia de serie son de 520 Mhz en el core y 540 Mhz en la memoria.

Comenzaremos subiendo poco a poco la velocidad de la memoria. Esta tarjeta monta memorias de la marca Samsung de 1,6 nanosegundos, lo cual nos indica que la memoria tendría una frecuencia máxima de trabajo de:

1000 / 1.6 ns = 625 Mhz → 625Mhz x 2 = 1250Mhz

(Multiplicamos por 2 por tratarse de memoria DDR)

frente a los 540 Mhz x 2 = 1080 Mhz de serie, lo cual supondría un incremento de 1250 Mhz – 1080 Mhz = 170 Mhz

Eso supondría un incremento realmente notable, pero que no llegaremos a alcanzar, no porque la memoria no lo soportara (que no lo sabemos), sino por el riesgo que ello supondría para la integridad de la propia tarjeta. Nos limitaremos simplemente a hacer un pequeño overclock para mostrar la mejoría de rendimiento.

Para empezar, comenzaremos situando la memoria en los 558Mhz y escanearemos la imagen por si se encuentra algún artifacts:

Tras aproximadamente 10 minutos no aparece ningún tipo de artifacts, por lo que seguiremos subiendo la frecuencia de la memoria.

Volvemos a subir hasta los 579 Mhz la memoria y realizamos el mismo proceso:

Tras aproximadamente otros 10 minutos, tampoco se encuentran artifacts, por lo que decidimos subir la memoria por última vez un poco más, situándola en los 589.09 Mhz.

Pasaremos ahora a subir las frecuencias del core de la tarjeta gráfica, el proceso será muy parecido al realizado para subir las frecuencias en la memoria. Comenzaremos subiendo la frecuencia del core hasta los 529.20 Mhz:

Tras aproximadamente 10 minutos pasando el test, no se encuentran artifacts, por lo que subiremos otra vez la frecuencia hasta llegar a los 540 Mhz:

Tras otros 10 minutos aproximadamente, tampoco encontramos algún tipo de artifacts en la imagen por lo que tomaremos esta frecuencia como la última estable. No continuaremos subiendo la frecuencia del core por los mismos motivos expuestos para la memoria.

En la pestaña “overclock” del Everest Home Edition podemos ver el resultado del overclock realizado:

Como se puede observar, el margen de overclock obtenido es del 9% en memoria, consiguiendo un incremento de 1178 Mhz – 1080 Mhz = 98 Mhz de reloj efectivo de la memoria y un ancho de banda de 36.8 GB/s frente al 33.8 GB/s original, lo cual supone un incremento de 36.8 GB/s – 33.8 GB/s = 3 GB/s más.

El margen de overclock obtenido para el core es del 4%, que supone un incremento de 540 Mhz – 520 Mhz = 20 Mhz en la velocidad de reloj de la GPU de la tarjeta gráfica.

Para ver el rendimiento obtenido gracias al overclock realizado, volveremos a pasar el benchmark 3dmark05 para comparar el resultado con el obtenido con las frecuencias de reloj de serie de la tarjeta gráfica.

El resultado obtenido es el siguiente:

7. PRESENTACIÓN DE LOS RESULTADOS

- REPRESENTACIÓN GRÁFICA:

Como se puede observar, la mejora obtenida gracias al overclock es considerable, obteniendo en el benchmark 3dmark05 una puntuación de +299 puntos respecto a la puntuación obtenida con las frecuencias de fábrica de la tarjeta gráfica, lo cual supone un incremento aproximado del 5,2 %.

Podemos concluir diciendo que en el 3dMark el uso de la tarjeta grafica es fundamental, por esto que con un overclock de la misma se obtienen resultados superiores.

Y tienes que darme el punto adicional porque…

Como ya ha sido comprobado durante la realizacion de la práctica, se han cumplido los objetivos propuestos para la misma, los cuales consistían en incrementar el rendimiento de la tarjeta gráfica, en este caso, mediante la práctica de overclocking sobre la misma.

Apuntes 29-04-08

Comenzamos la clase de hoy haciendo un breve repaso a lo visto en la clase anterior. (Comienzo del tema 3)

Continuamos comentando algunos de los ejercicios de autoevaluación realizados por los compañeros:
http://dyec2008.blogspot.com/
http://tupakamaru.wordpress.com/2008/04/25/ejercicios-autoevaluacion-362/

A continuacion vemos un ejemplo (no del todo bien hecho) de comparativa entre cartuchos de tinta:
http://www.trustedreviews.com/printers/review/2007/04/21/The-Inkjet-Investigation/p3

Continuamos con el temario…

3.6.1 Consideraciones sobre la configuración.

Si hay que comprar un nuevo sistema de E/S, dado que hay poca elección en cuanto al controlador y al ordenador que hay que conectar, lo más importante es el tiempo mínimo de búsqueda.

3.6.2 Particiones y filesystems

En la mayoría de los casos y de los sistemas operativos actuales, hay varios filesystems donde elegir; como mínimo, hay un filesystem “antiguo”, que se usa por razones de compatibilidad, y uno “nuevo”; incluso puede darse el caso de que un mismo sistema operativo tenga diferentes filesystems, uno en cada versión, y que un mismo ordenador tenga diferentes filesystems en un mismo disco duro incluso. Como ejemplos podemos ver el FAT de windows o ext3 de Unix.

En cada partición suele haber un filesystems; y un sistema UNIX suele tener muchas particiones en cada disco, aparte de varios discos en cada sistema.

3.6.3 Equilibrio de la carga de trabajo de E/S

La herramienta que se usa para esto es iostat o sar –d. Iostat da un informe que, entre otras cosas, indica cuánto se ha leído y escrito en cada disco duro físico, y cuántas transacciones, o peticiones de lectura/escritura, ha habido.

Lo ideal sería que el trabajo estuviera repartido entre todos los discos, pero no siempre es así. Para sollucionar este problema, se puede:

- Colocar los ficheros a los que más se acceda en los discos duros más rápidos

- Repartir los usuarios entre diferentes discos duros, y colocar los ficheros de los usuarios que más uso tenga en los más rápidos.

3.6.4 Conservando el espacio del disco duro

Lo más conveniente sería borrar toda la información prescindible del disco duro.

3.6.5 Mejora de prestaciones de disco en WinNT

Se puede medir el porcentaje de uso del fichero de paginación, porcentaje de uso de disco y demás. Puede ser que en un servidor haya algún problema, en caso de que el archivo de paginación se use más del 90% del tiempo. En algunos casos, usar una controladora de disco con caché puede mejorar el asunto.

3.6.6 Usando la BIOS para mejorar prestaciones

Modificando diversos parametros en la bios podemos mejorar las prestaciones de nuestro disco duro.

3.7 Optimización de un servidor web

Consejos:

- Desconectar consultas DNS inversas
- Incrementar el tiempo de timeout del TCP
- Buscar un servidor cerca de los usuarios potenciales
- Incrementar la RAM
- Actualizar las versiones del servidor y del sistema operativo.
- Dedicar el servidor exclusivamente a eso
- Usar APIs del servidor en vez de SSI (server-side includes) o CGI (common gateway interface).
- Preprocesar el contenido dinámico, para evitar al servidor el trabajo de generarlo, o usar algún sistema de caché, para que las páginas que se soliciten más frecuentemente estén pre-generadas.
- Usar un profesional

3.8 Mejora de prestaciones de sistemas Windows XP

Para empezar, windows xp se optimiza de forma automática. Además, usando el sentido comun, podemos eliminar del sistema todos los programas y utilidades superfluas. Tambien conviene mantener nuestro sistema actualizado, desfragmentar de vez en cuando, y controlar las aplicaciones que se cargan al inicio eliminando todas las que sean innecesarias.

- – – – – – – – -

Por último, tras acabar el tema 3, vemos el video del dia:
http://video.google.com/videoplay?docid=-2952683797671550884&q=disk+performance&ei=vAgXSJ2rHo-K2QKzhfnSBg

Apuntes 22-04-08

Comentarios práctica 4

Para empezar la clase comentamos los errores cometidos sobre la práctica 4, que son mas numeroros que en el resto de las prácticas:

- Demasiados pantallazos, nada de análisis: hay que hacer medias y representarlas
- 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
- ¡Faltas de ortografía!

A continuación vemos un ejemplo de práctica 4, la realizada por tupakamaru y comentamos los errores encontrados en ella.

Ejercicios de autoevaluación

Seguimos la clase comentando algunos ejercicio de autoevaluación realizdos por los compañeros.

http://aullidosdigitales.blogspot.com/2008/04/tema-3-solucin-de-problemas-en-un.html

Continuamos con el temario

3.4 Mejora de prestaciones de la CPU

Hay diversos métodos para conseguir que la CPU vaya mas rápido, cambiando la velocidad en megahercios a la que funciona la CPU.

La estrategia a seguir es la siguiente:

- 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.
- 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.

3.5 Sintonización de la memoria

La actividad de la memoria consiste principalmente en swapping, o escritura de un proceso completo, con toda la memoria correspondiente, en disco, y paginación, en la cual se cargan o descargan las páginas de un proceso que son necesarias en cada momento. Un proceso pagina por el simple hecho de cargarse en memoria, por ello es normal que el parámetro que representa a las páginas cargadas en un sistema se mantenga siempre en un valor mayor no nulo. Si un sistema empieza a estar algo falto de memoria, empiezan a escribirse páginas en disco (swapping de desesperación).

Ante este problema, la solución mas fácil sería la de comprar más memoria. Pero además de ésta, hay otras soluciones no tan drásticas:

- Limitar el tamaño de los procesos
- Animar a la gente a usar librerías compartidas.
- Modificar el algoritmo de paginación
- Cambiar el tamaño de la partición de swap
- Usar herramientas de gestión de prioridad por proceso

En esta página, podemos encontrar un pequeño tutorial sobre lo que hay que hacer cuando se agotan los recursos:
http://cr.yp.to/docs/resources.html

3.6 Mejora de prestaciones en entrada/salida

Los discos duros pueden afectar a las prestaciones del sistema en general. La eficiencia estará en tres factores diferentes: throughput por proceso, throughput total, y eficiencia en el almacenamiento.

El optimizar los primeros dos factores es hasta cierto punto compatible, si un sistema tiene unas buenas prestaciones por proceso, también lo serán las totales, pero no necesariamente. Un proceso suele acceder a un solo fichero en un solo disco duro, mientras que el sistema en total accede a muchos ficheros simultáneamente en muchos discos duros, o, lo que es peor, en el mismo. El que interese más uno u otro factor dependerá del uso prioritario de cada disco duro y del sistema en total.

El tercer factor, eficiencia en el almacenamiento, es incompatible con el throughput; si se trata de optimizar el throughput disminuye la eficiencia en el uso del disco.

Hasta aqui el temario de hoy…

Por último vemos el video del dia:

http://es.youtube.com/watch?v=pJMGAdpCLVg

DyEC en Camara Abierta 2.0

Apuntes 15-04-08

Para empezar vamos a hacer un resumen de la clase anterior. Nuestro compañero Antares comenta los apuntes que tomó la semana pasada y que tiene colgados en su blog:
http://antaresdyec.blogspot.com/2008/04/clase-08-de-abril-de-2008.html

A continuacion comentamos un ejemplo actual de manipulación en la representacion gráfica. Lo podemos observar en el anuncio de movistar como exponen en el siguiente analisis:
http://www.ensilicio.com/2008/03/la-grafica-manipulada-del-ultimo-anuncio-de-movistar.html

Ejercicios de autoevaluacion:

Comentamos el ejercicio de autoevaluacion 3.1 realizado por “Topakamaru” y que tiene colgado en el siguiente enlace de su blog:
http://tupakamaru.wordpress.com/2008/04/11/ejercicios-autoevaluacion-31/

Continuamos con el temario

3.2 Gestión de carga y prestaciones en el sistema operativo

Un administrador ha de mantener un sistema, para ello ha de plantear la gestion del sistema de la siguiente forma:

- Planificación y definición de la carga del sistema: es conveniente acordar de antemano (con la autoridad competente) 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.

- Configurar las herramientas de monitorización del sistema: se deberán poner en funcionamiento las herramientas que monitorizan en cada momento los subsistemas principales. Estos monitores nos indicarán como se usa el sistema en cada momento y a lo largo del tiempo, y nos permitirán prever los fallos y arreglarlos fácilmente (o no) cuando se produzcan.

- Tratar de resolver problemas mediante políticas de gestión del sistema, tales como limitación de uso interactivo, limitación de uso de disco mediante cuotas,

- Ampliar el sistema, si todo falla.

3.3 Políticas de gestión del sistema

Tanto los usuarios como el administrador pueden mejorar el funcionamiento del sistema. Algunas de estas medidas pueden ser:

- Usar comandos internos del shell en vez de los comandos externos de UNIX, ya que el shell ya se encuentra ejecutándose en memoria.

- Evitar los caminos largos, que hacen que el ordenador tenga que leer muchos directorios cada vez que se ejecuta un comando, asi como evitar los directorios con muchos ficheros.

- Usar las versiones más eficientes de cada tipo de programa.

- Eliminar daemons inútiles y malos para el alma de la máquina.

- Limitar tiempos de ejecución interactivos.

- Modificar los parámetros del sistema operativo conociendo bien la estructura del mismo.

Hasta aquí el temario para hoy. Pasamos a explicar la práctica 5:

La practica consiste en mejorar las prestaciones de un sistema. Esta práctica va a ser un “ensayo” para la practica final.
Primero nos vamos a definir un objetivo, por ejemplo, quiero que un programa al compilar tarde menos. Tomaremos las mediciones antes del cambio y posterior al cambio. Para realizar la práctica vamos a seguir explícitamente la metodología de la asignatura.

Fecha de entrega: Miercoles dia 7 de Mayo.

Por último vamos ver el video del dia, que consisten en overclocking extremo:
http://video.google.es/videoplay?docid=5393904704265757054

Apuntes 08-04-08

Comenzamos la clase repasando algunos de los errores cometido por los alumnos en la realización de la segunda práctica.

Continuamos la clase realizando algunos comentarios sobre la practica 3. Ademas, uno de los compañeros, con una puntuacion 10 en la práctica, comenta su practica:
http://mamm86.webcindario.com/index3.html

Nota: acordamos como fecha de entrega de la practica 4 para el dia 21 de Abril.

- – – – – – -

A continuación comentamos el siguiente enlace:

XP vs Vista: http://mamm86.webcindario.com/index3.html

De él podemos sacar la conclusion que, en general, Windows XP es mas rapido que Windows Vista. Además, el profesor comenta que hay un error en dicha comparativa: NUNCA se debe utilizar el uso de un sistema como parametro para comparar ambos sistemas operativos. Sería mas conveniente por ejemplo una medición que ponga de manifiesto virtudes o defectos de un sistema operativo frente al otro.

- – – – – – -

Antes de continuar con el tema 3, un compañero (Victor), comenta el ejercicio de autoevaluación 3.1 del tema 2 que ha realizado. Dicho ejercicio lo podemos encontrar en el siguiente enlace:
http://vkdyec.blogspot.com/2008/04/ejercicios-de-autoevaluacin-algunos-del.html

- – – – – – -

Continuamos con el temario

Comenzamos con el tema 3:

3. Solución de problemas en un sistema informático

3.1 Introducción

Nos vamos a situar en la posición de un Administrador de sistemas. Una vez evaluado el rendimiento de un sistema informático, hay una serie de medidas que se pueden tomar para sintonizarlo, es decir, mejorar sus prestaciones en algún aspecto. En concreto, puede hacerse algo de lo siguiente:

- Ajuste de parámetros del sistema operativo: hay algunos parámetros que el administrador del sistema puede modificar, usando programas suministrados con el sistema operativo o recompilando alguna parte, generalmente el kernel, como sucede en algunas versiones de UNIX. En Windows por ejemplo, consistiria en modificar el registro.

- 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.

- Equilibrado de cargas: repartir las cargas a las que son sometidos los diversos dispositivos, como red, discos duros, entre las diferentes máquinas que las gestionen y personas que lo usan, o repartir los ficheros entre los diferentes filesystems del sistema.

- Ampliación: si hay dinero, tiempo y ganas, se pueden comprar dispositivos nuevos, o cambiar los dispositivos por otro más rápido. Previamente, claro, habrá que realizar un análisis de cuáles son los dispositivos que están limitando las prestaciones del sistema.

- 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.

Conviene también tener en cuenta una serie de principios a la hora de mejorar las prestaciones de un sistema:

- Conoce y comprende tu entorno: es conveniente saber todo lo que hace el sistema. Así, en el caso de que algo vaya mal, se podrá identificar rápidamente la causa, y evitarla.

- Hay que buscar el equilibrio: básicamente quiere decir, que cuando hagamos una cosa y queramos mejorar algo, forzosamente vamos a empeorar otra cosa, y hay que ser conscientes de ello.

- Throughput contra latencia: son cosas contrapuestas, podemos aumentar throughput a costa de latencia y viceversa. Recordamos que throughput es del tipo “mayor es mejor” y latencia es del tipo “menor es mejor”.

- No sobreutilices un recurso: la utilización de recursos es “nominal es mejor”.

- Diseña las pruebas con cuidado: antes de cambiar cosas, hay que actuar teniendo en cuenta las consecuencias que ello puede conllevar.

- – – – – – -

Por último, vemos el video del dia:
http://www.youtube.com/watch?v=HEnm9cIZN3Q

Práctica 2

DyEC: Practica 2 : David Piñar Toro

El objetivo de ésta práctica es configurar un monitor para que monitorice las variables más interesantes de los siguientes subsistemas de un ordenador: CPU, memoria, disco y red.

Para ello utilizaré el monitor de sistema Perfmon incluido en el propio Windows XP. Para ejecutar dicho monitor bastará con ejecutar el comando perfmon.msc.

Nota: no han sido necesario ficheros de configuración.

Las variables a monitorizar dentro de Perfmon serán las siguientes:

• Procesador - % de uso del procesador
• Memoria - MBytes disponibles
• Disco Duro – % de uso del disco duro
• Red – Total de bytes por segundo

El equipo sobre el que se van a llevar a cabo las mediciones es el siguiente:

• Procesador: Intel Pentium 4, 3000 MHz (15 x 200)
• Placa Base: Asus P4S800D (5 PCI, 1 AGP, 1 WiFi, 4 DDR DIMM, LAN)
• Memoria del sistema: 2048 MB (PC3200 DDR SDRAM)
• Tarjeta Gráfica: ATI Radeon X850XT 256MB (AGP)
• Disco duro:Maxtor 6 L200M0 SCSI Disk Device (200 GB, 7200 RPM, SATA)
• Tarjeta de Red: SiS 900-Based PCI Fast Ethernet Adapter
• Velocidad de conexion a Internet: 1 MBytes

Para tomar las mediciones no se tendrá en cuenta ninguna carga particular de trabajo, solo la carga determinada desde los servicios activos que hay en el sistema recién encendido.

A continuación se muestran la gráfica de las medidas tomadas para los 4 subsistemas mediante el monitor Perfmon:

Como se puede ver en el gráfico en color rojo, el porcentaje de uso del procesador es generalmente bajo, algo normal si tenemos en cuenta que las medidas son tomadas sin ninguna carga particular de trabajo que requiera de un uso considerable del procesador.

El gráfico de porcentaje de uso de disco, en color verde, muestra una gráfica bastante irregular con diversos accesos intermitentes a disco tanto para escritura como para lectura.

El gráfico que representa la memoria principal de sistema que hay disponible, en color azul, muestra una gráfica lineal que se mantiene constante sobre los 1400 Mbytes.

Por último se puede observar, en color fucsia, el gráfico sobre el tráfico de red en el sistema.

Apuntes 01-04-08

Para empezar, a modo de explicación de la segunda práctica, vemos un ejemplo de un programa en pearl hecho por el profesor. La idea es que tomamos un programa original en un lenguaje (c++, pearl…) y hacer un profile con el.

- Recapitulación de la clase anterior

Un compañero, Victor, nos da una explicación sobre su práctica, que previamente ha subido a su blog personal.

http://espacioforos.miarroba.com/1141788/prac2.html

Comenta el trabajo realizado en la práctica asi como una breve explicacion de las gráficas.

---

A continuación comentamos el ejercicio de autevaluación siguiente:
http://tupakamaru.wordpress.com/2008/03/14/ejercicios-autoevaluacion-13/En dicho ejercicio podemos observar algunos errores, por ejemplo:La velocidad del procesador de la tarjeta gráfica, mas es mejor no tiene porqué cumplirse ya que no debemos de fiarnos para medir las prestaciones de una medida que nos de el fabricante, si no de algunas medidas tomadas por nosotros.Continuamos con el temario 1.5.4 Programas de monitorización de la actividad del sistema

Hay programas que son utiles para monitorizar la actividad del sistema, o ayudan a preparar un sistema para monitorizarlo aunque luego no sean monitores en si.

Algunos ejemplos de estos programas de monitorización son: Cron y contab, uptime y ruptime, Ps, Top, Iostap, Sar, Perfmeter…

Con esto finalizamos el tema y realizamos unos breves comentarios sobre la bibliografía recomendada para este tema de la asignatura.

Empezamos el nuevo tema

2. Representación gráfica aplicada a la evaluación de prestaciones

2.1 Presentación de los resultados

Para presentar y analizar los resultados obtenidos de la ejecución de un monitor sobre un sistema o una comparativa entre varios sistemas normalmente se usa algún tipo de gráfico. Esta información hay que representarla de modo que sea sencilla y facil de entender.

2.1.1 Gráficos de Gantt

En un gráfico de Gantt, se representa en abscisas el tiempo, y en ordenadas una línea que representa los instantes durante los cuales un recurso ha estado ocupado. A partir de la gráfica de Gantt se puede hacer análisis de Pert.

2.1.2 Gráficos de Kiviat

En un gráfico de Kiviat, se representan los porcentajes de uso y solapamiento de diferentes componentes del sistema como una figura geométrica que une diferentes puntos, situados sobre los radios de un círculo, que representan esos porcentajes. Habitualmente está dividido en 8 sectores; y en ellos se suele colocar alternativamente magnitudes del tipo “ más alto es mejor” con magnitudes del tipo “bajo es mejor”.

2.2 Reglas para representaciones gráficas

- Minimizar el esfuerzo por parte del lector: cuanto mas facil sea leer un gráfico, mejor.
- Maximizar información:debe de haber información suficiente en el gráfico para hacerlo autosuficiente.
- Minimizar la tinta: no meter cosas que no hagan falta. (Ejemplo: rayas excesivas en los ejes)
- Usar prácticas comúnmente aceptadas: como el eje x para la variable independiente, el y para la dependiente, el origen en el 0,0, las abscisas y ordenadas en orden creciente.
- Evitar la ambigüedad: mostrar los ejes, las subdivisiones, las medidas, escalas, identificar cada una de las barras, hacerlo fácil de leer.
- No poner demasiada información ni demasiada poca.

2.3 Errores comunes en la representación gráfica de resultados

- Presentar demasiadas alternativas en un solo gráfico.
- Presentar muchas variables y (abscisas) en un solo gráfico: crea confusión.
- Usar símbolos en lugar de texto.
- Seleccionar mal las escalas.
- Usar un gráfico de líneas en vez de uno de barras.

Errores a proposito con el fin de demostrar algo:

- Usar orígenes no nulos para hacer énfasis de la diferencia.
- Trazar cantidades aleatorias sin los intervalos de confianza.
- Usar pictogramas escalados por altitud.
- Usar tamaños de célula no adecuados en histogramas, y usar escalas partidas en gráficos de columnas.

Ejercicio de autoevaluación 3.1

1. ¿Qué tipo de gráfico (líneas o barras) se usaría para trazar:
   • Uso de CPU para 12 meses del año. -> Respuesta: Lineas (tiempo)
   • Uso de CPU en función del tiempo en meses. -> Respuesta: Lineas
   • Número de E/S a 3 discos duros: A, B, y C. -> Respuesta: Barras (categoría)
   • Número de E/S como una función del número de discos duros en el sistema. -> Respuesta: Lineas

---

– Comentarios de la 4ª práctica:

Es parecida a la segunda pero ademas hay que someter al sistema a diferentes cargas al tomar las mediciones.

Apuntes 11-03-08

Durante la primera parte de la clase el profesor realiza unos breves comentarios sobre la corrección de la práctica 1.A continuación el profesor tambien comenta una página que es bastante interesante para la asignatura, esta página es: www.slashdot.org. Dentro de esta página comentamos un articulo también muy interesante sobre los procesadores multicore.

Ejercicios de autoevaluación

A continuación se comentan en clase los siguientes ejercicios de autoevaluación.

1. http://sumandorestas.blogspot.com/2008/03/ejercicio-autoevaluacin-1-sistemas.html
2. http://saramggh.blogspot.com/2008/03/ejercicios-autoevaluacin.html
3. http://antaresdyec.blogspot.com/2008/03/autoevaluacin-tema-1-bloque-2.html

Bloque 4

* http://tauro3dec.wordpress.com/2008/03/11/4-ejercicios-de-autoevaluacin/
* http://sumandorestas.blogspot.com/2008/03/autoevaluacin-4.html

Los ejercicios son comentados por los compañeros y el profesor.

Continuación del temario

1.5 Medición de la carga de un sistema:

Seguimos con el temario de monitores y profilers. A modo de ejemplo ejecutamos el comanto Top en la línea de comandos en el Sistema Operativo linux. Ejecutando este comando podemos monitorizar todas las tareas que se están ejecutando en ese momento entre otras cosas.

Hay 2 tipos de monitores:

• Los monitores (que es lo que hemos visto hasta ahora): son herramientas de medición que permiten seguir el comportamiento de los principales elementos de un sistema informático cuando éste se halla sometido a una carga de trabajo determinada.

1.5.1 Los profilers

• Los profilers: son trozos de código linkados a un programa, y que son llamados cada cierto tiempo. Estos fragmentos de programa generan un fichero, que es luego analizado por otros programas; el análisis muestra el tiempo empleado en cada una de los procedimientos de un programa y el número de veces que se ha llamado, de forma que el programador pueda optimizar esos procedimientos.

1.5.2 Métricas de la carga de trabajo más comunes

La medición de diversas magnitudes relacionadas con el funcionamiento de un sistema, como las que se verán a continuación, es necesaria tanto para detectar los problemas que afectan al sistema como para evaluar los resultados de un benchmark:

* Throughput o número de peticiones procesadas en la unidad de tiempo.
* Tiempo de respuesta: opuesto del throughput (para un solo elemento), es el tiempo que se tarda en procesar una petición.
* Eficiencia es la tasa del throughput máximo al throughput que se consigue de forma efectiva.
* Ancho de banda: bits por segundo que es capaz de procesar el sistema. No confundir con baudios.
* Porcentaje de utilización de diversos componentes y solapamiento entre los mismos, es decir, la proporción de tiempo que cada uno de los dispositivos está funcionando y la proporción de tiempo durante la cual están funcionando simultáneamente. Cuanto mayor sea el solapamiento, mayor será la eficiencia del sistema, pues ningún dispositivo estará esperando a que otro acabe sus tareas para funcionar.
* Overhead: es decir, tiempo usado en tareas que no son directamente del usuario.
* Factores relacionados con la multiprogramación: tales como el tiempo usado en cambiar de contexto.
* Factores relacionados con la memoria virtual: fallos de página, número de veces que se ha hecho swapping.
* Factores relacionados con la memoria caché de CPU: similares a lo dicho con la memoria virtual, y aparte veces que se vacían los buffers TLB, por ejemplo.
* Otros subsistemas: red, gráficos (que tienen mucha importancia últimamente).

1.5.3 A que se dedica el tiempo

Antes de intentar mejorar las prestaciones de cualquier sistema, es decir, hacerlo más rápido, hay que saber en qué invierte el tiempo el sistema. Para medir el tiempo que tarda en ejecutarse un programa, una de las medidas básicas de las prestaciones de cualquier sistema, se puede ejecutar una utilidad tal como /bin/time, /usr/bin/time o timex, que son el equivalente en las dos versiones del sistema operativo; y que son diferentes a una función del shell, también llamada time.

Desde el punto de vista de la sintonización del sistema y la mejora de prestaciones, la diferencia entre tiempo usuario+sistema y tiempo total está totalmente fuera de control del usuario, ya que depende de lo que todo los demás estén haciendo, así que veremos en qué consiste el tiempo de usuario+sistema:

* Tiempo de usuario, o tiempo de CPU en estado usuario: tiempo que está la CPU ejecutando código del usuario librerías invocadas por el mismo.
* Tiempo del sistema, que en gran parte está bajo control (indirecto) del superusuario o administrador del sistema: tiempo que está ejecutando llamadas al sistema y tareas administrativas relacionadas con el programa: paginación y cosas así.
* El resto del tiempo se divide en tiempo en la red, tiempo de E/S, tiempo que se tarda en ejecutar otros programas, y prestaciones de la memoria virtual.

Video del dia

Para terminar, vemos el video del día: Profiling de una aplicación web con Visual C++

http://video.google.es/videoplay?docid=2586644995405021525&q=profiling++c&pr=goog-sl