urMQTT на правом ARM64 VPS-у: без екрана, без хардверског генератора случајних бројева и са руковањем које је било споро

Претходни текст, urMQTT v0.3.0, завршио се са четири ставке под „Шта следи”: одлука о јавном демо брокеру (D1), fuzzing PCI и virtio парсера и тест за закључане табеле страница, дијалог за кључ на страници градитеља и bare metal. Ниједна од четири није урађена у овом кругу и то кажемо прво. Урадили смо нешто друго, што је све време недостајало: покренули смо urMQTT на правом ARM64 серверу са KVM-ом, а скоро све испод потиче са те једне машине. Прва ставка старог списка, CI, почишћена је (ранији текст и напомене уз издање који су га звали црвеним исправљени су).

Напомена унапред остаје иста: пројекат је пред-алфа, бројке мере код, тестове и одређене огледе на једној машини, не зрелост у продукцији. Где бројка није измерена на циљној машини, то пише.

Како је то изгледало у времену

Од прошлог текста (3.11. у 02:43) до данас (4.11. у 03:18) у main је 29 нових commitова, укупно 244. Као и раније, пројекат се гради уз Claude Code (commitови носе Co-Authored-By: Claude). Бројке су израчунате методом из прошла два текста (све .rs датотеке изван vendor/ и fuzz/, #[test] функције, наслови ## ADR- у docs/DECISIONS.md); метода на старом commitу даје исте бројке као тада.

Тренутак	Commit	Време	Rust редова	Тестова	ADR-ова	Commitова
прошли текст	f1a7fbc	3.11. 02:43	115 148	962	133	215
данас	efddf6e	4.11. 03:18	117 084	978	134	244

Раст: +1 936 редова, +16 тестова, +1 ADR. Опет мало новог кода; сам асемблер за P-256 (1 509 редова) је vendorован и није у броју редова.

Друга права машина

Дотад је пројекат имао један прави сервер: Contabo VPS са AMD EPYC-ом (x86_64, KVM), коришћен за поређење перформанси са Mosquittom. ARM64 је радио само у QEMU-у, на Macu са хардверским убрзањем, а у CI-ју без њега. Нова машина је netcup VPS 500 ARM G12.5: језгро Neoverse N1 од око 3 GHz, 2 vCPU, 3,9 GiB RAM-а, 64 GiB virtio диск, QEMU/KVM са UEFI firmwareом, virtio мрежна картица. Све смо водили преко REST API-ја провајдера помоћу клијента за командну линију: отпремимо ISO, прикључимо га као виртуелни CD, пребацимо уређај за покретање, угасимо и поново укључимо напајање.

Шта смо на њој радили, редом:

1. Прво снимак оригиналног система. Онлајн снимак није могућ са UEFI-јем, па смо сервер угасили и направили снимак ван мреже.
2. Инсталација. Инсталатер са ISO-а записао је слику на диск (са 30-секундним одбројавањем укупно око 40 секунди) и сам угасио машину, како је дизајнирано.
3. Покретање са инсталираног диска трајало је око 35 секунди до TLS руковања.
4. Задржана (retained) порука преживела је тврд нестанак струје. Објавили смо је, прекинули напајање преко API-ја, поново покренули и поруку прочитали.
5. Инсталирани диск, измерен Дијагностичким уносом (само читање; тест писања је прескочен јер инсталирани распоред не оставља недодељен простор, што је намерно): секвенцијално читање 332 MiB/s, насумична читања од 4 KiB 22 147 у секунди са p50 10,4 µs, p90 28,3 µs, p99 671 µs, максимум 9,9 ms (2 000 читања).

Пет ставки није скуп тестова: то је једна машина, по једно покретање сваке ствари, а инсталациони пут је на правом диску испробан једном. Показује ипак да језгров сопствени virtio-blk драјвер, инсталатер и покретање раде на правом cloud госту, а не само у лабораторијском емулатору.

Без екрана, па дијагностика иде преко мреже

Дијагностички унос из v0.3.0 црта своје бројке на framebufferу. На овом серверу конзола провајдера каже „Display output is not active”: виртуелна машина има virtio графичку картицу за коју немамо драјвер, а серијски порт није изложен. Бројке су постојале, а нико их није могао прочитати.

Поправка је реч за покретање diag-serve: машина изврши иста мерења, па се покрене као нормалан жив брокер и објави извештај као један JSON документ у задржаној поруци $SYS/diag/report, коју сме читати само оператерски сертификат. Мали алат urmqtt-diag-png из тог JSON-а црта контролну таблу истим кодом који језгро користи на екрану (исти распоред и исти фонт 8x8), па је слика баш онај екран који би машина показала:

На екран су успут дошле још две ствари, јер су нам недостајале: такт CPU-а (бројач циклуса PMU наспрам временске основе: овде 2,95 до 2,98 GHz; где се може читати само тајмер сталне брзине, пише „није мерљиво” уместо да се фреквенција тајмера испише као фреквенција CPU-а) и панел за генератор случајних бројева.

Од чега је састављен генератор случајних бројева

Панел каже одакле је генератор засејан и тестира свеже бајтове из сваког хардверског извора. На овој машини пише:

• virtio-rng: нема уређаја. RNDR (инструкција самог CPU-а): на овом CPU-у није доступна.
• EFI генератор случајних бројева у loaderу: 8 од 8 вредности различитих од нуле.
• Резервна могућност са дрхтањем времена извршавања CPU-а (ADR-038): 1 024 узорка од по 64 корака преко бројача циклуса PMU, процењена 3 бита по узорку, 768 бита признато (четвртина процене, по дизајну), здравствени тестови прошли.
• Излаз генератора, тест здраворазумности над 4 096 бајтова: 49,6 % јединица, најдужи низ 16 бита. То је провера да ништа није заглављено нити пристрасно, не статистичка сертификација.

Генератор на овом серверу, дакле, почива на резервној могућности са дрхтањем и на ономе што је предао firmware. Управо то описује ADR-038 и то је најслабије засејавање које језгро прихвата. Не кажемо да је покварено: признати битови су изнад прага који језгро тражи (256), а процењивач је конзервативан. Такође не можемо доказати да је добро као хардверски извор. Да ли продукцијска слика треба да одбије покретање без хардверског извора осим ако оператер то изричито дозволи, отворено је питање за власника (налази се у плану, испод). У пракси је то питање и за провајдера: хардверски уређај за случајне бројеве у виртуелној машини би га решио.

Руковање које је било споро

Дијагностички унос је показао и колико на серверу кошта пуно узајамно TLS руковање: 1,08 ms. Скоро све је аритметика јавних кључева: две ECDSA P-256 провере (сертификат клијента и клијентов доказ), свака око 508 µs, X25519 176 µs, један ECDSA потпис 141 µs. На x86_64 смо то раније решили (ADR-130, OpenSSL/Intel асемблер: P-256 три до четири пута брже); на ARM64 је још радио преносиви RustCrypto код.

Исто смо урадили за ARM64 (ADR-255). Асемблер је OpenSSL-ов ARMv8 nistz256 (Apache-2.0), преузет из ring 0.17.14 и vendorован са записаним пореклом и сваком механичком променом. Шта је било важно у детаљима:

• Само цели бројеви. Асемблер не користи NEON регистре. Две функције за избор из табеле које изворни код користи са NEON-ом изоставили смо и написали маскирана претраживања у Rustu са константним временом (коштају највише 1,4 µs од потписа од 12 µs).
• Заштита грана. Језгро је преведено са BTI-јем и аутентикацијом показивача. Свака од 8 извезених улазних тачака има слетну површину (проверено у disassemblyју језгра), а шест које чувају линк регистар њега потписује.
• Тестови, јер је ово криптографија у бази којој верујемо. Цео x86_64 скуп сада ради и на aarch64 Linuxу: аритметика поља и скалара наспрам школске референце, читава табела генератора (2 368 уноса) наспрам RustCrypto-а, потписи бит по бит једнаки RustCryptoвим, пресуде провере, ECDH са улазима ван криве и са нулом, и тестови познатих одговора који раде при сваком покретању кроз продукцијске путање. У четвороједарној виртуелној машини под олујом прекида радило је 59 526 кругова познатих одговора са 0 неслагања.
• Временски тест са контролом и сигнал који је био наш сопствени тест. Намерно цурећи производ постиже |t| од 482 до 1755, па тест види цурење ове величине. На Apple језгру у контејнеру ECDH је постигао 0,2 до 2,1, потписивање 0,5 до 1,9, генерисање кључа 0,8 до 5,5. На серверском arm64 језгру CI runnera ECDSA потписивање је у три покушаја постигло |t| = 8,6, 9,1 и 8,3, изнад наше границе 7, док су ECDH (3,9) и генерисање кључа (1,9) на истој машини прошли. Резултат који се понавља није шум, па смо га записали као отворен налаз (A255-W1) и на неколико сати подигли границу за тај један случај на 12 да би билд могао да прође. Затим смо нашли узрок и био је то тестни оквир: случај је потписивао једну фиксну поруку, па је ретки кључ сваки пут давао исти потпис, а насумични кључеви сваки пут другачији, а DER кодирање поновљеног потписа је брже (|t| од 49 до 57 само за кодирање). Са насумичном поруком по мерењу у обе класе случај постиже на runneru (виртуелној машини Neoverse N2) 1,4 и 1,8, само генерисање nonce-а 2,7 и 1,1, а граница је поново на 7. Једна ствар остаје отворена (A255-W2): процесорска заставица која чини време множача независним од података на Arm језгрима (DIT) није постављена нигде, ни у језгру ни око позива на страни домаћина. Ниједно мерење не показује разлику, али виртуелна машина runnera не излаже ту функцију, па је ни тест није могао показати.

Шта је донело

Прво микробенчмарк на машини на којој смо развијали, Apple M4 Pro (није циљни CPU, па односи на серверу могу бити другачији), истим кодом који зове руковање, пре и после:

Операција	пре (µs)	после (µs)	однос
генерисање кључа	30,8	7,0	4,4x
ECDH P-256	135,2	25,0	5,4x
ECDSA потпис	34,7	11,6	3,0x
ECDSA провера (непознат кључ)	147,4	29,1	5,1x
провера CA (регистрован издавалац)	54,2	9,6	5,6x
X25519 (непромењен код)	20,4	20,1	1,0x
процена руковања (збир горњих)	292	104	2,8x

Затим права ствар: исти генератор оптерећења, иста метода као у ранијем тексту о перформансама (пуно TLS 1.3 руковање са сертификатом клијента, без настављања, MQTT CONNECT, сервер затвара први), покренут са машине удаљене од сервера 9 ms, наспрам истог netcup VPS-а, пре промене и после ње. Слика за мерење има опуштена ограничења руковања, као у поређењу на x86_64; три понављања, бројка је медијана.

Нити	пре (веза/s)	после (веза/s)	однос	грешке
32	848 (408-855)	1 317 (957-1 317)	1,55x	0
64	827 (815-839)	1 398 (1 352-1 416)	1,69x	0
128	778 (714-788)	1 316 (1 313-1 383)	1,69x	0
TLS део везе, p50, 32 нити	18,5 ms	13 ms

Пуних руковања у секунди било је више за око 1,55 до 1,7 пута, не три пута, колико би дала сама аритметика. Разлог је једноставан и вреди га рећи: убрзали смо P-256, а X25519 (176 µs), TCP/IP стек, слој записа и MQTT су непромењени, па преостали део добија на значају (Амдалов закон). Следећи кандидат је X25519.

Ради оријентације поред x86_64 сервера из ранијег текста. Ово није упоредиво као трка: различити CPU-ови, различит број језгара (4 наспрам 2), различита удаљеност до генератора (15 ms наспрам 9 ms) и у оба случаја дељени домаћин са оптерећењем који је током покретања изгубио 5 до 60 % сопственог CPU-а. Упоредива колона је сервера сопствена цена CPU-а по руковању:

	Contabo, x86_64 EPYC (asm)	netcup, ARM64 N1 пре	netcup, ARM64 N1 после
CPU сервера по руковању	0,26 ms (конзола брокера)	1,08 ms (Дијагностика)	0,55 ms (Дијагностика, једно покретање, види испод)
руковања/s, 32 нити	169 (bench)	848	1 317
руковања/s, 64 нити	278 (bench)	827	1 398
руковања/s, 128 нити	413 (bench)	778	1 316

Истог дана Дијагностички унос је поново покренут на овој машини, са асемблером (у билду који садржи и графички драјвер описан у ажурирању на крају): CPU трошак сервера за једно узајамно TLS руковање био је 553 µs према 1,08 ms раније, 1,95 пута мање. ECDSA верификација трајала је 192 µs (раније 508 µs), потписивање 78 µs (141 µs), а X25519 209 µs (176 µs; тај код је непромењен, а такт CPU-а у овом покретању био је 2,58 GHz према 2,95 до 2,98 GHz у ранијим, па се појединачне бројке на овој дељеној машини померају за десетине процената). То је једно покретање, на дељеном домаћину. То што је брзина руковања порасла 1,55 до 1,7 пута, док је сопствени трошак сервера по руковању пао 1,95 пута, слаже се: остатак везе је стек, генератор и мрежа. Шум између покретања види се у сировим датотекама: свака тројка има једног одступника (408 пре и 957 после при 32 нити), кад је домаћин са генератором већи део CPU-а изгубио у корист других виртуелних машина. При 128 нити на обе машине је на граници генератор, не сервер.

Остатак скупа на овој машини

Исти скуп као за x86_64 сервер (пропусност, кашњење, растурање, неактивне везе) у целини је радио наспрам нове градње. За ове редове нема „пре”: покретање је заустављено ради градње асемблера, па су стање после промене, а асемблер ове путање не дотиче, осим руковања која отварају везе. Једна чињеница објашњава већину испод: ова виртуелна машина има два vCPU-а. Језгро 0 ради мрежну картицу, диспечовање и сав MQTT и TLS посао, језгро 1 је језгро базе и било је све време заузето 2 до 3 %. Сервер x86_64 имао је четири vCPU-а и два радна језгра. Све испод је зато перформанса брокера на једном језгру.

Неактивне везе	5 000	10 000	20 000
повезано	5 000 од 5 000 за 4,3 s	10 000 за 9,3 s	20 000 за 21,2 s
раст хипа језгра по вези	0,34 KB	0,41 KB	0,43 KB
грешке	0	0	0

(0,50 до 0,66 KB по вези на серверу x86_64 при commitу H7. Бројка хипа је $SYS/broker/memory/used минус његова вредност пре прве везе.)

Кашњење при умереној брзини (8 парова x 100 порука/s, 64 B)	p50	p99
QoS 0	4,0 ms	6,9 ms
QoS 1	4,1 ms	7,0 ms

Растурање (1 издавач, 64 B)	испоручено у секунди	p50	p99
100 претплатника, QoS 0, 50 порука/s	5 000 (све)	5,9 ms	8,6 ms
100 претплатника, QoS 1, 50 порука/s	5 000 (све)	6,3 ms	10,0 ms
1 000 претплатника, QoS 0, 10 порука/s	8 805 од 10 000	207 ms	5,4 s

Поплава, 16 парова, издавачи брзином коју брокер прихвата	објављено/s	испоручено/s	p50 / p99	изгубљене везе
QoS 0, 64 B	231 317	85 140	1,36 s / 2,8 s	0
QoS 0, 1 KiB	62 110	25 506	336 ms / 873 ms	0
QoS 1, 64 B	107 349	55 965	21 ms / 29 ms	0
QoS 1, 1 KiB	51 369	25 054	47 ms / 60 ms	0
QoS 1, 64 B, 64 пара	130 462	69 411	69 ms / 87 ms	0

Како читати. Кашњење при умереној брзини је допринос брокера плус један пут до генератора: генератор је овом серверу ближи него онај у поређењу на x86_64, па колоне кашњења нису упоредиве. Поплава QoS 0 показује уобичајену слику преоптерећеног једног језгра: брокер прихвата 231 000 порука у секунди и испоручује 85 000 (остало одбацују правила повратног притиска, чему и служе) са кашњењима у секундама, а ниједна веза није изгубљена; на серверу x86_64 иста таква поплава коштала је по покретању неколико веза због 20-милисекундног чувара (ADR-221 је од тада променио начин на који се тај буџет рачуна). Ред са 1 000 претплатника има исти карактер као раније, репови у секундама, делом од самог генератора. Бројке при commitу H7 на серверу x86_64 налазе се у ранијем тексту; у исту табелу их не стављамо јер се код између два мерења у путањи података променио (ADR-221 до ADR-224) и јер се машине разликују у свему.

Грешке које смо сами пронашли

• Слика је писала „no disks found”, а диск је био у извештају. Прва верзија urmqtt-diag-png поље disks уопште није читала. Власник пројекта је погледао слику, рекао да изгледа погрешно и био у праву. Исправљено, а тест сада чита диск назад из JSON-а.
• Инсталатер смо прерано прогласили готовим. Стање сервера је два пута прешло на „off”: једном на крају поновног укључења и једном кад је инсталатер завршио. Наша скрипта је прво узела за друго, откачила ISO и покренула стари систем, који је затим јавио стари број верзије и послао нас да тражимо грешку у инсталатеру које није било. Скрипта сада прво чека свеже покретање.
• Историја напретка је изгубљена. Анализа за план утврдила је да је commit за миљоказ S6 заменио docs/PROGRESS.md (1 763 реда, миљоказ M0 до S5) сопственим уносом од 26 редова. Остало је неопажено данима, иако README ту датотеку назива „извором истине”. Враћено из историје.
• CI је после асемблера пао на два места. Три smoke теста имала су уписану величину слике за покретање („10 MiB”), која је са већим језгром порасла на 11 MiB; величину више не претпостављају. Други пад био је горе описани временски тест: први пут је изгледао као шум на дељеном runneru, па смо тест понављали три пута; пао је у сва три покушаја и тако смо сазнали да је то сигнал, а сигнал се показао као наш сопствени тест (сваки пут је потписивао исту поруку). Ту једну границу подигли смо на неколико сати, рекли то отворено и поново је спустили када је узрок отклоњен.
• Документација броји три речи за покретање, а код има четири (diag-serve), и табела миљоказа у README-у и даље приказује рад последње недеље као планиран. Обоје је у плану као ставке за исправку.

План, са питањима

По први пут постоји план: око 40 ставки у три фазе (v0.4 учвршћивање и рад; протокол и мрежа; скалирање, више cloudова и bare metal), свака са разлогом из документа, напором, ризиком и начином провере, 16 питања на која може одговорити само власник, и списак онога што је ван опсега. Неколико ствари каже отворено: подржан је само MQTT 3.1.1, објава QoS 2 затвара везу, нема IPv6 (провајдер даје /64), нема WebSocketа ни одлазне везе брокера, а нема ни драјвера за мрежне и уређаје за похрану великих cloudова.

Шта још није доказано

• CPU трошак по руковању са асемблером на Neoverse језгру мерен је само једном (553 µs према 1,08 ms раније, на нижем такту, на дељеном домаћину); 1,55 до 1,7 пута потиче од брзине пуних руковања, а 3 до 5 пута са Apple језгра. Страна x86_64 рефакторисања (код премештен у сопствену датотеку) тип-проверена је и изграђена, али њени unit тестови нису покретани и језгро x86_64 после тога није покренуто: x86_64 скупови нису у CI-ју, покрећу се ручно на Contabo VPS-у, а за ову измену то још није урађено.
• Константно време: за P-256 генерисање кључа, ECDH и потписивање (кључ и nonce) статистички тест није нашао зависност од ретке тајне. Радио је на Apple језгру и на CI runneru (виртуелној машини Neoverse N2), не на netcup Neoverse N1 језгру, и никада са постављеном DIT заставицом на серверском језгру (A255-W2, отворено: језгро је не поставља). Није радио за X25519 или Ed25519. Тест црне кутије ограничава само оно што може да разлучи при својој величини узорка.
• Један сервер, један провајдер, једна инсталација. Више резултата (инсталација, нестанак струје) је једно покретање. Осим руковања, редови перформанси немају „пре”, а машина са два vCPU-а даје брокеру једно језгро за податке.
• Генератор случајних бројева на овом серверу засејан је из дрхтања и из firmwarea, како је горе описано.
• Потписни кључ је и даље пробни, слике издања су развојне градње, а преводе овог текста написала је AI и нису их проверили изворни говорници.
• Нема независне ревизије, нема bare metala, нема IOMMU-а.

Шта следи

1. X25519 у асемблеру за ARM64 (то је 176 µs преосталог руковања) и понављање мерења по руковању на Neoverse језгру више од једном.
2. Одлука о подразумеваној вредности генератора случајних бројева: одбити покретање без хардверског извора осим ако оператер каже другачије, или задржати резервну могућност са дрхтањем и то гласно рећи.
3. Стари списак: одлука о D1, fuzzing PCI и virtio парсера, дијалог за кључ на страници градитеља.
4. Из плана, за следеће издање: прави потписни кључ и продукцијски PKI, MQTT 5.0 и QoS 2.

Код је на github.com/zeljan-alduk/urMQTT; docs/PROGRESS.md остаје извор истине о томе шта ради, docs/PERFORMANCE.md о томе шта је измерено (одељак 10 има бројке асемблера), docs/AUDIT.md о томе шта није доказано. Пред-алфа, као раније; пријаве грешака и безбедносне пријаве по упутствима у SECURITY.md су добродошле.

Ажурирање, 4. новембра, касније истог дана. Четири ствари из сати након објављивања овог текста.

1. Недостајућа бројка. Дијагностички унос је поново покренут на серверу netcup са асемблером и дао је број који недостаје у првој табели: 553 µs CPU-а сервера по узајамном TLS руковању према 1,08 ms раније (детаљи испод те табеле).
2. Сигнал код потписивања био је наш тест. Узрок горе описаног временског сигнала пронађен је и поправљен у тестном оквиру (сваки пут је потписивао исту поруку); граница је поново на 7. Отворено остаје то што DIT заставица није постављена нигде (A255-W2).

3. Проблем са екраном је решен и налази се на main. Написали смо драјвер за virtio графичку картицу (само 2D, ADR-256), који се укључује конфигурационим кључем уграђеним у слику (console.virtio_gpu, подразумевано off, а auto и on захтевају формат конфигурације 5). Са on картица Екран код провајдера приказује на живо контролну таблу Дијагностике на серверу netcup, исту слику као горе, укључујући и последњи екран са „press any key”. Његов fuzz циљ је у првој верзији пронашао праву грешку: одговор са информацијама о екрану, краћи за четири бајта од спецификације, прихваћен је као исправан (A256-W1); прави уређај увек шаље цео одговор, па сервер није био погођен, а парсер сада одбија краћи. Шта нисмо проверили: да је тамни екран заиста дошао од фирмвера који ресетује картицу при предаји језгру (вероватно, непотврђено), садејство са Secure Boot-ом и x86_64 на правој машини (радио је само под емулацијом). Познато ограничење (A256-W2): подешавање auto не разликује жив емулирани framebuffer поред virtio картице од мртвог, па у тој једној конфигурацији бира virtio картицу. Драјвер у језгро додаје парсер одговора хипервизора, због чега је искључен осим ако конфигурација то не затражи.

4. Издање. Све ово је у v0.4.0, које је исте вечери објављено као предиздање (издање на GitHub-у). Страница градитеља на овом сајту нуди прво њега; потребан је формат конфигурације 6, а старији шаблони (v0.2.0 до v0.3.0) одбијају нове кључеве поруком која каже да користите новије издање. Ограничења v0.3.0 остају: потписни кључ је и даље пробни, а слике су развојне градње са пробним сертификатима. CI на commitу издања био је зелен тек пошто је један посао поново покренут (клијентски тест унутар smoke сценарија једном је истекао по времену, а други пут је прошао). Шта смо проверили на објављеним датотекама: minisign потпис, контролне суме, атестације градње језгра и SBOM-а, и шаблон са новим кључевима (v0.4.0 их прихвата, v0.3.0 их одбија). Драјвер за нове virtio уређаје (конзола, балон, улаз, vsock) налази се у издању, али је подразумевано искључен и није покретан на правом серверу.