CPU çevrimi başına aktarım hızı: bir yönlendiriciyle karşılaşmayı atlatan sayı

İki fiziksel yönlendiricide, gerçek bir gigabit LAN üzerinden gerçek trafik taşırken, tünel çekirdeğimiz 122 Mbit/s ile itti; yönlendiricinin kendi çekirdek tünel uygulaması ise 66.8 Mbit/s ile — aynı gönderici üzerinde, Mbit başına daha az CPU ile. Hiçbir rakam tek başına hikâyenin tamamı değildir: iki kolun farklı trafik üreticileri kullanması gerekti, çünkü tek bir üretici bu karşılaştırmanın iki tarafında da çalışmaz. Bu yüzden tartışılacak oran, her kolun kendi tünelsiz tavanına karşı olan oranıdır; bu, aşağıdaki tabloda yer alır ve bizi daha da lehimize çevirir, aleyhimize değil. Bir dizüstü bilgisayarda dört VM'lik bir laboratuvar çalıştırması, mutlak rakamlarla daha hızlı bir şey ve bir eksende daha az göz alıcı bir şey söylüyor. Yönlendirici rakamına daha çok güveniyoruz, çünkü ikisinden yalnızca yönlendirici, bir müşterinin trafiğinin fiilen geçtiği yerdir.

Öne çıkarılmaya değer bulgu budur ve bu yazının bir yerine iki sonuç bölümü olmasının da nedeni budur: laboratuvar ile donanım, hangi eksenin önemli olduğu konusunda anlaşmıyor ve bu anlaşmazlığın üzerini örtmek, her iki rakamın kazandırdığından daha fazla güvenilirliğe mal olurdu.

Neyin, ne üzerinde ölçüldüğü

İki bağımsız ortam, çünkü bir kıyaslama yalnızca çalıştığı ortam içinde dürüsttür — bir iperf3 rakamı ile bir bandwidth-test rakamı, iki isim taşıyan tek bir rakam değildir ve bir dizüstü bilgisayarın çekirdeklerini paylaşan bir VM bir yönlendirici değildir.

Donanım — iki MikroTik yönlendirici, bir gigabit LAN, 2026-09-01. Gönderici olarak RB3011UiAS (ARMv7, 2×1400 MHz), alıcı olarak cAP ax (ARM64, 4×864 MHz), ikisinde de RouterOS 7.24.1. Çekirdeğimiz, bir RouterOS konteynerinde, kullanıcı alanında, fv olarak, yönlendiricinin kendi çekirdek içi WireGuard protokolü uygulamasına karşı çalıştı — bu donanımda mevcut olan tek elma-elma karşılaştırması, çünkü RouterOS'un kendisinde sunulan tek alternatif budur. İki üretici, çünkü hiçbiri uygulamaları temiz biçimde geçmez: konteyner çalıştırmamız için dd | nc, çekirdek çalıştırması için RouterOS'un kendi bandwidth-test'i — her biri kontrol olarak kendi tünelsiz tavanını taşır, böylece okuyucu orana güvenmeden önce tavanı akıl kontrolünden geçirebilir.

Laboratuvar — bir Apple silikon anamakine üzerinde QEMU/HVF altında dört aarch64 Debian konuğu, 2026-08-31. Test edilen her ikili arasında aynı anahtar çiftleri, adresler, portlar, MTU ve arayüz açılışı: çekirdeğimiz, çekirdeğimizin çatallandığı kullanıcı alanı çekirdeği olan boringtun 0.7, wireguard-go (WireGuard protokolünün referans uygulaması, kullanıcı alanı) ve Linux çekirdeğinin kendi WireGuard protokolü modülü. 15 saniyelik iperf3 çalıştırmaları, her birinden üç örnek, yukarıdaki uyarı kutusundaki nedenden dolayı her iki Rust çekirdeği de tek bir veri düzlemi iş parçacığına sabitlendi.

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

Yönlendirici çalıştırması henüz bir task hedefi değildir — her kutuda RouterOS'un yerleşik WireGuard protokolü sunucusuna karşı, bir RouterOS konteynerinde elle başlatılan fv'dir. Tam topoloji ve her ham satır kendi docs/benchmarks/results.csv dosyamızda yer alır.

Önemli olan sayı: yönlendiricide

İki bağımsız çerçeveleme birbirini doğruluyor; bu da sonucu seçilerek değil inandırıcı kılan şeydir: mutlak aktarım hızı çekirdeğimizi 1.8× lehine çeviriyor, her üreticinin kendi tartışmasız tavanına karşı korunan aktarım hızı ise onu 2.2× lehine çeviriyor. Tablonun söylemediği şey: iki üretici aynı araç değildir, bu yüzden tek bir manşet oranı yerine her iki tünelsiz tavan da yazdırılmıştır ve gönderici trafiği yerel olarak üretmek yerine gerçek ağ trafiği alsaydı her iki rakam da değişirdi. Aşağıdaki laboratuvar tablosunun aksine, bunlar tekil çalıştırmalardır: köşeli parantez içindeki yüzdeler, o çalıştırma sırasında CPU'nun dolaştığı aralıktır, tekrarlanan denemeler arasındaki bir yayılma değildir.

Laboratuvar: üç kullanıcı alanı çekirdeği, bir çekirdek, eşitlenmiş iş parçacıkları

CPU maliyeti, laboratuvarın bu yazıdaki yerini hak ettiği noktadır — bu, yönlendirici tablosunun gösteremediği tek eksendir, çünkü bir yönlendiricinin çekirdek içi karşılaştırma öğesi, karşılaştıracak bir CPU dökümü vermez.

Kazanmadığımız yerler

İki yer, ikisi de CSV'nin içine gömülmek yerine açıklanıyor:

Laboratuvarda kullanıcı modu CPU'su. Daha ucuz Rust karşılaştırma öğesinin 0.290'ına karşı 0.347 s/Gbit — o tabloda önümüzde olduğu tek sütun. Bizim okumamız, bunun israf değil satın alınmış olduğudur: çekirdeğimiz her iki yönde de TUN sağlama toplamı boşaltması (checksum offload) yapar; bu da işi çekirdekten alıp kullanıcı zamanı olarak sayılan kullanıcı alanı CPU'suna taşır — ve bu değiş tokuşun geri ödendiği sistem-CPU sütunu rahatça önde (0.549'a karşı 0.787). Toplam CPU yine de kazanıyor. Yukarıdaki kullanıcı/sistem bölünmesi, özellikle bu değiş tokuşun ileri sürülmek yerine görünür olması için gösteriliyor.

Yönlendiricide gidiş-dönüş süresi. Çekirdek tünelinin 0.92 ms'ine karşı 1.22 ms — çekirdek içi çözümün açıkça kazandığı tek donanım ekseni; bunun sıradan nedeni, bizim yolumuzun bir konteynerin veth sıçramasına ve çekirdek içi bir yolun ödemediği bir kullanıcı alanı zamanlama dönüşüne mal olmasıdır. İlginç biçimde laboratuvar, p99 gecikmesinde tersi bir sıralama gösteriyor (çekirdeğin 0.96 ms'ine karşı 0.94 ms) — bunun ötesinde “farklı ortamlar, farklı darboğazlar” dışında bir anlam çıkarmıyoruz ve hangi rakam daha göz alıcıysa onu seçmek yerine bunu söylüyoruz.

Neyin taze, neyin devralınmış olduğu

Yukarıdaki her rakam bir tarih taşır ve tarihler önemlidir: yönlendirici tablosu 2026-09-01, laboratuvar tablosu 2026-08-31'dir. O zamandan beri, koordineli bir major-sürüm sıçraması, veri düzlemimizin her pakette çağırdığı temel kripto crate'lerini taşıdı — chacha20poly1305, blake2, curve25519-dalek — ve o ağaca karşı tam laboratuvar veya yönlendirici karşılaştırmasını yeniden çalıştırmadık. Yukarıdaki rakamlar gerçektir ve dikkatle ölçülmüştür, ama yayımlandığı tarih itibarıyla altı gün eskidir, bu sıçramadan önceki bir ağaç üzerindedir. Bunları sessizce değil, bunu belirterek yayımlıyoruz ve elimize geçtiğinde bir yeniden çalıştırmayı tarihleyeceğiz. Yönlendirici rakamı da kendi kayıtlarımızda belirli bir commit'e sabitlenmiş değildir — “2026-09-01”i bir optimizasyon değişikliğine bağlı olarak değil, “eylül başı” olarak okuyun.

Bugün, bu makinede, bir yönlendirici veya VM laboratuvarı olmadan yeniden çalıştırabileceğimiz şey, kripto sıçramasının en doğrudan dokunduğu yoldaki kısımdır: yukarıdaki her soket, TUN ve iş parçacığı kaygısından yalıtılmış encapsulate ve decapsulate maliyeti.

2026-09-05'te, Apple M3 Max üzerinde, cargo bench -p forestvpn-quantum --bench datapath_benches -- --measurement-time 3 --warm-up-time 1 ile, criterion 0.8.2, nokta başına 100 örnekle yeniden çalıştırıldı. Soket yok, TUN yok, iş parçacığı yok — tamamlanmış tek bir el sıkışma, ardından döngü içinde kapsülleme/kapsül açma. Sonuçlar yöne ve paket boyutuna göre karışıktır, her iki yönde de birkaç yüzde içindedir; tam olarak beklediğimiz şey de budur: çekirdeğimiz bu yolu üst akışından çatalladı ve ikisi de artık aynı RustCrypto ilkel nesneleri kuşağı üzerinde duruyor. Bu bir aktarım hızı iddiası değildir — çatallanmış kripto yolunun kendisinin, gürültü payı içinde, üst akışınkiyle yaklaşık aynı maliyete sahip olduğunu söyler; bu da yukarıdaki laboratuvar ve yönlendirici kazanımlarını güvenilir kılan şeydir: bunlar yığının başka bir yerinden gelir (syscall toplu işleme, boşaltma, iş parçacığı), daha hızlı bir şifreleyiciden değil.

Yeniden üretme

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

Yönlendirici çalıştırması bugün elle yapılır: her kutuda bir RouterOS konteynerinde fv, RouterOS'un kendi WireGuard protokolü sunucusuna karşı.

Bunun size ne kazandırdığı konusunda dürüst olmak gerekirse: düzenek ve buradaki her tablonun arkasındaki ham results.csv, bugün herkese açık olmayan kendi ağacımızda yaşıyor. Yukarıdaki komutları, klonlayıp tekrarlayabileceğiniz bir şey olarak değil, çalıştırdığımızın tam bir ifadesi olarak okuyun. Bize en az bağımlı olan iddia, kontrol etmeye en çok değer olandır da — boringtun ve wireguard-go herkese açıktır, iperf3 herkese açıktır ve bu yazının başındaki iş parçacığı sayısı tuzağı (tek bir bayrağın bir karşılaştırma öğesini tek bir makinede kabaca 789 ile 1427 Mbit/s arasında oynatması) bu üçüne sahip ve döngüde bizim kodumuz olmayan herkes tarafından yeniden üretilebilir. Sizde de doğrulanırsa, tartışılacak satırlar yukarıdaki eşitlenmiş satırlardır. Doğrulanmazsa, bunu duymak isteriz.