Rendimiento por ciclo de CPU: la cifra que sobrevive al contacto con un router

En dos routers físicos, moviendo tráfico real sobre una LAN de gigabit real, el núcleo de nuestro túnel alcanzó 122 Mbit/s donde la propia implementación de túnel del kernel del router alcanzó 66.8 Mbit/s — en el mismo emisor, con menos CPU por Mbit. Ninguna de las dos cifras cuenta toda la historia por sí sola: los dos brazos tuvieron que usar generadores de tráfico distintos, porque ningún generador único funciona en los dos lados de esa comparación. Así que la proporción que vale la pena discutir es cada brazo frente a su propio techo sin túnel, que aparece en la tabla de más abajo y nos favorece más, no menos. Una ejecución de laboratorio con cuatro VM en un portátil da una cifra más rápida en términos absolutos y, en un eje, algo menos favorable. Confiamos más en la cifra del router, porque un router es el único de los dos por el que realmente pasa el tráfico de un cliente.

Esa es la conclusión con la que conviene empezar, y también la razón por la que esta entrada tiene dos secciones de resultados en lugar de una: el laboratorio y el hardware no están de acuerdo en qué eje importa más, y disimular ese desacuerdo costaría más credibilidad de la que gana cualquiera de las dos cifras.

Qué se midió, y sobre qué

Dos entornos independientes, porque una prueba de rendimiento solo es honesta dentro del entorno en el que se ejecutó — una cifra de iperf3 y una cifra de bandwidth-test no son una misma cifra con dos nombres, y una VM que comparte los núcleos de un portátil no es un router.

Hardware — dos routers MikroTik, una LAN de gigabit, 2026-09-01. RB3011UiAS (ARMv7, 2×1400 MHz) como emisor, cAP ax (ARM64, 4×864 MHz) como receptor, RouterOS 7.24.1 en ambos. Nuestro núcleo se ejecutó como fv, en un contenedor de RouterOS, en espacio de usuario, frente a la propia implementación del protocolo WireGuard en el kernel del router — el único comparador equivalente disponible en ese hardware, ya que es la única alternativa que trae RouterOS de serie. Dos generadores, porque ninguno cruza limpiamente entre implementaciones: dd | nc para nuestra ejecución en contenedor, y el propio bandwidth-test de RouterOS para la ejecución del kernel — cada uno aporta su propio techo sin túnel como control, para que quien lea pueda comprobar el techo antes de confiar en la proporción.

Laboratorio — cuatro invitados Debian aarch64 bajo QEMU/HVF en un host con silicio Apple, 2026-08-31. Mismos pares de claves, direcciones, puertos, MTU y activación de interfaz en cada binario probado: nuestro núcleo, boringtun 0.7 (el núcleo en espacio de usuario del que se bifurcó el nuestro), wireguard-go (la implementación de referencia del protocolo WireGuard, en espacio de usuario), y el propio módulo del protocolo WireGuard del kernel de Linux. Ejecuciones de iperf3 de 15 segundos, tres muestras cada una, con ambos núcleos en Rust fijados a un solo hilo de plano de datos por la razón indicada en el recuadro de arriba.

task test:impls    # lab: ours vs boringtun vs wireguard-go vs the kernel
task test:all      # lab: single-hop, multi-hop, and the comparison

La ejecución en el router todavía no es un objetivo de task: es fv iniciado a mano en un contenedor de RouterOS en cada equipo, frente al servidor del protocolo WireGuard integrado en RouterOS. La topología completa y cada fila en bruto están en nuestro propio docs/benchmarks/results.csv.

La cifra que importa: en el router

Dos formas de plantearlo, independientes entre sí, coinciden, y eso es lo que hace el resultado creíble en lugar de escogido a conveniencia: el rendimiento absoluto favorece a nuestro núcleo 1.8×, y el rendimiento retenido frente al techo indiscutido de cada generador lo favorece 2.2×. Lo que la tabla no dice: los dos generadores no son la misma herramienta, por lo que se imprimen ambos techos sin túnel en lugar de una única proporción destacada, y ambas cifras cambiarían si el emisor estuviera recibiendo tráfico de red real en lugar de generarlo localmente. A diferencia de la tabla de laboratorio de más abajo, estas son ejecuciones únicas: los porcentajes entre paréntesis son el rango en el que osciló la CPU durante esa ejecución, no una dispersión entre repeticiones.

El laboratorio: tres núcleos en espacio de usuario, un kernel, hilos igualados

El coste de CPU es donde el laboratorio se gana su lugar en esta entrada: es el único eje que la tabla del router no puede mostrar, porque el comparador integrado en el kernel de un router no ofrece ningún desglose de CPU con el que comparar.

Dónde no ganamos

Dos sitios, ambos explicados en lugar de enterrados en el CSV:

CPU en modo usuario, en el laboratorio. 0.347 s/Gbit frente a los 0.290 del comparador en Rust más barato — la única columna de esa tabla donde nos supera. Nuestra lectura es que se compra, no se desperdicia: nuestro núcleo hace descarga (offload) del checksum de TUN en ambas direcciones, lo que traslada trabajo del kernel a la CPU en espacio de usuario, contabilizado como tiempo de usuario — y la columna de CPU de sistema, donde se recupera esa inversión, va cómodamente por delante (0.549 frente a 0.787). El total de CPU sigue ganando. El desglose usuario/sistema de arriba se muestra específicamente para que esta compensación sea visible en lugar de solo afirmada.

Tiempo de ida y vuelta, en el router. 1.22 ms frente a los 0.92 ms del túnel del kernel — el único eje de hardware donde el kernel gana claramente, por la razón ordinaria de que nuestra ruta paga un salto veth del contenedor y un turno de planificación en espacio de usuario que una ruta en el kernel no paga. Curiosamente, el laboratorio muestra el orden contrario en la latencia p99 (0.94 ms frente a los 0.96 ms del kernel) — no le damos más lectura que «entornos distintos, cuellos de botella distintos», y lo decimos así en lugar de escoger la cifra que más favorezca.

Qué es reciente y qué es heredado

Cada cifra de arriba lleva una fecha, y las fechas importan: la tabla del router es del 2026-09-01, la del laboratorio del 2026-08-31. Desde entonces, una subida de versión mayor coordinada cambió los crates de criptografía subyacentes que nuestro plano de datos llama en cada paquete — chacha20poly1305, blake2, curve25519-dalek — y no hemos vuelto a ejecutar la comparación completa de laboratorio ni de router sobre ese árbol. Las cifras de arriba son reales y se midieron con cuidado, pero tienen seis días a fecha de publicación, sobre un árbol anterior a esa subida. Las publicamos indicándolo, en lugar de en silencio, y pondremos fecha a una repetición cuando la tengamos. La cifra del router tampoco está fijada a un commit concreto en nuestros propios registros: lee «2026-09-01» como «principios de septiembre», no como ligada a un único cambio de optimización.

Lo que sí podríamos volver a ejecutar hoy, en esta máquina, sin un router ni un laboratorio de VM, es la parte de la ruta que la subida de criptografía tocó más directamente: el coste de encapsular y desencapsular, aislado de cualquier consideración de sockets, TUN o hilos de las de arriba.

Repetido el 2026-09-05, Apple M3 Max, cargo bench -p forestvpn-quantum --bench datapath_benches -- --measurement-time 3 --warm-up-time 1, criterion 0.8.2, 100 muestras por punto. Sin sockets, sin TUN, sin hilos — un protocolo de enlace completado, y luego encapsular/desencapsular en bucle. Los resultados están repartidos por dirección y tamaño de paquete, todos dentro de unos pocos puntos porcentuales en cualquier sentido, que es exactamente lo que cabría esperar: nuestro núcleo bifurcó esta ruta desde su origen, y ambos están ahora en la misma generación de primitivas de RustCrypto. Esto no es una afirmación de rendimiento — dice que la ruta de criptografía bifurcada cuesta aproximadamente lo mismo que la del origen, dentro del ruido, que es lo que hace que las victorias de laboratorio y de router de arriba merezcan confianza: vienen de otra parte de la pila (agrupación de llamadas al sistema, descarga de trabajo, hilos), no de un cifrado más rápido.

Cómo reproducirlo

task test:impls          # lab: ours vs boringtun vs wireguard-go vs the kernel
task test:all            # lab: single-hop, multi-hop, and the multihop cost table
cargo bench -p forestvpn-quantum --bench datapath_benches -- --measurement-time 3 --warm-up-time 1

Hoy la ejecución en el router es manual: fv en un contenedor de RouterOS en cada equipo, frente al propio servidor del protocolo WireGuard de RouterOS.

Siendo sinceros sobre lo que eso te ofrece: el arnés de pruebas y el results.csv en bruto detrás de cada tabla de aquí viven en nuestro árbol, que hoy no es público. Lee los comandos de arriba como una declaración exacta de lo que ejecutamos, no como algo que puedas clonar y repetir. La afirmación que menos depende de nosotros es también la que más merece la pena comprobar — boringtun y wireguard-go son públicos, iperf3 es público, y la trampa del número de hilos al principio de esta entrada (un solo ajuste que mueve a un comparador entre aproximadamente 789 y 1427 Mbit/s en un único host) es reproducible por cualquiera que tenga esos tres y nada de nuestro código de por medio. Si se sostiene para ti, las filas igualadas de arriba son las que vale la pena discutir. Si no se sostiene, queremos saberlo.