Monitorizando la carga del sistema con “htop”
Posted: Mon Nov 01, 2021 3:26 pm
Para poder realizar este procedimiento antes tienes que realizar esta configuración:
Con el comando “htop” podemos ver la carga del sistema. Le ha quitado protagonismo al “top” de toda la vida ya que ha mejorado algunos aspectos como mostrar la carga de cada núcleo. Si ejecutamos "htop" veremos algo como esto:
Para que tengáis una referencia, deciros que esa imagen es con el MSXVR en el escritorio sin hacer nada. Podemos ver que el procesador de la RPI tiene cuatro núcleos y el número 3 está al 100%. Curiosamente si emulamos un juego, salimos al VR-DOS o al VR-BASIC, la carga se mantiene prácticamente al mismo nivel. Tan sólo con el GameDB que todavía no esta muy optimizado y parece que le cuesta procesar la gran cantidad de caratulas que carga, he visto que se llegaban a utilizar más de dos núcleos.
Vemos que el proceso con más carga se llama “./msxvr_pi3” y hay muchos más con ese nombre que no son más que hilos de ejecución del principal(si pulsamos F5 podemos ver el árbol de jerarquía). Este es el programa que inicia el entrono del MSXVR y como vemos tiene una carga del 112%. Alguno se estará preguntado cómo se puede superar el 100% de la carga del procesador, es debido a que se está contabilizando la carga acumulada de todos sus hilos, por lo que en teoría podríamos llegar a un 400% de carga.
Con esta visión podríamos pensar que vamos sobrados de procesador, pero hay que tener en cuenta que muchas tareas sólo se pueden ejecutar en un sólo hilo de ejecución, es decir, en un sólo núcleo, por lo que al final el límite lo va a poner la frecuencia de procesamiento, 1.2GHz en nuestro caso, por eso el hecho de que un sólo proceso ya alcance el 100% en uno de los núcleos no me dejaba tranquilo hasta que decidí hacer la siguiente prueba.
El fichero “config.txt” que hay en la partición “boot” contiene el parámetro “arm_freq” que sirve para establecer la frecuencia del procesador que por defecto sabemos que es 1400MHz(1200MHz al alcanzar 60º). Se me ocurrió activar este parámetro y poner la frecuencia mínima a la que se puede configurar, que es 600MHz:
Podemos comprobar que el cambio ha sido efectivo y la RPI funciona a esa velocidad con el script de este tema.
A esta velocidad el entorno y los programas en general cargan mucho más lentos, como era de esperar, pero lo que no me esperaba es que su velocidad de ejecución fuera prácticamente la misma, es decir, en la emulación de los juegos(incluso en el Hellsroad) no notaba que fueran más lentos, algo que por lo menos me deja bastante tranquilo pues parece que en cuanto a la emulación, el sistema tiene potencia de sobra. Otra cuestión muy distinta es la fluidez del escritorio donde sí se aprecia una notable lentitud, por ejemplo a la hora de mostrar menús o con las listas desplegables, si antes ya se notaba retraso, ahora funcionando a 600MHz se ha acuciado mucho más, algo que espero se solucione pues es difícil de entender cómo una lista desplegable con unas pocas opciones se puede demorar tanto en su presentación.
Lo curioso de todo esto es que esperaba que el sistema se sobrecargara mucho más, sin embargo se obtiene prácticamente la misma carga, tan solo se observa que los hilos de ejecución del proceso “msxvr_pi3” han aumentado ligeramente su valor, del 2,7% al 5.5%, como podemos ver en la siguiente imagen, algo que me vuelve a dar cierta tranquilidad ya que parece que el sistema, a pesar funcionar a 600MHz no requiere de mucha potencia para su ejecución:
Se ha hablado en ocasiones de la actualización a futuro a la Raspberry Pi 4, la cual funciona a 1,5GHz. A la vista de estos resultados y sobre todo en cuanto a la emulación se refiere de las distintas plataformas(MSX, ZX, CPC, etc) parece que con 1,2GHz vamos sobrados y no parece que el paso a la RPI4 sea una mejora muy necesaría, por lo menos mientras no aparezca alguna causa que lo justifique ya que por mi parte, aunque los tiempos de carga de las APPs nativas son un poco lentos es algo que puedo aceptar, pero no así la fluidez de movimiento cuando ya estás en la aplicación, algo que espero consigan mejorar.
Con el comando “htop” podemos ver la carga del sistema. Le ha quitado protagonismo al “top” de toda la vida ya que ha mejorado algunos aspectos como mostrar la carga de cada núcleo. Si ejecutamos "htop" veremos algo como esto:
Para que tengáis una referencia, deciros que esa imagen es con el MSXVR en el escritorio sin hacer nada. Podemos ver que el procesador de la RPI tiene cuatro núcleos y el número 3 está al 100%. Curiosamente si emulamos un juego, salimos al VR-DOS o al VR-BASIC, la carga se mantiene prácticamente al mismo nivel. Tan sólo con el GameDB que todavía no esta muy optimizado y parece que le cuesta procesar la gran cantidad de caratulas que carga, he visto que se llegaban a utilizar más de dos núcleos.
Vemos que el proceso con más carga se llama “./msxvr_pi3” y hay muchos más con ese nombre que no son más que hilos de ejecución del principal(si pulsamos F5 podemos ver el árbol de jerarquía). Este es el programa que inicia el entrono del MSXVR y como vemos tiene una carga del 112%. Alguno se estará preguntado cómo se puede superar el 100% de la carga del procesador, es debido a que se está contabilizando la carga acumulada de todos sus hilos, por lo que en teoría podríamos llegar a un 400% de carga.
Con esta visión podríamos pensar que vamos sobrados de procesador, pero hay que tener en cuenta que muchas tareas sólo se pueden ejecutar en un sólo hilo de ejecución, es decir, en un sólo núcleo, por lo que al final el límite lo va a poner la frecuencia de procesamiento, 1.2GHz en nuestro caso, por eso el hecho de que un sólo proceso ya alcance el 100% en uno de los núcleos no me dejaba tranquilo hasta que decidí hacer la siguiente prueba.
El fichero “config.txt” que hay en la partición “boot” contiene el parámetro “arm_freq” que sirve para establecer la frecuencia del procesador que por defecto sabemos que es 1400MHz(1200MHz al alcanzar 60º). Se me ocurrió activar este parámetro y poner la frecuencia mínima a la que se puede configurar, que es 600MHz:
Code: Select all
arm_freq=600A esta velocidad el entorno y los programas en general cargan mucho más lentos, como era de esperar, pero lo que no me esperaba es que su velocidad de ejecución fuera prácticamente la misma, es decir, en la emulación de los juegos(incluso en el Hellsroad) no notaba que fueran más lentos, algo que por lo menos me deja bastante tranquilo pues parece que en cuanto a la emulación, el sistema tiene potencia de sobra. Otra cuestión muy distinta es la fluidez del escritorio donde sí se aprecia una notable lentitud, por ejemplo a la hora de mostrar menús o con las listas desplegables, si antes ya se notaba retraso, ahora funcionando a 600MHz se ha acuciado mucho más, algo que espero se solucione pues es difícil de entender cómo una lista desplegable con unas pocas opciones se puede demorar tanto en su presentación.
Lo curioso de todo esto es que esperaba que el sistema se sobrecargara mucho más, sin embargo se obtiene prácticamente la misma carga, tan solo se observa que los hilos de ejecución del proceso “msxvr_pi3” han aumentado ligeramente su valor, del 2,7% al 5.5%, como podemos ver en la siguiente imagen, algo que me vuelve a dar cierta tranquilidad ya que parece que el sistema, a pesar funcionar a 600MHz no requiere de mucha potencia para su ejecución:
Se ha hablado en ocasiones de la actualización a futuro a la Raspberry Pi 4, la cual funciona a 1,5GHz. A la vista de estos resultados y sobre todo en cuanto a la emulación se refiere de las distintas plataformas(MSX, ZX, CPC, etc) parece que con 1,2GHz vamos sobrados y no parece que el paso a la RPI4 sea una mejora muy necesaría, por lo menos mientras no aparezca alguna causa que lo justifique ya que por mi parte, aunque los tiempos de carga de las APPs nativas son un poco lentos es algo que puedo aceptar, pero no así la fluidez de movimiento cuando ya estás en la aplicación, algo que espero consigan mejorar.