Archivos Mensuales: noviembre 2010

Desidia …

Desidia, (del latín: desidia), significa negligencia, inercia, falta de responsabilidad por pérdida de atención y/o interés, falta de cuidado …

Considero que la desidia es un mal (junto con la procrastinación) que todos adolescemos de uno u otro modo; en mi caso es notable la capacidad que tengo para procrastinar cuando tengo encima muchas responsabilidades (lo cual siempre trae una ingente cantidad de problemas), por lo que puedo hablar desde la experiencia; sin embargo, es un mal corregible fácilmente, tan solo aplicándole un poco de interés a lo que hacemos … haciéndolo divertido, un hobbie, un reto …

En mi caso (computación), suelo imponerme retos (¿será que consigo la forma de optimizarlo?, ¿será que si lo hago de otro modo funciona mejor?, ¿será que esta idea es aplicable?) y eso le da un “buen sabor” al trabajo y hasta lo hace divertido, con lo cual hay pocas probabilidades de procrastinar en otras cosas …

Pero mi desidia no pasa de más allá de incumplir una reunión, retrasar un par de días un programa u olvidarme enviar un correo …

 

El problema es cuando la desidia de las personas se traslada al trabajo que ejercen, sobre todo cuando son funcionarios públicos, el problema del poder es que no puede compartir con la desidia, las consecuencias son catastróficas y los venezolanos aún pensamos “a muy corto plazo” como para entenderlo …

El plan del cuatrero …

Un amigo me enseñó a decirle “cuatrero” a todo aquél funcionario público que ya antes de las cuatro de la tarde está pensando en dejar sus labores hasta el día siguiente, para un funcionario regular esto es su día a día, pero el caso en cuestión ocurrió con un jefe de plataforma tecnológica de una institución pública, acostumbrado a “apagar su celular” luego que salía a las 4 de la tarde porque “su horario de trabajo había finalizado y no le gustaba que lo molestaran por cosas del trabajo”, ese día *precisamente* un grupo de hackers le hicieron un “deface” (ataque donde eliminan la página principal y agregan algún mensaje) a la página web de la institución y esta no fué reparada sino hasta la mañana siguiente, hora en la que el empleado encendió su celular y llegó apuradito a su trabajo …

Conozco jefes de plataforma que se quedan más allá de las 6 de la tarde, revisando logs, reparando errores y siempre tienen líneas directas para que los llamen en caso de fallas …

Desviando la atención …

No hay persona que bajando de Maiquetía no se haya topado con el puesto de la Guardia Nacional previo al Peaje y bajando a Caracas con el grupo de fiscales más policía luego del viaducto; si todos los días están ahí, ¿cómo es posible que hayan permitido el paso de un camión más alto que el límite permitido por el tunel de Boquerón-1?. En algún tiempo pasado existía antes de la entrada uno de esos tubos altos que demarcan la altura máxima permitida, en alguna reparación fue removido y nunca fue devuelto a su sitio; tal vez la empresa que lo quitó sufrió de desidia y jamás se preocupó por devolverlo …

Ahora, nos quedamos sin tunel por un buen tiempo …

La falta de inversión …

La falta de inversión a veces no es por falta de dinero, a veces es simple “desidia”, un “ups!, se me olvidó” es lo que podrías escuchar en la mente de los funcionarios que a su cargo podría estar la solución al problema …

12 años sin mantenimiento pasaron las bombas de aducción que alimentan de agua potable a la ciudad de Barquisimeto, ¡12 años!, la directiva simplemente lo admite y dice “ya lo estamos corrigiendo”, pero esa corrección pasa por dejar sin agua a más de un millón de personas …

Si eso no fué desidia de los funcionarios, no sé que será …

Igual pasa con el Metro de Caracas, según estadísticas de la propia evaluación interna de Metro, el 60% de las ruedas están rotas y con fallas, cada vagón “teóricamente” podría empujar el resto pero ya ninguno cuenta con motores de potencia, solo las locomotoras (y muchas de estas ya están en falla) …

El Metro de Caracas ha pasado muchos años en mano de la desidia de sus funcionarios y cuando la gente se queja del mal funcionamiento, entonces los que se quejan son acusados de terrorismo! …

Ya eso no es desidia, eso se llama desfachatez! …

Cuando la desidia cobra víctimas …

Como le pasó un amigo que mandó a arreglar su camioneta unos días antes de salir de viaje, el mecánico (como muchos) “se aburrió y le dió pereza” fijar correctamente la dirección y reemplazar todas las piezas …

En una autopista, la dirección se partió y el cardán rebotó en el piso, si mi amigo hubiera ido más rápido, se hubiera volcado y muerto y el mecánico ni habrá sabido la cantidad de muertes que ha causado su desidia …

En la salida de Morón, la alcaldía decidió poner un “Policia Acostado” (un reductor de velocidad), tal vez tardaron mucho en colocarlo (procrastinaron demasiado) y al empleado que le tocaba pintarlo dijo “neeee, mejor me lanzo un par de cervezas y mañana lo pinto”, esa misma noche, un señor que venía con su familia de la playa, no vió el negro y sin pintura policía acostado, saltó por encima e impactó de frente con el poste de la isla de la autopista muriendo en el acto.

¿sabrá el pintor la muerte que causó?

Una empresa contratista de la Alcaldía de Barquisimeto ganó la reparación del Liceo “Lisandro Alvarado”, al contratista se le ocurrió la genial “idea” de para ahorrar costos, abrir huecos en la pared del gimnasio para que cuando lloviera el agua “empozada” se discurriera hacia los lados de la edificación … (¿no era más fácil cambiar el techo del gimnasio para que no se empozara el agua?), esta medida “humedeció” las paredes de pisos inferiores …

Un día, una bedel llegó temprano a limpiar las instalaciones del Liceo, cuando el techo de la oficina donde se encontraba cedió por la humedad y le cayó encima …

Nadie se ha hecho responsable y el consejo comunal de la zona no quiere reclamar porque “los tildarían de guarimberos si protestan” …

Mientras la bedel se bate entre la vida y la muerte y nadie se hace cargo del problema …

Desidia en la falta de suministros …

Hay tantos ejemplos de la vida real, donde podríamos demostrar que la mayoría de los problemas del país acontencen por la falta de articulación y gestión entre los diversos organismos, y esta es debida a la falta de ganas e interés por parte de sus funcionarios …

En la última remesa de insumos al Hospital Central Antonio Maria Pineda, me cuenta una amiga enfermera, a los que hacen esta proveeduría desde el Ministerio de Salud, se les *olvidó* colocar gasas, adhesivo de cirugía y suturas …

Ayer ví a un señor de campo, con una herida de machete en su brazo, la cual fue “envuelta” en plástico de bolsa transparente y sujeto con Adhesivo de construcción (del que se compra en librerías) para evitar que se le infectara la herida …

En ese momento, me acordé de lo que me dijo mi amiga … =P

¿Conclusiones?

No se puede decir que la mayoría de los problemas del país son como consecuencia de la desidia, pero si la mayor parte (ejemplo: desde 2004 se sabía de las fallas del sistema eléctrico y no se tomaron correctivos hasta que empezaron las emergencias o que el Metro de Caracas no haya tomado correctivos -incluyendo el despido de su director- hasta que empezaron las fallas críticas y los colapsos); la desidia lleva a la irresponsabilidad y al retraso, esta causa la mayoría de los males que sufre el país, puesto que si notamos la tendencia, la mayoría de las cosas que el gobierno “arregla” es en emergencia, luego que las cosas colapsan y o se arreglan o se pierde …

pero, ¿alguien se ha sentado a pensar en las víctimas que genera nuestra desidia en cargos públicos? …

[Linux] El parche milagroso de Mike Galbraith en acción

En la página de Phoronix esta mañana leí un artículo sobre un “fascinante parche” para el kernel Linux que permite agregar “grupos de tareas” para una mejor respuesta del kernel ante eventos, haciendo que aplicaciones de escritorio sean agrupadas por TTY aumentando la interactividad del escritorio en alta carga.

La noticia fué replicada por la gente de muyLinux bajo el nombre de “El milagro de las 200 líneas de código” …

El parche …

Este parche fué creado por Mike Galbraith, un eterno colaborador del Kernel Linux (nick: efault) y su finalidad principal es otorgar la posibilidad de “agrupar tareas” en las TTY para que el CPU pueda “procesar en lote” todo ese grupo de tareas de una manera más rápida, aprovechando el procesamiento “en paralelo” *casí* todas las tareas relativas al uso de escritorio (sobre todo en el rendering de video) se ven beneficiadas.

¿Cómo funciona?

Cuando una tarea se ejecuta, esta genera un “GROUP” de manera automática donde todos los childs (hijos) comparten el “task group” y este un único tty. El parche de hecho es una “prueba de concepto” de una idea que Linus Torvalds había propuesto sobre el comportamiento de los task groups y queda abierta a mejoras de todo tipo.

Para ser una prueba de concepto (sólo 200 líneas de código) se desempeña bastante bien.

¿Dónde y cómo implementarlo?

El parche aún se encuentra en pruebas y no ha sido empaquetado en ningún lado, se encuentra como respuesta a un correo de discusión de Linus Torvalds acá, y sólo puede ser implementado en kernels donde la gestión de carga de trabajo de las TTY existe (> 2.6.37), yo he descargado y copiado el parche acá:

http://anyhub.net/file/W_n-rfc-rft-v3-sched-automated-per-tty-task-groups.patch.tar.bz2

De donde lo pueden bajar limpio y sin inconvenientes.

He descargado el kernel 2.6.37-rc2 de la página de kernel.org, lo descomprimo para compilarlo “de la manera habitual”, sin embargo:

Ejecutamos:

make mrproper

Y la copia de las opciones “por defecto”

make oldconfig

Ahora aplicaremos el kernel, para ello lo descomprimimos en la raíz de /usr/src, nos movemos a la carpeta del kernel:

cd linux-2.6.37-rc2/

Y ejecutamos el parche:

patch -p1 --dry-run < ../RFC-RFT-v3-sched-automated-per-tty-task-groups.patch

Opciones habilitadas en el Kernel:

Ejecutando make menuconfig o make gconfig (si están en gnome) activaremos las siguientes opciones del Kernel Linux:

En “General Setup”:

Kernel compression mode:
LZO (el más rápido en descomprimir)

Para que el kernel se descomprima rápidamente pueden activar el modo de compresión LZO, pero requieren instalar el siguiente paquete:

aptitude install lzop
Enable Block Layer > IO Schedulers > CFQ I/O Scheduler > CONFIG_CFQ_GROUP_IOSCHED

Esto habilita el I/O scheduler por grupos (CFQ_GROUP_IOSCHED)

Control Group Support (CONFIG_CGROUPS):
Namespace cgroup subsystemFreezer cgroup subsystemDevice Controller for cgroups
CPUset support > include legacy

Precisamente la opción que incorpora el parche, los CGROUPS y su control.

Resource counters > Memory Resource controller > MRC for Swap Extension
Group CPU Scheduler (CONFIG_CGROUP_SCHED)
Group Scheduling for SCHED_OTHER
Group Scheduling for SCHED_RR/FIFO

Con esto, habilitamos todos los tipos de sheduler basado en grupos.

Block IO Controller
Default I/O scheduler
CFQ

Opciones que colaboran con el parche.

Processor type and features > Preemption Model > Preemptible Kernel (low-latency desktop)

Requerido, para que podamos contar con un kernel Preemtivo. (de baja latencia).

MTRR support > MTRR Cleanup support
Timer Frequency > 1000 Hz

Otras opciones que colaboran con el performance del kernel Linux.

Compilando

Compilamos de la manera usual:

  • make all
  • make modules
  • make modules install
  • make install
  • mkinitramfs -o /boot/initrd.img-2.6.37-rc2-amd64 /lib/modules/2.6.37-rc2-amd64

Y actualizamos nuestro grub para que agregue la entrada del kernel:

update-grub2

y Listo, ahora, a probar el kernel.

Pruebas

Aun cuando hay pruebas más especializadas (como el interbench diseñado por Con Kolivas) yo he hecho una simple prueba (repetible por cualquiera) y que demuestra los beneficios directos del tunning; en este caso, he comprobado con 3 Kernel Linux y diversos modos.

Como nota adicional, mi equipo es:

Linux lexotanil 2.6.37-rc2amd64 #2 SMP PREEMPT Tue Nov 16 16:32:42 VET 2010 x86_64 GNU/Linux

Es un Debian Squeeze, tiene servicios cargados (openldap, postgresql, mysql) y utilidades de escritorio (compiz-fusion, gnome-applets, metacity como gestor, rendering habilitado según guía en este mismo blog) por lo que este parche *podría* en teoría, ser muchisimo más beneficioso para gente con equipos basados en distribuciones Desktop (Ubuntu, Trisquel), que mi equipo que es un servidor, sin embargo, el incremento de rendimiento fue brutal!.

A este equipo se le han realizado los siguientes cambios, con el fin de mejorar su performance:

En la primera prueba, se probó en un Kernel “genérico Debian” sin ninguna modificación al equipo:

Kernel genérico, sin 3D ni MTRR:

glxgears -info
GL_RENDERER   = Software Rasterizer
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Mesa Project
1494 frames in 5.0 seconds = 298.796 FPS
1582 frames in 5.0 seconds = 316.213 FPS
1616 frames in 5.0 seconds = 323.090 FPS

Los tiempos en promedio, son unos 300 FPS.

Kernel genérico, sin aceleración 3D (pero corrección MTRR activa):

glxgears -info
GL_RENDERER   = Software Rasterizer
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Mesa Project
2277 frames in 5.0 seconds = 455.288FPS
2314 frames in 5.0 seconds = 462.779 FPS
2251 frames in 5.0 seconds = 450.191 FPS

Mismo kernel, pero con el MTRR corregido (mejora del 10%).

Con aceleración 3D, sin parche de Mike:
glxgears -info
GL_RENDERER   = Mesa DRI Intel(R) 965GM GEM 20091221 2009Q4
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Tungsten Graphics, Inc
3618 frames in 5.0 seconds = 723.600 FPS
3448 frames in 5.0 seconds = 689.600 FPS
3511 frames in 5.0 seconds = 702.200 FPS

Con 3D y MTRR corregido, el rendimiento en el kernel “genérico” es notable (promedio: 700 FPS).

Kernel con parche realtime (RT Linux): 2.6.33.7-rt29-amd64

GL_RENDERER   = Mesa DRI Intel(R) 965GM GEM 20091221 2009Q4
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Tungsten Graphics, Inc
3418 frames in 5.0 seconds = 683.600 FPS
3483 frames in 5.0 seconds = 696.600 FPS
3498 frames in 5.0 seconds = 699.460 FPS

Este Kernel (2.6.33-7 con parche RT de RT-Linux) lo uso para transmitir por radioGNU en modo tiempo-real.

Parche de Mike Galbraith; Kernel 2.6.37-rc2-amd64 con parche:

glxgears -info
GL_RENDERER   = Mesa DRI Intel(R) 965GM GEM 20091221 2009Q4
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Tungsten Graphics, Inc
5707 frames in 5.0 seconds = 1141.172 FPS
6153 frames in 5.0 seconds = 1230.600 FPS
6280 frames in 5.0 seconds = 1255.749 FPS

Como vemos, este parche incrementa en más del 70% la respuesta del Kernel a eventos como dibujado de pantalla, scroll, renderizado de video, etc.

Un screenshot acá:

En el screenshot se ve:

  • Chromium browser: con un video de youtube y otro con el FishIE Tank de HTML5
  • Firefox con unas 15 pestañas abiertas
  • Icedove con mis 3 buzones IMAP abiertos
  • GLXGears
  • Mplayer mostrando otro video
  • Una consola de gnome-terminal con 5 pestañas
  • un editor de texto (mi bitácora)
  • Gnome con Compiz-Fusion activado
  • Varias ventanas de nautilus

Como verán, la respuesta del kernel nunca fué poner el CPU en on-demand (1.6 Ghz) no fué necesario, ya que la carga paralelizada en Debian hizo que el CPU nunca llegara a más del 90% de su carga.

Nota: no hagan caso de la temperatura, vivo en la ciudad de Barquisimeto y hoy fué un día extremadamente caluroso (por encima de 32 grados centígrados). =P

Conclusiones

Hice pruebas y benchmarks también con el interbench de Con Kolivas, que aunque confirman los resultados acá expuestos, sería muy largo explicar el test cuando un glxgears reportaría iguales resultados (una mejora notable en la respuesta del equipo).

Espero hagan sus propias pruebas y permitan dar por sentado que este parche representa el futuro del alto rendimiento en Linux PREEMPT para usuarios comunes y corrientes de escritorio.

A %d blogueros les gusta esto: