Moviendo DyEC

Practica Final

2008-07-06T15:58:00.000-07:00

Evaluación de ordenadores como servidores HTTP

Servidor Saturado from LP-Spain on Vimeo.

Objetivo de la evaluación

En la web de la Paqui han aumentado drásticamente las visitas, el servidor web que actualmente tenemos no es capaz de aguantar semejante carga y se encuentra totalmente saturado. Asimismo tenemos disponibles varias maquinas para montar este servidor web (El famoso MEGA3, el GIGA4 y el Ogabanis (agradecimientos a Alberto Ogaban por la colaboración) ).

El objetivo es encontrar el sistema para el servidor web (que hará uso de BD) que pueda procesar el mayor número de peticiones sirviéndolas en un tiempo razonable.

El servicio del sistema es actuar de servidor web. El servidor web se compone de un servidor Apache2 con soporte para PHP5 y otro servidor MySQL 5.0. Un resultado válido para el sistema sería servir la página web.

Las métricas que usaremos serán:

Número de páginas servidas por segundo

Tiempo en servir una página (en ms)

La relación entre páginas servidas por segundo y el tiempo en servir una página (o como lo denomino: factor de carga veloz).

Los parámetros que pueden afectar a las prestaciones son: ejecuciones paralelas de otros programas o servicios del sistema, número de peticiones que se están atendiendo en un mismo momento, número total de peticiones y carga de la red

El factor a estudiar será la media por peticiones simultaneas del factor de carga veloz (el factor de carga veloz es la relación entre páginas cargadas por segundo y la media de tiempo de carga de estas páginas), este valor se trata de una estimación.

La técnica de evaluación se hará como medición de un sistema real mediante la herramienta Apache Benchmark. Para las distintas evaluaciones esta herramienta se ejecutará siempre en una maquina que no forma parte del sistema y que esta bajo la misma red local de 100Mbps que el sistema a evaluar. Haciéndolo de este modo tenemos aislado el servidor del programa de bechmark de modo que este no puede afectar a las mediciones, aunque sabemos que las condiciones de la red si pueden afectar a las mediciones pero... es un servidor web!, se conoce que esto es más aproximado a una situación real.

La técnica de evaluación es medición

La carga de trabajo a la que se va a someter cada sistema es a:

10 peticiones simultaneas para un número de peticiones totales de 500, 1000, 1500 y 2000

50 peticiones simultaneas para un número de peticiones totales de 500, 1000, 1500 y 2000

100 peticiones simultaneas para un número de peticiones totales de 500, 1000, 1500 y 2000

Diseño del experimento

El experimento se centra en una de las webs de la Paqui que más cargan y que, asimismo, más carga genera sobre el servidor: la portada de su blog, de modo que lo primero que definimos es que todos los experimentos se van a centrar en la carga del blog de la Paqui (concretamente la copia de BD correspondiente al 1 de Julio).

El experimento consiste en, para cada uno de los sistemas, ejecutar Apache Benchmark con las distintas cargas de trabajo a las que se va a ver sometido. Un ejemplo de linea de comandos puede ser el siguiente:

ab -n 500 -c 10 http://192.168.0.34/paquiblog/index.php
ab -n 1000 -c 10 http://192.168.0.34/paquiblog/index.php
ab -n 1500 -c 10 http://192.168.0.34/paquiblog/index.php
ab -n 2000 -c 10 http://192.168.0.34/paquiblog/index.php
ab -n 500 -c 50 http://192.168.0.34/paquiblog/index.php
ab -n 1000 -c 50 http://192.168.0.34/paquiblog/index.php
ab -n 1500 -c 50 http://192.168.0.34/paquiblog/index.php
ab -n 2000 -c 50 http://192.168.0.34/paquiblog/index.php
ab -n 500 -c 100 http://192.168.0.34/paquiblog/index.php
ab -n 1000 -c 100 http://192.168.0.34/paquiblog/index.php
ab -n 1500 -c 100 http://192.168.0.34/paquiblog/index.php
ab -n 2000 -c 100 http://192.168.0.34/paquiblog/index.php

Tomamos de cada medida los resultados para páginas cargadas por segundo y el tiempo medio de carga de cada página. Dividimos estos valores ( páginas por segundo / tiempo medio de carga ) y agrupamos los valores que obtenemos en tres grupos (10, 50 y 100 peticiones simultaneas por segundo) y a cada grupo le hacemos la media, con lo que obtenemos una media por peticiones simultaneas del factor de carga veloz (Si, es un lío pero a continuación explico por qué hago todo esto y en el análisis de datos la tabla de datos recogidos se autoexplica).

Anotaciones del experimento

Factor de carga veloz: Este factor tiene sentido en cuanto a que relacionamos los dos valores importantes para el servidor: ¿Cuántas páginas puede cargar en un tiempo? ¿El usuario tendrá que esperar mucho para ver su página? de modo que, estudiando este factor podemos de entre los sistemas seleccionar el que tenga el mejor compromiso sobre estas dos preguntas.

Media por peticiones simultaneas del factor de carga veloz: En la experimentación dados los factores de carga veloz para iguales peticiones simultaneas los unificamos mediante una media. Esto lo hacemos por que nos interesa conocer más sobre las peticiones simultaneas que sobre el número total de peticiones, que realmente poco afectan al experimento y casi se podrían eliminar pero se quedan para abarcar un determinado margen en que puedan reflejarse posibles situaciones que puedan darse.

Análisis e interpretación de datos

Realizamos análisis sobre tres sistemas.

Sistema MEGA3

Obtenemos los siguientes resultados:

Sistema GIGA4

Obtenemos los siguientes resultados:

Sistema Ogabanis

Obtenemos los siguientes resultados:

En este caso concreto los analisis para 50 y 100 peticiones simultaneas han dado error, el sistema se quedaba congelado y Apache Benchmark finalizaba su ejecución por error sin haber concluido los análisis.

Interpretación de los datos

A simple vista se puede observar que el Sistema GIGA4 tiene resultados mejores en todos los campos, siguiéndole el Sistema Ogabanis que desgraciadamente falla al aumentar la carga de usuarios simultáneos y por último el Sistema MEGA3 que a simple vista no es lo suficientemente potente para este cometido.

Para poder observar claramente las diferencias entre los sistemas creamos los índices, que nos lo dejarán claro:

	MEGA3	GIGA4	Ogabanis	IMEGA3	IGIGA4	IOgabanis
10 pet. simultaneas	0.00075	0.01023	0.00200	1	13.64	2.66
50 pet. simultaneas	0.00016	0.00216	Error	1	13.5	Error
100 pet. simultaneas	0.00008	0.00114	Error	1	14.25	Error
Media aritmética				1	13.79	Error
Media geométrica				1	13.64	Error

Resultados

Observamos los datos representados en la siguiente gráfica

Podemos observar que GIGA4 vuelve a ganar (al igual que en anteriores trabajos), esta vez con una enorme diferencia con respecto a los demás. El sistema base tiene un índice 1 y el mejor sistema es GIGA4 con índice de 13.64 para el objetivo planteado. Por tanto el sistema que cumple mejor con nuestros objetivos es el sistema GIGA4.

Y esto no termina aquí...

Servidor Saturado - Final from LP-Spain on Vimeo.

Practica 6

2008-06-28T13:30:00.000-07:00

Objetivo del benchmark

Durante nuestro trabajo en la MASA un cientifico ~~loco~~ nos ha llamado a los servicios de informática:

-Servicios de informática de la MASA, digame.

-Hola, soy un científico, necesito un equipo que me haga muy eficientemente sumas de decimales, sumas de enteros y su escritura de cada suma en disco. Son más importantes las sumas de decimales, serán un 99% del total de los cálculos.

-Ya, si aquí todo el mundo pide... pero justifiqueme su necesidad, por que a JJ le gusta que las cosas estén bien justificadas.

-Queremos hacer unos cálculos, sumas de puntos de ejes de coordenadas X e Y, con una precisión de un decimal y cada uno de los resultados se escriben en disco.

-Bueno, ¿entonces todas las sumas son decimales no?

-No, los ".0" se cuentan como enteros, por eso como ya te digo hay un 1% de sumas de enteros. Creemos que con esto hallaremos si existe agua en Marte.

-Pues para esta tarde te lo tengo que a mi me gusta mucho el agua.

De modo que tenemos el objetivo de encontrar, entre varios equipos que tenemos disponibles, el que mejor hará este trabajo. Para ello elaboramos un Benchmark con el que obtener, de cada uno, el que mejor hará el trabajo requerido.

Métricas a usar

Vamos a usar 2 métricas:

Cálculos por milisegundo (Para los casos de cálculos de sumas de enteros y de decimales)
Caracteres por milisegundo (para el caso de escritura en disco)

Sobre el benchmark

El benchmark va a devolver tres resultados, siendo estos:

Cálculos de enteros por cada milisegundo: Esto se realiza calculando el tiempo total en segundos que tardan en realizarse 10000000000 sumas de números enteros, posteriormente esto se pasa a la unidad métrica que tenemos asignada siendo el resultado aproximado.

Cálculos de números con decimales por cada milisegundo: Esto se realiza calculando el tiempo total en segundos que tardan en realizarse 10000000000 sumas de números con decimales, posteriormente esto se pasa a la unidad métrica que tenemos asignada siendo el resultado aproximado.

Caracteres escritos en disco por milisegundo: Esto se realiza calculando el tiempo total en segundos que tardan en escribirse 30000000000 caracteres en un archivo ¡Cuidado, el archivo es de 2Gb y no se borra automágicamente!, posteriormente esto se pasa a la unidad métrica que tenemos asignada siendo el resultado aproximado.

El código fuente del benchmark se puede encontrar aquí
NOTA: Se recomienda no abrir el fichero incluido archivo.cpp por que por su tamaño colgaría cualquier editor/lector, este incluye la declaración de la cadena de caracteres inicial para la escritura en disco en bloques grandes.

La linea de comandos para compilar y ejecutar sería:

g++ benchmark.cpp -o benchmark
./benchmark

Resultados

Equipo 1

Benchmark
CPU Enteros: Cálculos/ms: 208333
CPU Decimales: Cálculos/ms: 204081
DISCO Escritura: Caracteres/ms: 211267

Equipo 2

Benchmark
CPU Enteros: Cálculos/ms: 303030
CPU Decimales: Cálculos/ms: 238095
DISCO Escritura: Caracteres/ms: 312500

Equipo 3

Benchmark
CPU Enteros: Cálculos/ms: 294117
CPU Decimales: Cálculos/ms: 232558
DISCO Escritura: Caracteres/ms: 731707

Suponemos que, por cada suma que se realiza, se escriben 5 caracteres (3 enteros + el punto separador + 1 decimal) en ese caso. De modo que todas las medidas de escritura en disco serian de 5 caracteres por milisegundo:

Equipo 1: 42253,4 (5Caracteres/ms)
Equipo 2: 62500 (5Caracteres/ms)
Equipo 3: 146341,4 (5Caracteres/ms)

Análisis de Resultados

	E1	E2	E3	IE1	IE2	IE3
CPU Enteros	208333	303030	294117	1	1,45	1,41
CPU Decimales	204081	238095	232558	1	1,16	1,11
Disco Escritura	42253,4	62500	146341,4	1	1,47	3,46
Media geométrica				1	1,35	1,75

Observamos que se da la característica en todos los equipos de que la velocidad de escritura limita los cálculos, por tanto en nuestra conclusión para este análisis obviaremos el factor de CPU para simplemente determinar qué equipo es el más adecuado determinado únicamente por la capacidad de escritura.

El sistema base tiene un índice 1 y el mejor sistema es el Equipo 3 con índice de 3,46 para el objetivo planteado.

Practica 5

2008-05-11T06:33:00.000-07:00

Objetivo de la mejora de prestaciones

Tenemos una página web en la que preveemos que el dia X aumentarán drasticamente las visitas. Hasta el momento teniamos un servidor desde hace un par de años (denominado MEGA3) y ahora nos han traido uno nuevo (denominado GIGA4).

El objetivo es encontrar la configuración adecuada para, con los recursos disponibles, montar un servidor web (que hará uso de BD) de tal modo que maximicemos el número de peticiones a la web que se pueden atender dentro de un corto periodo de tiempo.

El servicio del sistema es actuar de servidor web. El servidor web se compone de un servidor Apache2 con soporte para PHP y otro servidor MySQL 5.0

La métrica que usaremos será número de páginas servidas por segundo

Los parametros que pueden afectar a las prestaciones son: ejecuciones paralelas de otros programas o servicios del sistema, número de peticiones que se están atendiendo en un mismo momento, número total de peticiones, carga de la red (según el caso) y la página web a servir.

El factor a estudiar será el número de páginas servidas por segundo, este valor se trata de una estimación.

La técnica de evaluación se hará como medición de un sistema real mediante la herramienta Apache Benchmark. Para las distintas evaluaciones esta herramienta se ejecutará siempre en la misma maquina en la que esté ejecutandose el servidor web apache, hay que destacar sobre esto que quizás no sea una forma del todo buena de hacerlo, lo ideal seria disponer de un tercer ordenador en red local para ejecutar Apache Benchmark pero como no disponemos de este lo hacemos de esta forma y asumimos que afectará negativamente a todas las medidas aproximadamente del mismo modo.

La carga de trabajo a la que se va a someter el sistema es a: 5000 peticiones con un máximo de 10 peticiones al mismo tiempo

Pasos en el análisis y mejora de prestaciones

1: Ejecutar Apache Benchmark en la maquina en la cual esté instalado Apache.

ab -n 5000 -c 10 http://192.168.0.34/ruta.php?pag=ruta&id=1

con 5000 peticiones, 10 peticiones al mismo tiempo y una página web (siempre la misma) basada en PHP+MySQL.

2: Tomamos los resultados.

Resultado de las medidas antes y después de la mejora de prestaciones

Vamos a hacer cuatro analisis con distintas configuraciones del sistema, con ello determinaremos cual de las configuraciones nos ofrece mejores prestaciones y con ello elegiremos la configuración más adecuada.NOTA: Las pruebas 2 y 3 tienen un factor que no tienen la 1 ni la 4 que es la conexión de red, las pruebas se han realizado sobre una red local Ethernet de 100Mbps sin carga inicial y con un "hop" entre equipos.

Caso 1: Apache2 y MySQL ejecutándose desde el servidor MEGA3

Este es el sistema "antes", tal como ha estado siempre el servidor web.
Para este caso la salida de Apache Benchmark es: Requests per second: 77.78 [#/sec] (mean)

Caso 2: Apache2 ejecutándose en MEGA3 y MySQL en GIGA4

La idea es repartir la carga del sistema en dos maquinas, esto es algo que incluso se ha comentado en clase de DyEC como método para aumentar las prestaciones de un servidor web.
En este caso: Requests per second: 140.63 [#/sec] (mean). El número ha aumentado, parece que dedicar la maquina GIGA4 a administrar la Base de Datos produce mejoras.

Caso 3: Apache2 ejecutándose en GIGA4 y MySQL en MEGA3

El mismo caso de antes pero al revés, esto lo hacemos por que no sabemos a priori cómo se comportará cada maquina según lo que ejecuten.
En este caso: Requests per second: 27.46 [#/sec] (mean). Unos resultados desastrosos, el sistema estaría peor que al principio.

Caso 4: Apache2 y MySQL en GIGA4

Aqui se deja toda la carga para la maquina nueva.
En este caso: Requests per second: 375.61 [#/sec] (mean). Observamos cómo la maquina GIGA4 se las apaña muy bien ella solita siendo la configuración que ofrece mayores prestaciones en cuanto a peticiones por segundo.

Resultados

Los datos hablan por sí solos y se pueden ver claramente en un gráfico:

A tesón de los resultados queda claro que la configuración que cumple nuestro objetivo dentro de los cuatro casos que hemos descrito y analizado es la cuarta, por tanto esta será la elegida.

Y tienes que darme el punto adicional porque...

Con esta practica he conocido la configuración adecuada para servir páginas webs con los equipos que tengo disponibles en mi casa, próximamente tendrá un uso real puesto que se de buena tinta que un proyecto en el que participo (la Paqui) tendrá un incremento de peticiones al servidor los días en los que estrenemos la segunda película.
Que sino por lo menos dame el punto por haber cargado con el MEGA3 hasta mi cuarto, instalarlo, configurarlo, etc.

Practica 2: Monitor de sistema para Ubuntu, GNU/Linux: Conky

2008-05-11T06:31:00.000-07:00

Conky es un monitor del sistema local totalmente configurable, está hecho para trabajar gráficamente sobre el fondo de escritorio (estando de este modo siempre presente sin "estorbar"). Escogí probar este monitor por comentarios agradables a su favor en varios blogs

Instalación
En Ubuntu 7.04 su instalación se efectua simplemente poniendo en consola:

sudo apt-get install conky

Desde este momento se puede ejecutar con su configuración predeterminada:

conky

(ejecutar con la opción -o en caso de que queramos que aparezca en una ventana)

Configuración
Como ya hemos dicho es un monitor "altamente configurable" y es que toda su interfaz se configura en base a un fichero de texto en el que describimos lo que queremos que aparezca y cómo queremos que aparezca, este fichero admite variables propias del programa y scripts del usuario (que puede programarse uno en caso de que las funciones propias no cubran nuestras necesidades). De este modo el usuario puede diseñar el monitor del sistema a su medida sin que necesariamente tenga que ser un "experto".

Desde la página del proyecto podemos descargar ejemplos de configuración. En mi caso he construido la siguiente interfaz a partir de uno de los ejemplos:

En el que se han usado, entre otras, las siguientes variables propias de conky:

$nodename: Nombre del equipo
$kernel: Versión del Kernel
$uptime: Tiempo UP
$loadavg: Cargas del sistema
$cpu%: Porcentaje de uso de la CPU
${cpubar}: Muestra gráfica en una barra del uso de CPU
${cpugraph cpu0 32,309 000000 7f8ed3}: Muestra gráfica en linea del tiempo del uso de la CPU0
$mem/$memmax: Memoria RAM usada/Memoria RAM total
$processes: Procesos
$running_processes: Procesos en ejecución
${downspeed eth0}: Velocidad de descarga del dispositivo eth0
${upspeed eth0}: Velocidad de subida del dispositivo eth0
${tcp_portmon 1 65535 count}: Conexiones TCP
${fs_free /mnt/fat32/}: Capacidad libre en el dispositivo de almacenamiento /mnt/fat32
${fs_size /mnt/fat32/}: Capacidad total en el dispositivo de almacenamiento /mnt/fat32
${fs_bar /mnt/fat32/}: Representación en una barra de la capacidad en el dispositivo de almacenamiento /mnt/fat32
${top name 1} ${top pid 1} ${top cpu 1} ${top mem 1}: Nombre, PID, Uso de CPU y uso de memoria del proceso que está usando más CPU
${top_mem name 1} ${top_mem pid 1} ${top_mem cpu 1} ${top_mem mem 1}: Nombre, PID, Uso de CPU y uso de memoria del proceso que está usando más Memoria
$diskio: Uso de la Entrada/Salida
${diskiograph 32,309 000000 7f8ed3 5000}: Muestra gráfica de la Entrada/Salida
${tail /var/log/apache2/access.log 15}: Muestra las últimas 15 lineas del log de accesos de Apache

A lo que hay que agregar la funcionalidad proveniente de los scripts que podemos construir e integrar en el programa.

Adjunto el fichero de configuración:

background yes
font 7x13
use_xft no
on_bottom yes

mpd_host 192.168.150.2
mpd_port 6600

update_interval 1.0

total_run_times 0

own_window no

own_window_transparent no

double_buffer yes

minimum_size 280 5

draw_shades yes
draw_outline no
draw_borders no
stippled_borders 8
border_margin 4
border_width 1

default_color black
default_shade_color black
default_outline_color black

alignment top_right

maximum_width 500

gap_x 12
gap_y 12

no_buffers yes

uppercase no

cpu_avg_samples 2
net_avg_samples 2

override_utf8_locale no

use_spacer no

# stuff after 'TEXT' will be formatted on screen

TEXT
${color #5b6dad}$nodename   linux-$kernel${alignr}${time %T}

${color #5b6dad}System:
${color #5b6dad} Uptime:${color #7f8ed3} $uptime ${color #5b6dad}- Load:${color #7f8ed3} $loadavg
${color #5b6dad} CPU Frequency:${color #7f8ed3} $freq_dyn_g ${color #5b6dad} Maximum:${color #7f8ed3} $freq_g
${color #5b6dad} CPU Usage:${color #7f8ed3} $cpu% ${cpubar}
${color #000000}${cpugraph cpu0 32,495 000000 7f8ed3}
${color #000000}${cpugraph cpu1 32,495 000000 7f8ed3}
${color #5b6dad} RAM Usage:${color #7f8ed3} $mem/$memmax - $memperc% ${membar}
${color #5b6dad} Swap Usage:${color #7f8ed3} $swap/$swapmax - $swapperc% ${swapbar}
${color #5b6dad} Processes:${color #7f8ed3} $processes  ${color #5b6dad}Running:${color #7f8ed3} $running_processes

${color #5b6dad}Networking:
 ${color #5b6dad}Down:${color #7f8ed3} ${downspeed eth0} k/s${color #5b6dad}${offset 160}Up:${color #7f8ed3} ${upspeed eth0} k/s
${color #000000}${downspeedgraph eth0 32,245 000000 7f8ed3} ${color #000000}${upspeedgraph eth0 32,245 000000 7f8ed3}
 ${color #5b6dad}Address: ${color #7f8ed3}${addr eth0}${alignr}${color #5b6dad}TCP Connections: ${color #7f8ed3}${tcp_portmon 1 65535 count}

${color #5b6dad}File Systems:
 ${color #5b6dad}/ ${color #7f8ed3}${fs_free /}/${fs_size /} ${color #7f8ed3}${fs_bar /}
 ${color #5b6dad}FAT32 ${color #7f8ed3}${fs_free /mnt/fat32/}/${fs_size /mnt/fat32/} ${color #7f8ed3}${fs_bar /mnt/fat32/}
 ${color #5b6dad}Archivos ${color #7f8ed3}${fs_free /mnt/archivos/}/${fs_size /mnt/archivos/} ${color #7f8ed3}${fs_bar /mnt/archivos/}
 ${color #5b6dad}SAExt3 ${color #7f8ed3}${fs_free /mnt/saext3/}/${fs_used /mnt/saext3/} ${color #7f8ed3}${fs_bar /mnt/saext3/}            

${color #5b6dad}Name              PID     CPU%   MEM%
${color #7f8ed3} ${top name 1} ${top pid 1} ${top cpu 1} ${top mem 1}
${color #7f8ed3} ${top name 2} ${top pid 2} ${top cpu 2} ${top mem 2}
${color #7f8ed3} ${top name 3} ${top pid 3} ${top cpu 3} ${top mem 3}
${color #5b6dad}Mem usage
${color #7f8ed3} ${top_mem name 1} ${top_mem pid 1} ${top_mem cpu 1} ${top_mem mem 1}
${color #7f8ed3} ${top_mem name 2} ${top_mem pid 2} ${top_mem cpu 2} ${top_mem mem 2}
${color #7f8ed3} ${top_mem name 3} ${top_mem pid 3} ${top_mem cpu 3} ${top_mem mem 3}

Disk IO: $diskio
${diskiograph 32,495 000000 7f8ed3 5000}

${tail /var/log/apache2/access.log 15}

Este fichero debe ser llamado a la ejecución del programa del siguiente modo:

conky -c fichero

Siendo fichero la ruta al fichero Archivo de configuración
En este blog hay también un fichero de configuración interesante para conky.

Valoración
Conky es muy util y muy adaptable para su uso en el sistema local, su funcionamiento es simple (tan simple que no existe iteracción con el usuario), consume unos recursos aceptables (alrededor de 4% en mi equipo) y admite scripts que hayamos programado nosotros extendiendo así su utilidad a nuestra capacidad de programación, tiene la desventaja de que la configuración se establece a través de un fichero de texto plano y de que pega parpadeos cuando tiene que cargar mucha información.

Arranque de Guadalinex VS Ubuntu

2008-03-04T05:18:00.000-08:00

A la prueba de tiempo de arranque comparando a ojo en cuanto al tiempo estos dos elementos:
-Guadalinex V4.1 en mi PC antiguo (AMD a 1'8Ghz, 256Mb de RAM) recién formateado.
-Ubuntu V7.04 en mi PC nuevo (Características) con tiempo ya trabajando y ejecutando algunos servicios al inicio.

Ha tardado menos tiempo Guadalinex en mi PC antiguo (y que rabia que da xD).

Ejercicio autoevaluación Tema 1 Bloque 2

2008-02-27T00:15:00.000-08:00

Parece que es interesante el ejercicio de autoevaluación correspondiente a esta clase y a esta parte del temario.

1. Especificar en qué consistirían los 10 pasos de la sección 1.2 en el caso de la evaluación de alguno de los siguientes sistemas: un compilador, un proveedor de servicio ADSL, una tarjeta gráfica, una impresora.

Bueno, últimamente estoy mirando monitores para comprarme uno en condiciones así que me voy a salir un poco del tiesto y voy a hacer esta actividad para monitores.

Objetivos y definición del sistema: El objetivo principal es escoger un monitor cuya superficie de pantalla sea superior al actual y que se cumplan los demás requisitos (compatible con el software que usamos, tamaño del punto, tasa de refresco, etc) con el fin de poder trabajar comodamente a altas resoluciones (cualquier resolución que supere con un rango de 200px a 1024x768). El actual monitor puede considerarse como el típico monitor TFT de 17'' que te regalan en un torneo de counter el día de la ETSIIT (o sea, que cualquiera lo supera y ponerme a describirlo es incluso imposible por que el modelo que tengo no existe en el catalogo xD). El objeto a evaluar es un monitor.
Servicios que ofrece: Visualización de píxeles, ajuste de brillo y contraste, modo de reposo, botón de encendido/apagado, auto-ajuste de la pantalla, conexión DVI estándar a tarjeta gráfica y ajuste del "aspect ratio".
Métricas: píxeles X píxeles (Resolución de la pantalla), ms (tasa de refresco), mm (tamaño del punto), ?? (contraste), cd/m2 (luminosidad), grados (ángulo de visualización), W (consumo máximo), pulgadas (superficie de la pantalla), kg (peso), mm X mm X mm (dimensiones), colores (nº de colores), Hz (frecuencia máxima)
Parámetros que pueden afectar a las mediciones: Subidas y/o bajadas de tensión, Capacidad de la tarjeta gráfica/PC/Software para representar diferentes resoluciones, colores, frecuencias,...
Factores a estudiar: [Todos los del punto 3]
Técnica de evaluación: Medición
Carga de trabajo: Representación de todo tipo de cartas de ajuste a distintas resoluciones
, 9. y 10. Se realizan tras estos otros pasos

Darse de alta en la asignatura

2008-02-26T13:00:00.000-08:00

for (i=0; i<=Un puñado de compañeros; i++){
  -Oye Fran, ¿tu estuviste el dia de la presentación de DEC?
  -Si, estuve.
  -Oye explicame qué es lo que hay que hacer para darse de alta.
  -Bueno, son muchas cosas...
  -Es que no me he enterado...
  -Es que no te ha salido de los eggs apuntar nada gañañazo
  -Perdona, no te he entendido
  -Que lo pondré en mi blog de la asignatura.
  -Vale
}

Y así es cómo surge el primer post de la asignatura dedicado a esos alumnos que se quedan de repente sin tinta en el boli y otros que no pudieron acudir.

Bien, esta asignatura el año pasado funcionaba mediante una plataforma muy chula y novedosa pero este año por falta de alguien que la mantenga vamos a usar varias cosas descentralizadas.

Lo primero de todo es darse de alta en la asignatura mediante esta web: http://geneura.ugr.es/~jmerelo/DyEC/cgi/alta.cgi. Para ello hay que introducir el DNI para luego rellenar los datos que pide y pulsar sobre actualizar.

Esta será además la web donde se entregarán las practicas, la practica se ha de entregar:
-Cómo un único archivo en formato HTML y denominado index.html
-o bien cómo un conjunto de ficheros unificados en un archivo .zip ó .tgz que ha de contener en su raíz un fichero index.html

Lo segundo es suscribirse a la lista de correo de la asignatura, para ello mandamos un email en blanco desde nuestra cuenta de correo habitual a dyec2004-subscribe ARROBA yahoogroups.com

Lo tercero, opcional y que va subiendo nota es seguir la metodología innovadora de clase por la que es famoso JJMerelo, estás son la participación con blogs y con wikis:

3.1Hacer ejercicios de auto evaluación mediante un blog: En esta asignatura existen en cada tema ejercicios de auto evaluación (vease tema 1). Estos ejercicios de auto evaluación se hacen en el blog de cada uno (si no tienes uno createlo).

La asignatura dispone de un agregador de blogs para que, tanto el profesor como nosotros, podamos ver todos los blogs: http://geneura.ugr.es/~jmerelo/DyEC/planet.cgi avisa al profesor para que agrege tu blog a este agregador o no podrá ver tus ejercicios!

3.2Participar en un Wiki: Los apuntes de clase son tomados por los alumnos y puestos a disposición de todos en un Wiki. El wiki es http://dyec-ugr.wikispaces.com/ (hay que darse de alta en wikispaces.com y posteriormente solicitar acceso al wiki). El profesor irá colgando la estructura o índice de lo que va a dar ese día y nosotros en la página de discusión tomaremos apuntes durante la clase.

Si no tienes portatil ve a las 17:57 al lado del aula 2.1 (en la segunda planta), espera a que llegue el profesor que pedirá portátiles para nosotros (al terminar la clase hay que devolverlo emm).

Con estos tres pasos podéis empezar a funcionar en la asignatura.

PD: Si te lías en WikiSpaces tomate tu tiempo para ver cómo funciona y/o aprende un poco de inglés. El sistema es fácil solo que el diseño lia un poco.