Como a la mayoría, si eres cliente de una línea de ADSL te habrás dado cuenta de que la velocidad real que alcanza la conexión muchas veces dista bastante de lo contratado con la operadora. Esto empezó a notarse cuando se popularizaron las ADSLs con velocidades superiores a los 3 Megas, especialmente con las famosas ofertashasta20 Megas…
Hay muchísimas causas que afectan a la velocidad final que se obtiene de una línea ADSL. Hay factores tanto internos a nuestra casa como externos; en esta primera entrega trataré de explicar cuales son las más comunes y cómo mejorar la instalación telefónica de nuestra casa a fin de conseguir la mayor velocidad posible.
Recientemente he visto la noticia de que planean introducir sistemas de protección anticopia (también conocidos como DRM) en la Nintendo DS. No es que esta noticia sea especialmente relevante, pero quiero aprovechar la ocasión para hablar más desde un punto de vista analítico que teórico, de la mayoría de protecciones comerciales disponibles en el mercado; empezando por la que oferta la empresa mencionada en la noticia, Metaforic, demostrando que la venta de aparente seguridad parece ser muy rentable.
Hace un par de semanas me encontré con este caso, necesitaba un programa para convertir un archivo PDF a formato Word y me encontré con una herramienta de la empresa VeryPDF que cumplía perfectamente con mis espectativas (PDF2Word).
En la página web reza que la aplicación tiene licencia GPL y me extrañó encontrarme con la típica ventana Nag de los programas shareware que te invita a registrarte.
Resulta que hace bastante tiempo que vengo utilizando esta herramienta en el trabajo, en su versión del año 1.997, y me mosqueaba bastante que al abrir el diseño de una tabla o simplemente ver los datos de la misma, la CPU se lanzase al 100% de uso (50% en mi caso ya que tiene hyperthreading).
Para más frustración, no se puede utilizar una versión más actualizada ya que supondría muchas modificaciones en el programa de la empresa; y por supuesto Microsoft ya no da soporte para este software.
Hace algunos días me dio por investigar esto utilizando el depurador OllyDbg y me encontré con que la aplicación ejecuta un bucle prácticamente infinito para actualizar la barra de herramientas de la ventana. En este bucle en ocasiones llama (o debería llamar) al API de Windows Sleep() para liberar los recursos consumidos. Si no es así, el consumo de la CPU se mantiene muy alto aun sin estar haciendo nada.
Estar llamando continuamente a Sleep() tampoco es lo más óptimo, por tanto el punto crucial de este sistema es el cuando llamar a esta función. Los ingenieros de Microsoft programaron este bucle utilizando otro API, GetTickCount() (que devuelve el tiempo desde que se arrancó el sistema), para medir el tiempo transcurrido desde la ultima vez que se dio una vuelta al bucle.
Si nos remontamos a la época de 1.997 con los Pentium entre 200 y 400 Mhz, esta claro que debía funcionar bastante bien, pero con los años se ha creado un bug en este algoritmo. Con las nuevas máquinas de 2 y 3 Ghz el bucle tarda 0 milisegundos en ejecutarse y con por culpa de eso, nunca llama a la función Sleep().
La solución ha sido modificar la comparación que se hace al llamar a GetTickCount() por otra que salte más veces:
Parche para Microsoft Access 97
Tenemos el espacio bastante limitado, asi que la comprobación será sencilla. El código nuevo lo que hace es llamar a la función Sleep() si el valor que devuelve GetTickCount() es par. La función Sleep() se llama para que espere 125 milisegundos, asi que se reducirán mucho las veces que se ejecuta el bucle.
Después de modificar la aplicación y probarla durante unos días, todo funciona correctamente, la toolbar se refresca bien y el consumo de la CPU es prácticamente 0 🙂
Actualización:
Buscando por Google, encontré este enlace a la Knowledge Base de Microsoft dando una explicación al respecto. En resumen, dicen que es normal que el access consuma el 100% durante unos 20 ~ 30 segundos después de entrar en modo reposo (tras abrir una tabla, minimizar el programa, pasar a modo diseño, etc…). Lo que no tienen en cuenta es que si trabajas activamente con el programa pasando de modo diseño a SQL, abriendo tablas y demás, se mantendrá fácilmente al 100% casi siempre.
La Fonera es un dispositivo muy versátil que viene con una distribución de Linux instalada por defecto. Si se le instala otra distribución más actualizada diseñada para dispositivos embebidos (generalmente se instala OpenWRT o bien DD-WRT) se abre un nuevo mundo de posibilidades. Tiene 14 mb de ram y unos pocos MB de espacio en la flash.En mi caso, despues de liberar la fonera e instalarle el OpenWRT Kamikaze, no tardé mucho en darme cuenta de que me iba a quedar pronto sin espacio para poder hacer cosas. Siguiendo la guía que está en el foro de Seguridad Wireless conseguí instalarle correctamente un lector de tarjetas SD.
Moví de sitio la antena a un lateral, recorté el conector de floppy para que entrase justito por la parte trasera al lado del conector de red y también me encontré con algunos problemas:
– puenteé los pines 3 y 4 (sólo hace falta uno de ellos, depende de si se usa OpenWRT o DD-WRT, lo ideal es probar con uno y si no funciona con el otro)
– puse la masa en el negativo del conector SW1, que está conectado tambien al casquillo del conector de red, pero que no está conectado a masa ¬.¬
Después de solucionar esto conseguí que funcionase, ahora tengo disponibles 512 mb de espacio en la Fonera.
Podeis ver las fotos de como ha quedado aquí:
El foro de Seguridad Wireless es muy extenso y tiene mucha información de cómo sacarle más partido a la fonera y a casi cualquier dispositivo que tenga wifi, os recomiendo que os paseis por allí si os interesa el tema.
Bueno, aqui comienzan mis andaduras en este blog. Espero que se cumplan las espectactivas que tengo puestas en él y que quien lea esto disfrute tanto como yo. 🙂
