Actualmente estoy haciendo un proyecto de secundaria estudiando claves RSA para comprenderlas mejor teórica y prácticamente. Una parte del proyecto consiste en un experimento, y elijo probar y ver qué tan grande será la carga de trabajo para la CPU al generar claves RSA de diferente longitud. También me gustaría ahorrar tiempo como punto de datos, si necesito llegar a una conclusión.
La máquina ejecuta Ubuntu 16.04 y las aplicaciones se descargan de los repositorios predeterminados.
El plan es utilizar GnuPG para generar claves RSA de diferente longitud (1024, 2048 y 4096) y GNU Time para obtener la carga de trabajo de la CPU y el tiempo para ejecutar el proceso. El proceso se automatizará con un script en Python y se verá así:
Para longitud en [1024, 2048, 4096]:
1.1. Por X veces:
1.1.1. Ejecute el comando Gnu PG y monitoree los recursos del sistema
1.1.2. Escribir el uso de los recursos del sistema en el archivo
A continuación trazaré algunos gráficos para ver si mi hipótesis es correcta.
Pero tengo algunas preguntas sobre la implementación de mi prueba GnuPG. Una explicación de cómo vendrá mi implementación después de las preguntas. Mis preguntas son:
- ¿Esta configuración hace lo que quiero hacer?
- ¿Puedo de alguna manera desactivar la creación automática de certificados de revocación?
- ¿Por qué se tarda mucho más en generar algunas claves?
- ¿Por qué GnuPG da la respuesta de que se necesitaron 0 segundos de CPU en el espacio de usuario para la creación de las claves? ¿Se hace en otro proceso?
- ¿Por qué el parámetro de carga de trabajo de la CPU solo muestra un valor (0 < CPU) cuando tomó menos de un segundo (reloj de pared > 1) crear las claves?
Leyendo el manual parece que la forma más sencilla de generar las claves es con la --batchopción activada. Configuré las opciones en un archivo con las siguientes instrucciones:
# Text syntax in this file
#%dry-run
%echo Generating RSA key...
# Don't ask after passphrase
%no-protection
Key-type: RSA
Key-Length: 1024
Name-Real: Real Name
Name-Email: [email protected]
Expire-Date: 0
# Generate RSA key
%commit
%echo Done!
El comando que ejecuta este archivo tiene dos partes, la parte Gnu Time y la parte GnuPG. El comando GNU Time tiene el siguiente aspecto:
$ time --format="Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%"
Y el comando GnuPG es el siguiente.
$ gpg2 --gen-key --homedir=./rsa-keys --batch [filename]
El comando que ejecuto en mi shell (fish shell si es importante) es el siguiente (GNU Time + GnuPG):
$ time --format="Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%" gpg2 --gen-key --homedir=./rsa-keys --batch [filename]
Salida del comando:
Wall clock: 36.83[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 0.04[s], CPU (userspace): 0.00[s], CPU (workload): 8%
Wall clock: 4.76[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 72.39[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 57.52[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 84.71[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 63.32[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 51.10[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 47.58[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 64.72[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 0.05[s], CPU (userspace): 0.00[s], CPU (workload): 6%
Wall clock: 0.03[s], CPU (userspace): 0.00[s], CPU (workload): 11%
Wall clock: 29.62[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 55.02[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 36.08[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 42.92[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 40.41[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 204.36[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 246.42[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 51.50[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Respuesta1
GnuPG lee desde /dev/random, que se bloquea cuando no hay suficiente entropía disponible (que es un comportamiento discutible). El esfuerzo computacional real es bastante insignificante. También puede observar que la primera o algunas ejecuciones terminan más rápido, ya que el grupo de entropía todavía estaba lleno de "bits nuevos". Recomiendo ejecutar watch cat /proc/sys/kernel/random/entropy_availen una terminal adicional para comprender cuándo GnuPG se ejecuta en modo de "baja entropía".
En las plataformas de hardware actuales, los procesos bloqueados por IO o en suspensión se pondrán en segundo plano, por lo que no se contabilizará el tiempo de CPU.
$ time --format='Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%' sleep 5
Wall clock: 5.00[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Esto también es visible al copiar algunos bytes /dev/random(lo que puede llevar bastante tiempo, especialmente en máquinas virtuales):
time --format='Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%' dd if=/dev/random of=/dev/null bs=1 count=512
512+0 records in
512+0 records out
512 bytes copied, 210.672 s, 0.0 kB/s
Wall clock: 210.67[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Finalmente, esto también explica por qué las iteraciones rápidas tienen una carga de trabajo de CPU mucho mayor: como el proceso se bloqueó en IO-wait durante un período de tiempo mucho menor, la porción del tiempo de cálculo real del tiempo de ejecución total es mucho mayor.