Bueno, ya se terminó la asignatura y aquí pongo un enlace a mi trabajo.
http://mamm86.webcindario.com/trabajo.html
E e e eeeso es todo amigos
lunes, 21 de julio de 2008
martes, 20 de mayo de 2008
DYEC - 20 de Mayo de 2008
Empezamos la clase dando nuestros nombres a JJ para subirnos unos puntillos extra por asistencia, :)
Después vemos el resumen de la clase anterior (esta vez me ha tocado a mí).
A continuación vemos un artículo sobre los kernel precompilados y el hecho de no ser necesario compilar elkernel para cada máquina; Y vemos que el argumento que utiliza el autor es que aunque optimices el kernel, en este caso compilandolo, es muy bajo el tiempo que se está ejecutando en CPU y por lo tanto no vas a conseguir una gran mejora. Sobre este argumento vemos que es erróneo porque si el sistema es un sistema orientado a que el tiempo del kernel en núcleo sea alto, como por ejemplo un servidor, es obvio que se reducirá bastante el tiempo de cualquier rutina.
Trabajo final: 6 de Julio de 2008
Las notas de clase saldrán en Julio y se pueden reclamar.
Seguimos con ejercicios de autoevaluación:
1. El blog de Josele
En estos ejercicios vemos que el artículo tiene varios fallos a la hora de representar los gráficos como meter un fondo, barras delimitadoras, distintos formatos (verticales y horizontales), demasiados resultados en un sólo gráfico, utilizar líneas cuando deberían ser barras, utilizar una leyenda en vez de colocar cada identificador debajo de su barra correspondiente,.... y no haber incluido el índice final.
2: Davis87 Ejercicio 4.1
3: Davis87 Ejercicio 4.2
4: Davis87 Ejercicio 4.3
Y ahora seguimos con el temario:
4.2.6 Engañando a los benchmarks
El mejor benchmark que se puede utilizar para un juego es probar ese juego, porque al utilizar un benchmark sintético te puede dar unos resultados malos y al jugar el juego te puede funcionar perfectamente y darte unos resultados buenísimos.
ATI y NVIDIA configuraron sus tarjetas para que al ejecutar el benchmark 3DMark, dejase código sin ejecutar para que obtuviesen resultados muy buenos con el 3DMark.
Después vemos el resumen de la clase anterior (esta vez me ha tocado a mí).
A continuación vemos un artículo sobre los kernel precompilados y el hecho de no ser necesario compilar elkernel para cada máquina; Y vemos que el argumento que utiliza el autor es que aunque optimices el kernel, en este caso compilandolo, es muy bajo el tiempo que se está ejecutando en CPU y por lo tanto no vas a conseguir una gran mejora. Sobre este argumento vemos que es erróneo porque si el sistema es un sistema orientado a que el tiempo del kernel en núcleo sea alto, como por ejemplo un servidor, es obvio que se reducirá bastante el tiempo de cualquier rutina.
Trabajo final: 6 de Julio de 2008
Las notas de clase saldrán en Julio y se pueden reclamar.
Seguimos con ejercicios de autoevaluación:
1. El blog de Josele
En estos ejercicios vemos que el artículo tiene varios fallos a la hora de representar los gráficos como meter un fondo, barras delimitadoras, distintos formatos (verticales y horizontales), demasiados resultados en un sólo gráfico, utilizar líneas cuando deberían ser barras, utilizar una leyenda en vez de colocar cada identificador debajo de su barra correspondiente,.... y no haber incluido el índice final.
2: Davis87 Ejercicio 4.1
3: Davis87 Ejercicio 4.2
4: Davis87 Ejercicio 4.3
Y ahora seguimos con el temario:
4.2.6 Engañando a los benchmarks
El mejor benchmark que se puede utilizar para un juego es probar ese juego, porque al utilizar un benchmark sintético te puede dar unos resultados malos y al jugar el juego te puede funcionar perfectamente y darte unos resultados buenísimos.
ATI y NVIDIA configuraron sus tarjetas para que al ejecutar el benchmark 3DMark, dejase código sin ejecutar para que obtuviesen resultados muy buenos con el 3DMark.
Dado que las decisiones de compra de muchos consumidores de
material informático dependerán de las prestaciones del mismo, tal como han sido
medidas por organizaciones, independientes, hay una gran presión para obtener
los mejores resultados posibles. Ya que es difícil manipular los resultados, por
la verificación a que éstos son sometidos, se intenta mani pular los ordenadores
de forma que produzcan tiempos de ejecución mejor en los benchmark. El problema
es que, de esta forma, los benchmarks se convierten el algo totalmente
independiente de las prestaciones reales del sistema, y, lo que es más
importante, en las diferencias relativas entre sistemas.
En algunos casos se
hace difícil comparar dos sistemas, incluso para el mismo juego, porque el
código que se ejecuta depende del hardware; por eso, usar juegos para comparar
puede ser contraproducente, porque puede dar mejores prestaciones en el hardware
peor, siempre que el código para ese hardware específico lo permita. El problema
es que al ser el código específico del sistema, si se usa un benchmark genérico,
los resultados que se van a dar no van a tener ningún sentido.
Los timos en
lso benchmarks son un problema real, habiendo artículos que hablaban de
escándalos casi diarios Las formas más habituales en
que se suelen producir estos engaños son los siguientes:
Detección y
optimización del código de un benchmark: tanto los compiladores como el código
del sistema operativo pueden examinar lo que están ejecutando o compilando, ver
su parecido con alguno de los benchmarks habituales, y optimizar sólo y
exclusivamente ese código, dando resultados mucho mejores que los que se
obtendrían con un código similar en una aplicación real o dando resultados
optimizados aún en el caso de que el compilador no haya activado esta opción.
Esto hizo IBM cuando produjo una versión nueva de su compilador de C para las
estaciones de trabajo IBM System/6000, o algunos fabricantes de tarjetas de
video que incluyeron código de aceleración de WinBench directamente en un ASIC.
Hay incluso una empresa, KAP, que mejora compiladores para que optimicen código de algún
benchmark, específicamente Matrix300, esto, a largo
plazo no sirve de mucho, porque es. Incluso en algún caso, había compiladores
que eliminaban totalmente el bucle principal del benchmark, como sucedió con
Whetstone y un compilador de IBM (hecho que no he sido capaz de comprobar, por
cierto). También lo ha hecho Sun con CaffeineMark, un benchmark para Java. Posiblemente, lo mismo haya sucedido con estos cambios de versión de driver que dieron tal diferencia entre
tarjetas..
Análisis del benchmark independiente
de la máquina. En algunos casos, los lenguajes como el Java o los compiladores
como el gcc de la GNU, crean un código independiente de la máquina, que
posteriormente se ensambla o interpreta por una máquina virtual. En tal caso, se
puede analizar ese código, como se hace en [Conte91], para concluir qué
características debe de tener un ordenador que ejecute ese código lo más rápido
posible. Esto permite, por ejemplo, dimensionar las caches para que se minimicen
los fallos de página. Sin embargo, una vez más, las mejoras sólo serán
aplicables para los programas incluidos en el benchmark, aunque en este caso los
resultados sean de aplicación más genérica.
Precisamente por esta razón, la
mayoría de los benchmark estándar cambian cada cierto tiempo. SPEC se revisa
cada 3 años, y hasta ahora ha habido tres versiones: SPEC89, 92, 95 y 2000
(todavía están preparando la siguiente en el año 2005). De esta forma, cuando
los fabricantes han aprendido a engañar un benchmark, se propone uno
nuevo.
En teoría, de todas formas, debería ser posible crear un benchmark que
no se pueda engañar, como afirman en este trabajo, que no parece
haber tenido mucho éxito. Solo que es difícil.Otra forma de engañar a un benchmark como ya hizo Sun es al usarlo con un servidor de páginas webs, servir las páginas desde la caché.
Un benchmark interesante para bases de datos es el TPC:
TPC (Transaction Processing Performance Council) es un consorcio que propone benchmarks en el área de procesamiento de transacciones. Hay varios benchmarks propuestos; hoy en día los más usados son TPC-C y TPC-D. Ambos tienen como entorno de referencia el siguiente: un sistema cliente, que genera peticiones de bases de datos usando un front-end, y un sistema servidor, que ejecuta el intérprete del lenguaje de bases de datos, generalmente SQL, y desde el mismo accede a un sistema de gestión de bases de datos. Cada transacción debe de ser atómica, es decir, se lleva a cabo o no completa, y además los sistemas deben de estar disponibles 24/7, 24 horas al día 7 días a la semana.
Estos benchmarks son de muy alto nivel, o más bien, ejercitan todos los niveles del sistema, desde la jerarquía de memoria, incluyendo memoria secundaria, pasando por el sistema operativo, hasta los programas que resuelven un problema concreto.
Las métricas que se proporcionan con estos benchmarks son de dos tipos: peticiones/tiempo, número de usuarios, y precio/prestaciones; hay unas reglas estrictas para evaluar éste último. Se verá a continuación cada uno de los benchmarks por separado.
h5e.incWrite('TPC-C')Otros benchmark interesantes son los creados para la Web:
4.3.2 SPECWebxxx y otros benchmarks de servidores web
SPECWeb2005 (http://www.spec.org/osg/web2005/) es la última versión de un benchmark que se concibió originalmente en el año 95; es un benchmark sintético para medir las prestaciones de sistemas como servidores web. Inicialmente incluía sólo páginas estáticas, pero hoy en día ha cambiado mucho. Tiene las siguientes características:
Combina contenido estático y dinámico, pero se basa más en el estático que en el dinámico.
El contenido estático contiene ficheros de diferente tamaño y frecuencia decreciente; y dentro de cada "nivel", los ficheros tienen tamaños que se incrementan en un número fijo de Ks. Por ejemplo, los del nivel de 100Ks se incrementan de 10 en 10 Ks. Se sigue una ley de Zipf (número de peticiones exponencialmente decreciente con el tamaño) para decidir qué fichero se pide.
El resultado principal de este benchmark es lo que se denomina "conexiones simultáneas conformantes", es decir, peticiones simultáneas que es capaz de manejar; se suele repetir tres veces y se da la mediana de los tres resultados como resultado válido.
Al principio, este benchmark recibió bastante atención por parte de los medios; por ejemplo, este artículo cuenta como se triplica prácticamente, sobre la misma máquina, las prestaciones de un servidor RH Linux sobre un servidor IIS. Sin embargo, mirando un poco de más cerca, vemos a qué se puede deber esta ventaja. El servidor que usa el sistema RedHat es Tux, denominado actualmente Red Hat Content Accelerator, un servidor que se ejecuta como tarea en el kernel, en un sistema exclusivamente dedicado a eso (prácticamente). De hecho, los servidores web más potentes no suelen ser los más conocidos.
De hecho, el uso de este servidor web es relativamente irrelevante, ni siquiera aparece en el informe de servidores web. Por lo tanto, el hecho de que se use o no este servidor puede ser totalmente irrelevante para un caso real, donde los servidores van a ser probablemente el Apache o el IIS. Al parecer, la imposibilidad de superar a este servidor en los benchmarks ha hecho que la gente pase de ejecutarlo sobre sus máquinas, y probablemente conducirá a la revisión del mismo (igual que sucedió con el SpecWEB96, que tuvo que ser revisado por la introducción por parte de Sun del Network Caché Accelerator, un módulo del kernel que metía las páginas estáticas en un buffer de la memoria del kernel).Terminamos el tema 4 y para terminar la clase vemos el último video del día.
martes, 13 de mayo de 2008
DYEC - 13 de Mayo de 2008
Comenzamos la clase viendo los fallos de la quinta práctica:
- 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.
- Los objetivos no pueden ser sobre la tasa de uso de un componente (memoria, CPU)
- 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.
- 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).
- Tampoco se trata de bajarse "PC optimizer 2000", le doy a siguiente, siguiente siguiente, y luego mira la pantalla que pone "sistema optimizado".
- Un buen ejemplo: http://aullidosdigitales.blogspot.com/2008/05/prctica-5-medicin-de-las-prestaciones.html
- Otro, más claro: http://mdyec.blogspot.com/2008/05/practica-5.html
Vemos la práctica de LP-Spain y vemos que ha hecho un poco de trampa porque en verdad cambia un sistema viejo y malo y por uno nuevo y bueno.
Ahora vemos el resumen de la clase anterior.
Seguimos con los ejercicios de autoevalución de Davis87.
Ahora vemos un artículo sobre la arquitectura x86 y que dice que va a estar presente muchos año más.
Seguimos con el temario:
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.
Uno de los benchmark más conocidos es el SPEC, y vemos un ejemplo del SPEC.
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 (por ejemplo que multiplica matrices), 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. No representan en asoluto a ninguna carga de trabajo real.
- 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. Son benchmark de bajo nivel.
Los mejores benchmark son los de núcleos o kernel, aunque hay muchos buenos que combinan los kernel y los sintéticos.
- Representar solamente comportamiento medio en la carga de trabajo.
- Ignorar la distribución desigual de las peticiones de dispositivos. Provoca que los resultados no sean muy realistas.
- No controlar el nivel de carga de forma apropiada.
- Ignorar los efectos de la cache. Puede falsear los resultados. Para evitarlo hay que hacer benchmark que no quepan en la caché o repitiendolo varias veces.
- Ignorar el overhead del monitor.
- No validar las medidas. Hacerlas varias veces. (Muy importante).
- No asegurarse de las mismas condiciones iniciales, es decir, de que el estado de la cache sea el mismo, el de los procesos que se están ejecutando también, incluso, si es posible, la fragmentación del disco duro y el espacio que queda libre, pues, como se sabe, estos son dos factores que influyen en la velocidad del mismo. (Muy importante). Por ejemplo: ejecutar el benchmark con el ordenador recién arrancado.
- 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. Por ejemplo: en un sistema recién arrancado, la temperatura no va a ser la misma que la que tendrá pasado un rato.
- Utilizar los porcentajes de uso de los dispositivos para comparar prestaciones. Por ejemplo el uso de CPU. (Muy importante).
- Recoger demasiados datos con muy poco análisis. (Muy importante).
Es hacer marketing utilizando un benchmark, engañar al público con los resultados de un benchmark. Truco clásico de benchmarking de AMD frente a Intel: sus CPUs se llaman lo mismo a las equivalentes en Intel. Por ejemplo un AMD 1800 que en verdad va a 1600 equivale a un Intel que va a 1800.
- 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.
- Elegir una carga de trabajo arbitraria.
- Usar benchmarks demasiado pequeños.
- Proyectar o interpolar resultados de un benchmark.
- Elegir el sistema base de normalización de forma arbitraria.
Y para terminar el video del día.
lunes, 12 de mayo de 2008
DYEC - 6 de Mayo de 2008
Como siempre repaso de la clase anterior.
Comenzamos viendo los trabajos que ya están aquí publicados.
Después vemos unas determinadas cuestiones sobre la práctica siguiente y el trabajo final:
Comenzamos viendo los trabajos que ya están aquí publicados.
Después vemos unas determinadas cuestiones sobre la práctica siguiente y el trabajo final:
- Hay que seguir los 10 pasos que vimos en el tema 1 para la comparación de sistemas.
- El objetivo de una comparativa no es hacer la comparativa, sino evaluarlas siguiendo un objetivo determinado.
- Al final debe de haber un indice (numéricamente o gráficamente) que muestre los resultados finales. Hay que elegir un sistema base (sistema sin mejorar en caso de que vayamos a mejorarlo), por cada mejora sería un nuevo sistema. Si hay varios sistemas se toma como base el sistema más lento. Ejemplo:
A B IA IB Indice de b: media geométrica de las medidas de B
ma 3 5 1 1,666
mb 2 6 1 3 1 (Raiz(Ib(a), IB(b)) / sqrt(5)
- La última frase del trabajo o la práctica 6 debe ser: el siguiente sistema tiene un indice 1 y el mejor sistema es tal.
- No incluir pantallazos. Sólo incluir una tabla y un gráfico. No meter pantallazos de benchmarks, meter los datos en tablas y presentar las tablas finales.
- El trabajo final no debe exceder de 10 páginas.
- Hay que comparar mínimo 3 sistemas
- Hay que poner el indice final obligatoriamente
- La fecha de entrega del trabajo es la fecha del examen.
- Los indices son siempre mayor es mejor, por lo tanto si tenemos un índice menor es mejor se divide el menor entre el mayor.
- Todo deben de ser medidas y no caracteristicas.
Seguimos con el temario.
3.7 - Optimizacion de la red:
Heramienta: ethtool
ethtool -t eht0
Si la red es muy segura lo mejor es enviar paquetes muy grandes para no tener que esperar tanto a los ACK.
Buffers de red: mejor cuanto más grandes
Con el ethtool se puede hacer que la tajeta de red tome parte del procesamiento que hace el procesador sobre paquetes de red
Terminamos el tema 3 y empezamos el 4.
4 - Selección y Configuración de Sistemas Informáticos: Benchmarking
No hay que poner todas las medidas que muestra un benchmark, solo las realmente útiles para nosotros.
En las comparativas nunca hay que poner uso de cpu. Si la única diferencia entre 2 sistemas es la CPU lo que hay que hacer es hacer varias copias simultáneas o ocupar casi todo el uso de CPU y asi ver que programa con la CPU a 100% va mejor. También se puede mirar la temperatura de la CPU.
A continuación vemos unos ejercicios de tupakamaru.
Práctica 6
Hay que analizarlo como el trabajo final, con un sistema base cuyo índice va a ser 1 y hay que usar 3 sistemas. Como mínimo hay que hacer mediciones sobre un aspecto. Probar: programas en perl, java y en xp, vista, linux o mac. También uno muy fácil puede ser en javascript o perl. Tiene que ser portable. Tiene que tardar 5 o 6 minutos en ejecutarse para que se puedan apreciar los cambios. Usar el reloj del sistema y no un cronómetro de mano para medir los tiempos. 3 sesiones de prácticas.
Fecha de entrega: 2 de Junio
Y por último los videos del día:
- Pruebas a un portátil (Por favor, no realiceis estas pruebas en casa y si lo haceis, bajo la supervisión de un adulto).
- Prestaciones de Windows XP.
DYEC - 15 de Abril de 2008
Para empezar, como siempre, repasamos la clase anterior viendo en este caso el resumen de Antares. A continuacion comentamos un ejemplo de manipulación en la representación de gráficas.
Ejercicios de autoevaluacion: Comentamos el ejercicio de autoevaluacion 3.1 realizado por Topakamaru
Continuamos con el temario:
3.2 Gestión de carga y prestaciones en el sistema operativo
Un administrador ha de mantener un sistema y 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.
A continuación, pasamos a ver la 5ª práctica:
Consiste en mejorar las prestaciones de un sistema. Esta práctica va a ser una prueba para la practica final. Primero definimos un objetivo, por ejemplo, que al compilar tarde menos. Tomaremos las mediciones antes del cambio y posteriores 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.
Y como siempre el video del día, overclocking extremo.
Ejercicios de autoevaluacion: Comentamos el ejercicio de autoevaluacion 3.1 realizado por Topakamaru
Continuamos con el temario:
3.2 Gestión de carga y prestaciones en el sistema operativo
Un administrador ha de mantener un sistema y 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.
A continuación, pasamos a ver la 5ª práctica:
Consiste en mejorar las prestaciones de un sistema. Esta práctica va a ser una prueba para la practica final. Primero definimos un objetivo, por ejemplo, que al compilar tarde menos. Tomaremos las mediciones antes del cambio y posteriores 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.
Y como siempre el video del día, overclocking extremo.
DYEC - 8 de Abril de 2008
Comenzamos la clase repasando las prácticas 2 y 3.
Después de esto, vemos un versus entre Xp y Vista. Comentamos que no se deben de utilizar nunca los usos de los sistemas para compararlos. Si el uso de CPU o el de memoria, al abrir un fichero por ejemplo, da igual la cantidad de memoria o CPU que consuma por lo que interesa es la rapidez con que se abre y la cantidad total de archivos que puedes abrir con distintos sistemas.Vemos un ejercicio de autoevaluacion de Vkthor. Las barras se utilizan para variables categóricas.Empezamos el tema 3: Solución de problemas en un sistema informático.
Cambiar parámetros en Linux: en proc podemos modificar todos los parámetros del sistema operativo como el tiempo de quantum, swap, etc. En windows es mediante el registro: regeditCon df vemos la carga de los discos. Los cuentas de la facultad están repartidas por ciclos, cada uno de los ciclos están en un disco distinto.La utilizacion de recursos es del tipo nominal es mejor. Libro recomendado: gestion del tiempo para administradores de sistemas.Ejercicio de autoevaluación 3.1:
Indice de suervivencia de pagina: cd proc. dirty_ratio (creemos)
Numero máximo de usuarios: cd proc.
find . -name "max" -print
No sabemos cual sería.
Y para terminar, vemos el video del dia
Después de esto, vemos un versus entre Xp y Vista. Comentamos que no se deben de utilizar nunca los usos de los sistemas para compararlos. Si el uso de CPU o el de memoria, al abrir un fichero por ejemplo, da igual la cantidad de memoria o CPU que consuma por lo que interesa es la rapidez con que se abre y la cantidad total de archivos que puedes abrir con distintos sistemas.Vemos un ejercicio de autoevaluacion de Vkthor. Las barras se utilizan para variables categóricas.Empezamos el tema 3: Solución de problemas en un sistema informático.
Cambiar parámetros en Linux: en proc podemos modificar todos los parámetros del sistema operativo como el tiempo de quantum, swap, etc. En windows es mediante el registro: regeditCon df vemos la carga de los discos. Los cuentas de la facultad están repartidas por ciclos, cada uno de los ciclos están en un disco distinto.La utilizacion de recursos es del tipo nominal es mejor. Libro recomendado: gestion del tiempo para administradores de sistemas.Ejercicio de autoevaluación 3.1:
Indice de suervivencia de pagina: cd proc. dirty_ratio (creemos)
Numero máximo de usuarios: cd proc.
find . -name "max" -print
No sabemos cual sería.
Y para terminar, vemos el video del dia
DYEC - 1 de Abril de 2008
Comienza la clase con la novedad de que tenemos a la tele grabando nuestra clase.
Vemos un profiler del profesor mientras Antares reponde a unas preguntas para la TV.
Al hacer una mejora en un programa con un profiler lo importatnte es que el tiempo total al final sea menor que el tiempo original.Vemos un extraño lenguaje llamado brainfuck que solo tiene como instrucciones los simbolos lógicos.Vemos unas paginas sobre IP sobre palomas mensajeras (IP over avian carriers).VKthor nos explica como ha realizado su practica 2. Despues vemos ejercicios de autoevalizacion de tupakamaru. Las metricas coreclock y merclock no son unas buenas medidas, porque no podemos fiarnos de lo que nos diga el fabricante. La realción calidad/precio, sobre calidad es mas es mejor y precio menos es mejor.Seguimos con la teoria:
Entramos en /proc que es un flesystem del kernel. Dentro de proc estan todas las estructuras de datos del kernel.diskstats: para ver la utilizacion de los discos.
Vemos otros monitores de sistemas: vmstat 10 10. Las 3 primeras columnas se refieren a procesos, esperando ejecutarse, bloqueado, y swapeados. Las 3 columnas siguientes se refieren a memoria. La 2 siguientes son entradas en swap y salidas de swap. Las 2 siguientes son bloques escritos y leidos. In es interrupciones.Cs son los cambios de contexto por segundo. Ver man vmstat. Ejecutamos un programa y utilizando vmstat vemos los cambios en el sistema.
Kasicguard es un monitor para KDE.La utilizacion de la CPU es un factor y por lo tanto no debemos incluirlo....Empezamos el tema 2.Graficos de kiviat: magnitudes de menor es mejor y mayor es mejor
Vemos un profiler del profesor mientras Antares reponde a unas preguntas para la TV.
Al hacer una mejora en un programa con un profiler lo importatnte es que el tiempo total al final sea menor que el tiempo original.Vemos un extraño lenguaje llamado brainfuck que solo tiene como instrucciones los simbolos lógicos.Vemos unas paginas sobre IP sobre palomas mensajeras (IP over avian carriers).VKthor nos explica como ha realizado su practica 2. Despues vemos ejercicios de autoevalizacion de tupakamaru. Las metricas coreclock y merclock no son unas buenas medidas, porque no podemos fiarnos de lo que nos diga el fabricante. La realción calidad/precio, sobre calidad es mas es mejor y precio menos es mejor.Seguimos con la teoria:
Entramos en /proc que es un flesystem del kernel. Dentro de proc estan todas las estructuras de datos del kernel.diskstats: para ver la utilizacion de los discos.
Vemos otros monitores de sistemas: vmstat 10 10. Las 3 primeras columnas se refieren a procesos, esperando ejecutarse, bloqueado, y swapeados. Las 3 columnas siguientes se refieren a memoria. La 2 siguientes son entradas en swap y salidas de swap. Las 2 siguientes son bloques escritos y leidos. In es interrupciones.Cs son los cambios de contexto por segundo. Ver man vmstat. Ejecutamos un programa y utilizando vmstat vemos los cambios en el sistema.
Kasicguard es un monitor para KDE.La utilizacion de la CPU es un factor y por lo tanto no debemos incluirlo....Empezamos el tema 2.Graficos de kiviat: magnitudes de menor es mejor y mayor es mejor
Suscribirse a:
Entradas (Atom)